1.
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

2.
<ul><li>Joint team between INRIA & Ecole des Mines de Nantes (France) </li></ul><ul><li>+10 members </li></ul><ul><li>Research focus on: </li></ul><ul><ul><li>MDE core technologies </li></ul></ul><ul><ul><ul><li>metamodeling, model transformation, MaaS, model management,… </li></ul></ul></ul><ul><ul><li>MDE applications </li></ul></ul><ul><ul><ul><li>reverse engineering, tool interoperability </li></ul></ul></ul><ul><li>Organizers of the “MDE Diploma” 1st full postgraduate program on MDE </li></ul><ul><li>Commitment to Eclipse open-source projects: </li></ul><ul><ul><li>ATL, MoDisco, EMF Facet, AMW, AM3, TCS </li></ul></ul><ul><li>Strong links with several software development companies </li></ul><ul><li>Participation in both national and international research projects </li></ul>AtlanMod

3.
Index <ul><li>Introduction to Modeling/MDE </li></ul><ul><li>Modeling in Agile </li></ul><ul><li>Agile in Modeling </li></ul><ul><li>Modeling the Agile </li></ul><ul><li>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!! </li></ul>

4.
Index <ul><li>Introduction to Modeling/MDE </li></ul><ul><li>Modeling in Agile </li></ul><ul><li>Agile in Modeling </li></ul><ul><li>Modeling the Agile </li></ul>

5.
Introduction <ul><li>In the beginning: Model Driven Architecture /Model Driven Development </li></ul><ul><li>Now Model Driven Engineering : endless possibilities </li></ul><ul><ul><li>DSLs </li></ul></ul><ul><ul><li>Model to model and model to text transformations </li></ul></ul><ul><ul><li>Model-driven Reverse Engineering </li></ul></ul><ul><ul><li>Megamodeling & Model management </li></ul></ul><ul><ul><li>Model V&V </li></ul></ul><ul><ul><li>Business Rules Reengineering </li></ul></ul><ul><ul><li>Tool interoperability </li></ul></ul><ul><ul><li>… </li></ul></ul>

6.
Relationship between MDA/MDD/MDE

7.
MDE vs Programming Technical Spaces Modelware Grammarware MOF/KM3 (metametamodel) UML (metamodel) MyModel.uml EBNF.g Java.g MyProgram.java <ul><li>Same “architecture” but different abstraction level </li></ul>

8.
MMa MMb Ma Mb MMa2MMb.atl MMa is the source metamodel Ma is the source model Mb is the target model MMB is the target metamodel Key elements in MDE: Models and Model Transformations ATL Transformation <ul><li>A MDD dev. process could be defined as a series of M2M transformations plus one final M2T transf. to generate the code </li></ul>

9.
Why modeling? <ul><li>The benefits of modeling activities in a software development process are well-known (?) : </li></ul><ul><ul><li>Improves the productivity of the development team (e.g. models can be used for a semi-automatic code-generation) </li></ul></ul><ul><ul><li>Reduces the number of defects in the final code (models facilitate early evaluation of the system) </li></ul></ul><ul><ul><li>Capture and organize the understanding of the system (which btw, eases the integration of new team members). Models are well suited for documentation </li></ul></ul><ul><ul><li>Permit early exploration of alternatives </li></ul></ul><ul><ul><li>Increases the decomposition and modularization of the system </li></ul></ul><ul><ul><li>Facilitates the system's evolution and maintenance (e.g. by facilitating tracing back the code to the original requirements) </li></ul></ul><ul><ul><li>Facilitates the reuse of parts of the system in new projects </li></ul></ul>

10.
Reality Check (but let’s be optimistic) <ul><li>Modeling will be commonplace in 3 years time – S. Mellor </li></ul><ul><ul><li>Though he is giving the same answer for the last 20 years </li></ul></ul>

11.
Let’s be optimistic: Technology hype cycle MDE? <ul><li>Maybe a more agile modeling approach will help to climb up? </li></ul><ul><li>Will it happen the same with Agile? </li></ul>

12.
Index <ul><li>Introduction to Modeling/MDE </li></ul><ul><li>Modeling in Agile </li></ul><ul><li>Agile in Modeling </li></ul><ul><li>Modeling the Agile </li></ul>

13.
Modeling in Agile? Are you serious? <ul><li>Modeling may seem to go against agile principles (how many of you employ modeling techniques in your daily work?) </li></ul><ul><li>Stephen Mellor: agile critique to mde: </li></ul><ul><ul><li>models don't run (i.e. not working software), </li></ul></ul><ul><ul><li>can't be tested, </li></ul></ul><ul><ul><li>are just documentation, </li></ul></ul><ul><ul><li>require extra work and alignment (i.e. not adequate for late requirement changes) </li></ul></ul><ul><li>But let´s take a closer look!!! </li></ul><ul><ul><li>Let´s see if modeling can be integrated in agile processes </li></ul></ul><ul><ul><li>And what kind of modeling would be more beneficial for those (avoid “modeling just for the sake of modeling”) </li></ul></ul>

14.
Modeling and MDE are process-agnostic <ul><li>Modeling is not a development process just a software development technique </li></ul><ul><ul><li>Many people still think that UML is their development process!!! </li></ul></ul><ul><li>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 </li></ul><ul><li>Any development process could follow MDE principles and employ modeling techniques </li></ul><ul><li>Two interesting initiatives: </li></ul><ul><ul><li>Modeling tailored for Agile: Agile Modeling </li></ul></ul><ul><ul><li>MDE tailored for Agile: Agile MDA </li></ul></ul>

15.
Agile Modeling <ul><li>A practice-based methodology for effective modeling and documentation of software-based systems. </li></ul><ul><li>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. </li></ul><ul><li>Lead by Scott Ambler. Web site: http://www.agilemodeling.com/ </li></ul>

16.
Some Agile Modeling Principles (I) <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>Multiple Models . You need to use multiple models to develop software because each model describes a single aspect/view of your software. </li></ul><ul><li>Rapid Feedback . By working with other people on a model you are obtaining near-instant feedback on your ideas. </li></ul><ul><li>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) </li></ul>

17.
Some Agile Modeling Principles (II) <ul><li>Embrace Change . Requirements evolve over time and so your models </li></ul><ul><li>Incremental Change . Develop good enough models. Evolve models over time (or simply discard it when you no longer need it) in an incremental manner. </li></ul><ul><li>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 </li></ul><ul><li>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. </li></ul>

18.
Agile Modeling Practices <ul><li>These practices help to achieve the previous principles and integrate very well in agile dev. processes </li></ul>

19.
Agile MDA (I) <ul><li>Ambler’s view: MDA combined with the agile modeling principles seen before. Executability by means of series of transformation steps </li></ul><ul><li>One of the best ways of realizing the benefits of models is generating software artifacts from them </li></ul>

20.
Agile MDA (II) <ul><li>S. Mellor’s view: Executable UML / Executable models </li></ul><ul><li>Models are directly executable </li></ul><ul><li>Easy to test/simulate </li></ul><ul><li>Code-generation and model interpretation are then two different alternative strategies to &quot;implement&quot; executable models. </li></ul><ul><li>Many design decisions need to be predefined </li></ul><ul><li>Most times, models with limited expressivity (you can only draw what you can execute) </li></ul>

21.
MDD: Isn’t this Agile? Automatic Generation of a CRUD application

22.
Isn‘t this agile? (II) <ul><li>Only a static model (e.g. UML class diagram) is provided </li></ul><ul><li>A full CRUD application can be obtained (for prototyping or even as part of the final application) </li></ul><ul><li>Would you say this is an agile technique? </li></ul><ul><li>Would you adopt such technique in your development process? </li></ul><ul><li>This is exactly what many dev. frameworks (symfony, Django, Grails,…) already provide (even if it is using a specific notation like Doctrine) </li></ul><ul><li>Many programmers are then in fact modelers as well!! (low-level modelers) </li></ul><ul><ul><li>Even if they don´t want to acknowledge that  </li></ul></ul>

23.
Index <ul><li>Introduction to Modeling/MDE </li></ul><ul><li>Modeling in Agile </li></ul><ul><li>Agile in Modeling </li></ul><ul><li>Modeling the Agile </li></ul>

24.
Can Agile help MDE engineers? <ul><li>MDE engineers need to develop a large number of metamodels, model transformations, model injectors,… </li></ul><ul><li>Can agile techniques help in this process? </li></ul><ul><li>Can we just treat an MDE project as a software project and follow an agile method to develop MDE artifacts? </li></ul>

25.
Can Agile help MDE engineers? (II) <ul><li>As you can guess my answer is a rotund YES </li></ul><ul><li>Let’s take a look at, for instance, the 12 XP practices to see if we could have an Extreme Modeling method. </li></ul><ul><li>Pair programming -> Pair Modeling. Same benefits </li></ul><ul><li>Planning game -> Planning the releases of the MDE artifact makes completely sense </li></ul><ul><li>Test-driven development -> Test-driven (meta)modeling. Modeling by first writing tests that the new model excerpt must pass. </li></ul>

26.
Can Agile help MDE engineers? (III) <ul><li>Whole team -> Even easier in this case. Customers are the designers that will use the MDE artifacts in the next development project </li></ul><ul><li>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 ) </li></ul><ul><li>Design improvement -> Model refactorings </li></ul><ul><li>Small releases -> Incremental development of the MDE artifacts (e.g. a transformation that in each iteration processes a larger part of the input models) </li></ul><ul><li>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) </li></ul>

27.
Can Agile help MDE engineers? (III) <ul><li>Collective code ownership -> Collective model ownership </li></ul><ul><li>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?) </li></ul><ul><li>System metaphor -> MDE artifacts should also be easy to explain to everybody </li></ul><ul><li>Sustainable pace -> Believe it or not, MDE engineers are also human (as programmers) </li></ul>

28.
Index <ul><li>Introduction to Modeling/MDE </li></ul><ul><li>Modeling in Agile </li></ul><ul><li>Agile in Modeling </li></ul><ul><li>Modeling the Agile </li></ul>

29.
<ul><li>Agile is fashionable: Many companies want to look “modern” by adopting an agile method </li></ul><ul><li>The introduction of a new software process in an organization is a difficult and often risky proposition. </li></ul><ul><li>This is especially true when adopting agile processes since they usually imply radical departures from traditional team structures, cooperation styles and relationships </li></ul><ul><li>Therefore, many of them fail and may (wrongly) conclude that agile does not work. </li></ul>Adopting agile methods is not easy

30.
<ul><li>Agile is not for every project nor for every team </li></ul><ul><ul><li>The “not for every project” part is usually assumed </li></ul></ul><ul><ul><li>The “not for every team” is not </li></ul></ul><ul><li>E.g. Email I got a few days ago: </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>I cannot answer if I don’t know the organization and context of your team!! </li></ul>Adopting agile methods is not easy <ul><li>Companies need a better understanding of the implications and requirements to adopt an agile method </li></ul><ul><li>Once this is understood you can even go beyond Agile: </li></ul><ul><ul><li>Survey results: companies selling agile tools do not use agile methods themselves! ( http://www.drdobbs.com/tools/220301068 ) </li></ul></ul>

31.
<ul><li>We face the same situation with people trying to adopt MDE </li></ul><ul><li>Buying nice code-generator tools is not enough </li></ul><ul><li>What if nobody in your team is good at modeling? (even if he/she is a great programmer) </li></ul><ul><li>Any method needs to be adapted to the reality of the company </li></ul>Adopting agile methods is not easy <ul><li>Also, remember: Introduction of ANY new technology decreases productivity in the short term </li></ul>

32.
<ul><li>Unfortunately, descriptions of software processes focus on the sequence of process activities and generated artefacts </li></ul>Understanding the agile method is key Picture from Wikipedia

33.
<ul><li>Can a company implement Scrum with these descriptions? </li></ul>Understanding the agile method is key (II) SPEM view of the process

34.
<ul><li>These descriptions ignore the social and organizational aspects of the agile method, such as: </li></ul><ul><ul><li>Which are the most critical roles? What are the consequences if they don’t perform? </li></ul></ul><ul><ul><li>What are the skills required to perform each role? </li></ul></ul><ul><ul><li>Which other actors a member depends on in order to succeed in his goals? What does he depend on them for? </li></ul></ul><ul><li>This kind of knowledge is key to facilitate the adoption of a software process </li></ul><ul><li>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 </li></ul>Adopting agile methods is not easy <ul><li>E.g. If nobody in the team has the skills to play the role of Scrum master I cannot adopt Scrum </li></ul>

35.
How modeling can help? <ul><li>We propose to use models to represent a new perspective of agile methods </li></ul><ul><li>This perspective focuses on describing and analyzing the social and human aspects of the process. </li></ul><ul><li>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. </li></ul><ul><li>The i* framework consists of two main models: the SD (Strategic Dependency) and SR (Strategic Rationale) model. </li></ul><ul><li>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) </li></ul>

36.
Strategic Dependency model <ul><li>Focuses on the dependencies between the different actors/roles of the process and the goals they want to achieve </li></ul><ul><li>Two kinds of goals: hard goals (or simply goals) representing the functional objectives, and soft goals, expressing qualitative objectives. </li></ul><ul><li>Analysing this information helps to answer questions about the social aspects of the software process, as the ones mentioned before. </li></ul>

37.
Strategic Dependency model (II) <ul><li>Here is very clear what are the roles team members must fill and what problems may appear when a given member does not deliver </li></ul>Simplified SD model for Scrum

38.
Strategic Rationale model <ul><li>Once the SD is done we refine it to create the SR model </li></ul><ul><li>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 </li></ul>

39.
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

40.
Analysing the models <ul><li>The models facilitate the evaluation of the adequacy of this process for the company. </li></ul><ul><li>For instance, looking at the models, any company willing to adopt Scrum should realize that it needs to check: </li></ul><ul><ul><li>If there is somebody in the company that can play the role of Scrum Master (and the same for the other roles) </li></ul></ul><ul><ul><li>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? ...) </li></ul></ul><ul><ul><li>. . . </li></ul></ul>

41.
Analysing the models (II) <ul><li>And be prepared to invest the required time/money to cover the gaps found in the analysis or assume their consequences </li></ul><ul><li>Consequences are the cascade problems triggered by not satisfying the expectations of the other actors shown as dependencies in the SD model. </li></ul><ul><li>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. </li></ul>

42.
In the future… <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><ul><li>Experiments already done with students developing a software project with Scrum </li></ul></ul><ul><ul><li>We were able to correctly identify the problems they would have applying Scrum before they started the project </li></ul></ul><ul><ul><ul><li>We knew what parts of the model were impossible to satisfy in their classroom setting -> we identify the goals that would not be fulfilled </li></ul></ul></ul>

43.
In the future…

44.
Conclusions <ul><li>Agile and Modeling / MDE are friends and not foes </li></ul><ul><li>There are many ways in which they can benefit from each other </li></ul><ul><ul><li>Modeling helps to understand agile processes and facilitates their adoption </li></ul></ul><ul><ul><li>Modeling is a useful technique to integrate in an agile process </li></ul></ul><ul><ul><li>Agile techniques can improve the modeling phase of any software development process </li></ul></ul>

45.
Continuing the discussion http://modeling-languages.com [email_address] www.emn.fr/x-info/atlanmod @softmodeling <ul><li>And the Jeudi des Mo dè les series of conferences : http://www.emn.fr/z-info/jmodeles/ </li></ul>