Mining Source Code^3
Nucci, Dario Di
Code is an incredible source of information. Indeed, mining software repositories can tell us whether code is natural, how to use a new framework, or how to identify similar changes. In this talk, I will present state-of-the-art and limitations on the usage of graph-based algorithms to mine software repository. In particular, I will cover how program analysis, pattern mining and pattern matching can help developers to identify: conventions and idioms, using syntactic information commonly represented as Abstract Syntax Trees; framework usages, relying on semantic information such as control and data dependencies represented as Program Dependency Graphs; similar modifications in multiple different locations, computed using change loggers or change distillers. Last I will present INTiMALS, an ongoing industry-university collaboration to develop a language-parametric framework for mining this information in legacy systems.
 Okay, cool. So next up, so one more last for the year. Thank you, everyone. Thank you for being here. So I'm Dadyo Dinucci. I'm a research fellow here in Brassos. So actually, I didn't work a lot to arrive here. But I work in the sister university of Welby. So I work in the Frey University of Brassos. If you've been in Brassos for a couple of days, you know some stories about Brassos. I've never been in Brassos. So today, I'm going to talk with you about mining source code, about mining idiom, usages, and edits. Actually, I will show you that these different aspects in reality have a lot in common. And I will try to show you the limitation that we have in applying these kind of techniques. But also, the novelty of applying these kind of techniques and the advantages that we could have in a few years of research. So actually, I'm a Sunday researcher in Europe. So I moved a bit during my life. I'm not Belgian. I'm Italian. I'm an Italian from the South. But then during the last years, I was in a working depth. And after a while, I moved to Brassos. So today, I'm going to talk with you about mining software repositories. We could think about that a software repository is just a Git repository or maybe an issue tracker. But actually, when we talk about software repositories, we talk about not only versioning systems and issue tracker, but also about marketplaces or about communication in which you developers use all your information. So actually, what we would like to do is to gather this information to mine these repositories just to extract this data and to create a common history for a software project. So after having all this information, what we can do is that we can, for example, apply machine learning techniques. And today, you heard a lot about this. But why we need this? Because actually, if you think about, you are providing a lot of data to public repositories. But there is something that these repositories can do for you. And actually, this is what we are trying to do. So actually, we are trying to get all your information but just to help you. So to provide you some information that you can use so that you can reduce the time that you spend coding your projects. Actually, because no one likes to debug the silly mistakes. So last year in Brussels, we started a collaboration with a company that is called Rincut and is based in Brussels. So the goal, actually, Rincut is a company that is working on compilers. So they are very good in modernized software languages. And maybe it seems to be a bit strange. But even if today we have really modern languages, we have really a lot of code that actually is still in legacy code. So actually, we are trying to help Rincut people to modernize languages. Because actually, this is an important market. There is a growing needed to have this kind of techniques. But one of the problems is that today, what Rincut the people are doing is pretty much manually. So they are doing everything manually. Without any IDE or any to support. And for example, just to understand the complexity of what they are doing, in some cases, they are trying to replicate the behavior of a compiler without running the compiler. So you have some code. You try to understand how this code really works. And we are talking about a code or something that is stranger than a code. And then you have to modernize this code to something that you can run on Azure or on your cloud or something like this. I'm talking about Azure because Rincut works with Microsoft. So the goal of this project is actually to automate the migration that requires pattern discovery. But for doing this, we are trying to mine three different use cases for three different objectives. So going in details, I will show you that actually mining codidiums or mining library usages or mining systematic edits. Now I will tell you what I'm talking about. It's not very different. But why we are trying to do this? So first of all, we would like to comprehend these programs. Because the first issue that you have when you work with legacy code is just to understand what the code is doing. Then what we would like to do is to do some anomaly detection. So actually, if you have a large code base, maybe, starting from a new piece of code, you can understand if you are making a mistake. But what is very our final goal is to build a full modernization assistance that actually is able to tell you which mistakes you are making and to create a better language without a lot of effort. So to transpose your code from one language to another. So our approach is actually divided in three different steps. The first step is actually only to import the code. Because our idea is that these assistance should be language parameter, so parametric. So what we would like to do is to have a common framework that is able to work with different languages, not only COBOL, not only Java, not only Python, but to have a common framework. For doing this, we need a meta model. Actually, this meta model should be able to gather the information and to provide them this information to our algorithms, our pattern mining algorithms. But first of all, we have to work on importing this data. To import this data, actually, at this point of our project, we have different importers. For example, we are able to import Java code from open source projects. But we are also able to import legacy systems. For example, we are able to import COBOL code. The second step after having this common meta model is to run our pattern mining algorithm. I will show you briefly. In theory, it seems that everything is easy. That we have everything that is needed to deal with this kind of issue. But in practice, I will show you that it's not so easy. And maybe we have to work several years on this. And then the third part is actually to provide the patterns that we're able to mine to developers so that developers can really understand if there are some common usages for our library or whether there are some syntactic idioms. Or for example, whether some commits are repetitive. So first of all, I will just provide you some information about idioms. Actually, this morning, Miltos was talking about idioms. Anedium is just a syntactic fragment that recourse across software projects and serves a single semantic purpose. Actually, this definition is a bit bug. Because it's a bit hard to understand what is really an idiom. But let's try to just find a simple example. So in this case, we have three different pieces of code. You see that in all these pieces of code, you have a try. Then you have a condition. And in this condition, you are invoking the method move to first. Then you have a body, which we are doing something. And then finally, you have the final for the exception. And then you close these objects. So as you can see in the end, these three pieces of code, they are doing actually the same. So and you can generalize these three pieces of code with this idiom. And maybe when you have to modernize and to move from a version of your system to another, you can use this kind of information. Now, the problem is that actually, we are talking about only three pieces of code. And actually, it's pretty straightforward to understand that these three pieces of code are something in common. But when we talk about ecosystems, when we talk about huge software repositories, in the end, we find out that it's not so easy. And of course, a developer could not do something like this. So the idea, if we would like to apply a really theoretical approach, is just to run a frequent item set algorithm. So in theory, this problem is not very hard to solve. Because what we can do is that from a piece of code, we just create a representation with that three because based on the code, you can just create an abstract syntax tree. And then you can run your algorithm maybe without any problem. But in practice, when you run it, you discover that most of the idioms that you find out, in the end, are not so interesting. In the end, they are boring. And we're boring. We mean that, OK, if I tell you that given a Java class, a Java class is composed by attributes and methods, then you say that, OK, this is not so interesting. It's not something that is new. We know about it. But the problem is that actually, it's led that you have a trade-off. I mean, from a point of view, you would like to discover very particular, very tricky idioms. But from the other point of view, you have that after a while, your search just explodes. So in the end, you are not able to gather patterns. And most of the cases, you have only auto-memory issues. So you cannot really do anything. So what we are trying to do is to explore novel pattern-mining arguments for source code. And then we are going to incorporate this information in our tool. So actually, there are various applications that you can use for mining when you mine code idioms. First of all, you could discover new syntactic pattern. Then you could discover a code that is deviated from a pattern. And then you can propose new actions to developers. So this is the overview of our framework. So as I was telling you in the general view, we have a source code importer that is able to gather this information in a common representation. Then we have some mining preprocessors that helps us to clean up the representations. And then we have the pattern miner. Actually, it's important to say that now we are running a pretty simple algorithm that is frequently mining. But we are trying to explore all the possibilities that you have with this kind of algorithm. So in the end, using the algorithm per se is not very hard. But adapt this kind of algorithm to our case study is not so easy. Also, because you have to remember that it's true that we are talking about, at least now for the first year of our project, we are talking about Java projects. But in theory, we would like to apply this knowledge to all the languages. So one of the problems is that after that you set up your algorithm, maybe your algorithm will work just for your case study, a realy small case study. I will not generalize it all. So after having our pattern miner, and actually we are exploring different kinds of algorithms, the second step, the fourth step is the pattern match. So after mining a lot of patterns, what you can do is that to apply your match to discover if in another piece of code you have these patterns. And only after these, you can provide this information to the developers so that actually the developers will able to improve their code base. So the first problem of this kind of application is that it's highly time consuming. And tweaking the algorithm is not so easy. A really something that is maybe in some cases very people don't consider about much learning is that really every, every, every small detail matter. And changing a bit the configuration means that in the end you are going to spend a lot of execution time. And maybe after spending all this time, there is such that you will have are not very useful. So another problem that you have is that in some cases, we are able to generate really a large amount of patterns, as well as redundant patterns. Some patterns are more related to the grammar of the language and not about the use of the language. So what we are trying to do is that to solve these issues, we are trying to put some constraints that help to reduce the search space. Actually, the search space in our case is very, very large. But we are trying to fix these kind of issues. Another problem is that the setting constraints is not so straightforward. I mean, really every detail matter, and setting these details is not so easy. Another issue, the last one, is that evaluating, maybe the most important issue is that evaluating the patterns is not easy at all. I mean, one of the issues that we had in the first year is that we were able to mine patterns. But in the end, even saying what is boring and what is interesting is not so easy. So it means that maybe after hours of computation, we are going to have a lot of patterns, but you don't know whether they are useful or not. And if you don't know this, it means that you are not able to tweak your algorithm. So in summary, we developed a language parameter framework to mine co-digms. Now we are running this kind of algorithm. And we are doing some work in progress to reduce the search space, applying heuristics and constraints. And we are trying to understand the real value of idioms to improve the mining process. The second part of my presentation is about mining usages. Now you know the difference between libraries and frameworks. So libraries are different by frameworks, because if you would like to use a library, you just need to understand the API and to use the APIs. While if you would like to use a framework, actually what you have to do is that you have to implement or to extend some parts of the framework. Now one of the issues that you have today with framework is that from the point of view of the developer, actually you don't know how to use a framework and how to correctly extend a framework given a functionality. So actually what you do today is that you just take your framework and you start analyzing the different way in which this framework could fit your test study. So first of all, from the developer point of view, we would like to understand how you should extend a given framework. But also another problem that you have in this case when you try to mine libraries is that from the maintainer of the framework point of view, actually the maintainer doesn't know anything about how people are using his library. So in the end, it's possible that if you are a maintainer of a library and you would like to remove a functionality that maybe no one is using, in the end you don't know this. I mean, you based on comments or based on what is your opinion, you are going to add or remove APIs. But in the end, you don't know what will be the impact of your change. So when you would like to extend a framework, what you have, and this is a definition that is from a paper of a few years ago, is that you have an extension point that is the part that you should extend, and then you have a usage that actually defines how you are going to extend your framework. But there are different kind of extension point. For example, a really simple extension point is the one in which actually in your code base, you're just using a method. This is the easiest thing. And actually, if you think about this, extending a framework in this way is not very different to use a library. The second thing that you will do is that you not only use a method, but you also customize this method before using it. The third way is that you actually extend a class providing new functionalities. Now, if you have a look to this picture, this is another work that we, and another part of Intimal from which we are working on. And then it seems that the framework is different with respect to the previous version that I showed you. But if you think about it, it's not very different. Because in every case, we need an importer, and then we need a miner, and then we need a matcher, and then afterwards, we need a visualization tool. So this is for telling you that in the end, when you try to mine different aspects of the source code, in most of the cases, there are not so many difference, at least from a really high point of view. Now, we performed a case study in which we developed an importer for Scala. So first of all, we are able to mine the source code. We are able to tag each part of the source code. And based on this tagging, what we are able is that, first of all, we are able to extract all the data that we need. So we are going, we clone the projects, then we compile the projects, we do type resolution, and just after this, we are able to understand which are the extension points. After this part, we run our miner. With respect to the previous approach, in this case, we run a subgraph mining algorithm. That is a priori. And then we visualize the data. But what is important is that, also in this case, we tried to evaluate our approach, mining several projects from Scala. We mined five different frameworks, so Spark, Kamokito, Adoop, and Play. Naturally, we saw something that was pretty much interesting. First of all, we saw that mining these kind of patterns is not very hard, but also the accuracy of these patterns. In the end, it's very high. I mean, in most of the cases, we had that the accuracy was about 90 something percent. But one thing that, for example, we are not expecting is that in most of the cases, to extend a given class, you don't have a lot of extension points. So in most of the cases, given a class, you have at most four extension points. And also, we discovered that applying our miner, most of the patterns that we were able to find were pretty much simple. So from this point of view, you can understand that, as I told you before, you have a trade-off. The trade-off is that, on the one end, you have that your patterns could be simple. On the other end, you have the accuracy. So the higher the accuracy, the simpler the patterns. But this also means that what we have to do in the future is that we have to try to gather some patterns that are more complicated. This means that maybe our accuracy will start failing. But it's also true that, as a developer, you care about complex patterns. Because if you are going to use a library, you don't need this kind of technology if the extension is easy. Last, I will talk to you about mining edits. So until this point, we'll talk about snapshots. So you have your snapshot. You analyze your snapshot. From your snapshot, you analyze your snapshot from a syntactic point of view or from the point of view of a given library or a given framework. Now, when we talk about systematic edits, we are talking about comments. So what we would like to do is that we will let's consider a repository. And in this repository, we have these changes, and then these changes, and then these changes. So we have three instances of a change. But in the end, we have only one systematic edit. So actually, it could be interesting to know about these changes, because what we will do is that if we have a new change and the change is different, we expect that the systematic changes, it's probable that actually we are going to add a bug. So systematic edits can be tedious, and of course, manually mining this data is very hard, because you can just add errors. Now, what we did is that we proposed the atull. They actually, based on a software project in Java, is able to mine all the story of a project, and is able to, it represents the source code changes as ST nodes, and is able to apply a frequent item set mining that is a bit different with respect to the first that I showed you in the previous slides. Now, the applications are similar to the one that I showed you before. So first of all, you would like to detect error-prone code, then you would like to assist the developers. And the best thing would be to generate automatically some transformation based on existing instances. So in this case, the approach is a bit different, because we don't start from a snapshot, but we start from a git repository with different code revisions. Then we apply a change distiller. So we are able to gather all the edd scripts. Then what we do is that, first of all, we group these edd scripts, then we apply an equivalent script, create idea, and all in the end, we apply our frequent item set mining algorithm. Now, let's consider an example, because it's much easier to understand. Let's consider that we have this commit. So in this commit, we are adding two lines of code. Actually, these two lines of code are more or less the same. There's only a really small change. Now, so what we are doing? First of all, we are inserting an if statement. Then we are inserting a method invocation. Afterwards, we are adding a dis-expression. And then we are computing the equals on the argument that is the TCP. Afterwards, we are returning an integer. Now, we can say that we have two different groups of changes. This one and this other one. But in the end, these two groups are doing the same. Now, what is the grouping criteria? First of all, what we are going to do is to group the changes into transaction. Actually, what we do is that we group the changes based on the method in which they are. So we are going to have these two groups. Of course, there are some limitations in this approach, because our approach could be a bit naive in some cases. For example, because we are excluding changes that occur across different methods. The second thing is to understand that given two different group of changes, is to understand if they are the same. Otherwise, we cannot compute the ed script. Now, the change equivalence criteria is based on the change type, the subject, and the context. The change type is pretty much easy to understand, because for example, in the case before, we are adding a line of code. So in the end, this is an insert. So given this edit, in the end, we know that this is the subject. And actually, what we do is that we anonymize the identifiers, just because otherwise it's hard to gather together the patterns. And then finally, we define the context. But the context, if you think about, is just the place in which the subject occurs. So given these two group of changes, we transform the edits in this kind of representation. What we did is that we evaluate the correctness of the tool. And actually, we applied it to our code base of our company that is in Belgium. We mined different repositories from Android projects. Actually, and it's important to say that, for really understand if our ed scripts were correct or not, we had to manually evaluate the scripts. And as I told you before, this is something that you always have to do. I mean, one of the problems in doing research in academia is that actually, sometimes, we don't have real developers. And so it's a bit tricky, but in the end, we try to be developers. So what we understand from this study is that, first of all, in most of the cases, you have that the majority of systematic edits have few instances. So in the end, you see that, and this one of the problems of applying our mining algorithm is having a few instances. It means that you have to spend more computational effort. Then another problem, because you cannot cut the search, then another problem is that in most of the cases, you see that on average, three or four ST level changes disregard the number of instances. So you have that larger instance size can occur with the small number of instances. So in summary, we have a technique that is able to identify systematic edits. In most of the cases, we see that in 12.5% of commits, they contain systematic edits. And mostly, all these instances are pretty, pretty much small, but they can have a large size. As a future work, we are trying to explore the different configurations. And we are trying to mine for the specific type or systematic edits. And also, we are trying to mine across commits. Because one of the problems that we have today is that we mine a single commit per time. So if we have changes that are across commits, we are not able to mine this kind of information. Thank you. Have you studied any pattern of good practices or bad practices in terms of number of times they've been removed or added in a code base? Can you carry out any questions? Yeah, the question is that when we were studying systematic edits, if we see people? If you notice any pattern of add-ins, you can say, OK, this is a good practice. Because if you've been added a lot of time, this is a bad practice because it's already removed. So the question is that if we were able to mine some best practice across the systematic edits, actually, this is an ask question. And actually, it's the final goal of this kind of study. I mean, the final goal is to understand if there are some best practice that you can apply everywhere. But what you have to understand is that in most of the cases for systematic edits, you have really a small number of instances. It means that if you mine a software repository, you have, for example, for a systematic editor, you have three instances. For example, in this case, we saw that for 2,500 systematic edits, you have only three instances. So this cannot be our best practice. But one of the problems is that one of the problems applying this kind of technique is scalability. Because what we were doing is that for each project, we are going through the history. And we were analyzing all the history of just one project per time. Now, what you should do for having an information like that is that you should mine a complete ecosystem so that you should be able to understand whether there are some best practice that different developers are applying. Because in our case, most of the repositories are, I mean, most of the people that work on a repository are not a lot. I mean, in most of the cases, you don't have thousands of developers. So it's really hard to mine a best practice that you could apply everywhere. 10. Depending on your project, you found different videos applying to the same thing. You find that? Different videos that apply to the same thing. OK, so the. We'll put the question. You have one minute to answer. OK. So the question is that when mining different projects, we found similar idioms. Actually, this is a nice question. And it still depends what is an idiom for you. Because for example, I could say that one of the examples for an idiom is that let's say that you have a project in Java 8. You would like to go into a new feature that you have in Java 9. That what you can say is that, OK, if I mine projects that are moving from one version to another, I will find this idiom. So if you think that that is an idiom, then you will find this kind of idiom across projects. But there are some idioms that are very peculiar about, and they are really about the developers that are implementing the project. So in these cases, you will not find them. Great. So well done. Thank you very much. Thank you. Thank you. Thank you. Thank you. All right. So you have water. You're not throwing on your laptop. OK. Easy. OK. No, there's more here. OK. OK. OK. What's that? What's that? What's that? What's that in the light? OK. OK. And how much? I want to eat. Oh, I can't imagine. Do you want some? No, thank you. I will finish the presentation. presentation. I'm going to take a second. I'm going to take a second.
 Okay, cool.  So next up, so one more last for the year.  Thank you, everyone.  Thank you for being here.  So I'm Dadyo Dinucci.  I'm a research fellow here in Brassos.  So actually, I didn't work a lot to arrive here.  But I work in the sister university of Welby.  So I work in the Frey University of Brassos.  If you've been in Brassos for a couple of days,  you know some stories about Brassos.  I've never been in Brassos.  So today, I'm going to talk with you  about mining source code, about mining idiom,  usages, and edits.  Actually, I will show you that these different aspects  in reality have a lot in common.  And I will try to show you the limitation  that we have in applying these kind of techniques.  But also, the novelty of applying these kind of techniques  and the advantages that we could have  in a few years of research.  So actually, I'm a Sunday researcher in Europe.  So I moved a bit during my life.  I'm not Belgian.  I'm Italian.  I'm an Italian from the South.  But then during the last years, I was in a working depth.  And after a while, I moved to Brassos.  So today, I'm going to talk with you  about mining software repositories.  We could think about that a software repository is just  a Git repository or maybe an issue tracker.  But actually, when we talk about software repositories,  we talk about not only versioning systems and issue  tracker, but also about marketplaces or about communication  in which you developers use all your information.  So actually, what we would like to do  is to gather this information to mine these repositories just  to extract this data and to create a common history  for a software project.  So after having all this information,  what we can do is that we can, for example,  apply machine learning techniques.  And today, you heard a lot about this.  But why we need this?  Because actually, if you think about,  you are providing a lot of data to public repositories.  But there is something that these repositories can do for you.  And actually, this is what we are trying to do.  So actually, we are trying to get all your information  but just to help you.  So to provide you some information  that you can use so that you can reduce the time that you  spend coding your projects.  Actually, because no one likes to debug the silly mistakes.  So last year in Brussels, we started a collaboration  with a company that is called Rincut  and is based in Brussels.  So the goal, actually, Rincut is a company  that is working on compilers.  So they are very good in modernized software languages.  And maybe it seems to be a bit strange.  But even if today we have really modern languages,  we have really a lot of code that actually  is still in legacy code.  So actually, we are trying to help Rincut people  to modernize languages.  Because actually, this is an important market.  There is a growing needed to have this kind of techniques.  But one of the problems is that today, what Rincut  the people are doing is pretty much manually.  So they are doing everything manually.  Without any IDE or any to support.  And for example, just to understand the complexity  of what they are doing, in some cases,  they are trying to replicate the behavior of a compiler  without running the compiler.  So you have some code.  You try to understand how this code really works.  And we are talking about a code or something  that is stranger than a code.  And then you have to modernize this code to something  that you can run on Azure or on your cloud or something like  this.  I'm talking about Azure because Rincut works with Microsoft.  So the goal of this project is actually  to automate the migration that requires pattern discovery.  But for doing this, we are trying  to mine three different use cases for three different  objectives.  So going in details, I will show you  that actually mining codidiums or mining library  usages or mining systematic edits.  Now I will tell you what I'm talking about.  It's not very different.  But why we are trying to do this?  So first of all, we would like to comprehend these programs.  Because the first issue that you have when  you work with legacy code is just  to understand what the code is doing.  Then what we would like to do is to do some anomaly detection.  So actually, if you have a large code base, maybe,  starting from a new piece of code,  you can understand if you are making a mistake.  But what is very our final goal is  to build a full modernization assistance that actually  is able to tell you which mistakes you are making  and to create a better language without a lot of effort.  So to transpose your code from one language to another.  So our approach is actually divided in three different steps.  The first step is actually only to import the code.  Because our idea is that these assistance  should be language parameter, so parametric.  So what we would like to do is to have a common framework that  is able to work with different languages, not only COBOL,  not only Java, not only Python, but to have a common framework.  For doing this, we need a meta model.  Actually, this meta model should be  able to gather the information and to provide them  this information to our algorithms, our pattern mining  algorithms.  But first of all, we have to work on importing this data.  To import this data, actually, at this point of our project,  we have different importers.  For example, we are able to import Java code from open source  projects.  But we are also able to import legacy systems.  For example, we are able to import COBOL code.  The second step after having this common meta model  is to run our pattern mining algorithm.  I will show you briefly.  In theory, it seems that everything is easy.  That we have everything that is needed to deal  with this kind of issue.  But in practice, I will show you that it's not so easy.  And maybe we have to work several years on this.  And then the third part is actually  to provide the patterns that we're able to mine to developers  so that developers can really understand  if there are some common usages for our library  or whether there are some syntactic idioms.  Or for example, whether some commits are repetitive.  So first of all, I will just provide you  some information about idioms.  Actually, this morning, Miltos was talking about idioms.  Anedium is just a syntactic fragment  that recourse across software projects  and serves a single semantic purpose.  Actually, this definition is a bit bug.  Because it's a bit hard to understand what is really an idiom.  But let's try to just find a simple example.  So in this case, we have three different pieces of code.  You see that in all these pieces of code, you have a try.  Then you have a condition.  And in this condition, you are invoking the method  move to first.  Then you have a body, which we are doing something.  And then finally, you have the final for the exception.  And then you close these objects.  So as you can see in the end, these three pieces of code,  they are doing actually the same.  So and you can generalize these three pieces of code  with this idiom.  And maybe when you have to modernize  and to move from a version of your system to another,  you can use this kind of information.  Now, the problem is that actually,  we are talking about only three pieces of code.  And actually, it's pretty straightforward  to understand that these three pieces of code  are something in common.  But when we talk about ecosystems,  when we talk about huge software repositories,  in the end, we find out that it's not so easy.  And of course, a developer could not do something like this.  So the idea, if we would like to apply a really theoretical  approach, is just to run a frequent item set algorithm.  So in theory, this problem is not very hard to solve.  Because what we can do is that from a piece of code,  we just create a representation with that three  because based on the code, you can just  create an abstract syntax tree.  And then you can run your algorithm maybe  without any problem.  But in practice, when you run it,  you discover that most of the idioms that you find out,  in the end, are not so interesting.  In the end, they are boring.  And we're boring.  We mean that, OK, if I tell you that given a Java class,  a Java class is composed by attributes and methods,  then you say that, OK, this is not so interesting.  It's not something that is new.  We know about it.  But the problem is that actually,  it's led that you have a trade-off.  I mean, from a point of view, you  would like to discover very particular, very tricky idioms.  But from the other point of view,  you have that after a while, your search just explodes.  So in the end, you are not able to gather patterns.  And most of the cases, you have only auto-memory issues.  So you cannot really do anything.  So what we are trying to do is to explore  novel pattern-mining arguments for source code.  And then we are going to incorporate  this information in our tool.  So actually, there are various applications  that you can use for mining when you mine code idioms.  First of all, you could discover new syntactic pattern.  Then you could discover a code that  is deviated from a pattern.  And then you can propose new actions to developers.  So this is the overview of our framework.  So as I was telling you in the general view,  we have a source code importer that  is able to gather this information  in a common representation.  Then we have some mining preprocessors  that helps us to clean up the representations.  And then we have the pattern miner.  Actually, it's important to say that now we  are running a pretty simple algorithm that  is frequently mining.  But we are trying to explore all the possibilities  that you have with this kind of algorithm.  So in the end, using the algorithm per se  is not very hard.  But adapt this kind of algorithm to our case study  is not so easy.  Also, because you have to remember that it's true  that we are talking about, at least now  for the first year of our project,  we are talking about Java projects.  But in theory, we would like to apply this knowledge  to all the languages.  So one of the problems is that after that you set up  your algorithm, maybe your algorithm  will work just for your case study, a realy small case  study.  I will not generalize it all.  So after having our pattern miner,  and actually we are exploring different kinds of algorithms,  the second step, the fourth step is the pattern match.  So after mining a lot of patterns,  what you can do is that to apply your match  to discover if in another piece of code  you have these patterns.  And only after these, you can provide this information  to the developers so that actually the developers will  able to improve their code base.  So the first problem of this kind of application  is that it's highly time consuming.  And tweaking the algorithm is not so easy.  A really something that is maybe in some cases  very people don't consider about much learning  is that really every, every, every small detail matter.  And changing a bit the configuration  means that in the end you are going  to spend a lot of execution time.  And maybe after spending all this time,  there is such that you will have are not very useful.  So another problem that you have is that in some cases,  we are able to generate really a large amount of patterns,  as well as redundant patterns.  Some patterns are more related to the grammar of the language  and not about the use of the language.  So what we are trying to do is that to solve these issues,  we are trying to put some constraints that  help to reduce the search space.  Actually, the search space in our case is very, very large.  But we are trying to fix these kind of issues.  Another problem is that the setting constraints  is not so straightforward.  I mean, really every detail matter,  and setting these details is not so easy.  Another issue, the last one, is that evaluating,  maybe the most important issue is  that evaluating the patterns is not easy at all.  I mean, one of the issues that we had in the first year  is that we were able to mine patterns.  But in the end, even saying what is boring  and what is interesting is not so easy.  So it means that maybe after hours of computation,  we are going to have a lot of patterns,  but you don't know whether they are useful or not.  And if you don't know this, it means  that you are not able to tweak your algorithm.  So in summary, we developed a language parameter framework  to mine co-digms.  Now we are running this kind of algorithm.  And we are doing some work in progress  to reduce the search space, applying  heuristics and constraints.  And we are trying to understand the real value of idioms  to improve the mining process.  The second part of my presentation is about mining usages.  Now you know the difference between libraries and frameworks.  So libraries are different by frameworks,  because if you would like to use a library,  you just need to understand the API and to use the APIs.  While if you would like to use a framework,  actually what you have to do is that you have to implement  or to extend some parts of the framework.  Now one of the issues that you have today with framework  is that from the point of view of the developer,  actually you don't know how to use a framework  and how to correctly extend a framework given a functionality.  So actually what you do today is that you just  take your framework and you start  analyzing the different way in which this framework could  fit your test study.  So first of all, from the developer point of view,  we would like to understand how you should  extend a given framework.  But also another problem that you have in this case  when you try to mine libraries is that from the maintainer  of the framework point of view, actually  the maintainer doesn't know anything  about how people are using his library.  So in the end, it's possible that if you are a maintainer  of a library and you would like to remove a functionality that  maybe no one is using, in the end you don't know this.  I mean, you based on comments or based on what is your opinion,  you are going to add or remove APIs.  But in the end, you don't know what  will be the impact of your change.  So when you would like to extend a framework, what you have,  and this is a definition that is from a paper of a few years  ago, is that you have an extension point that  is the part that you should extend,  and then you have a usage that actually  defines how you are going to extend your framework.  But there are different kind of extension point.  For example, a really simple extension point  is the one in which actually in your code base,  you're just using a method.  This is the easiest thing.  And actually, if you think about this,  extending a framework in this way  is not very different to use a library.  The second thing that you will do is that you not only use  a method, but you also customize this method  before using it.  The third way is that you actually  extend a class providing new functionalities.  Now, if you have a look to this picture,  this is another work that we, and another part of Intimal  from which we are working on.  And then it seems that the framework  is different with respect to the previous version  that I showed you.  But if you think about it, it's not very different.  Because in every case, we need an importer,  and then we need a miner, and then we need a matcher,  and then afterwards, we need a visualization tool.  So this is for telling you that in the end, when  you try to mine different aspects of the source code,  in most of the cases, there are not so many difference,  at least from a really high point of view.  Now, we performed a case study in which we developed  an importer for Scala.  So first of all, we are able to mine the source code.  We are able to tag each part of the source code.  And based on this tagging, what we are able  is that, first of all, we are able to extract all the data  that we need.  So we are going, we clone the projects,  then we compile the projects, we do type resolution,  and just after this, we are able to understand  which are the extension points.  After this part, we run our miner.  With respect to the previous approach,  in this case, we run a subgraph mining algorithm.  That is a priori.  And then we visualize the data.  But what is important is that, also in this case,  we tried to evaluate our approach,  mining several projects from Scala.  We mined five different frameworks, so Spark,  Kamokito, Adoop, and Play.  Naturally, we saw something that was pretty much interesting.  First of all, we saw that mining these kind of patterns  is not very hard, but also the accuracy of these patterns.  In the end, it's very high.  I mean, in most of the cases, we had that the accuracy  was about 90 something percent.  But one thing that, for example, we are not expecting  is that in most of the cases, to extend a given class,  you don't have a lot of extension points.  So in most of the cases, given a class,  you have at most four extension points.  And also, we discovered that applying our miner,  most of the patterns that we were able to find  were pretty much simple.  So from this point of view, you can understand that,  as I told you before, you have a trade-off.  The trade-off is that, on the one end,  you have that your patterns could be simple.  On the other end, you have the accuracy.  So the higher the accuracy, the simpler the patterns.  But this also means that what we have to do in the future  is that we have to try to gather some patterns that  are more complicated.  This means that maybe our accuracy will start failing.  But it's also true that, as a developer,  you care about complex patterns.  Because if you are going to use a library,  you don't need this kind of technology  if the extension is easy.  Last, I will talk to you about mining edits.  So until this point, we'll talk about snapshots.  So you have your snapshot.  You analyze your snapshot.  From your snapshot, you analyze your snapshot  from a syntactic point of view or from the point of view  of a given library or a given framework.  Now, when we talk about systematic edits,  we are talking about comments.  So what we would like to do is that we  will let's consider a repository.  And in this repository, we have these changes,  and then these changes, and then these changes.  So we have three instances of a change.  But in the end, we have only one systematic edit.  So actually, it could be interesting to know about these  changes, because what we will do is that if we have a new  change and the change is different,  we expect that the systematic changes,  it's probable that actually we are going to add a bug.  So systematic edits can be tedious,  and of course, manually mining this data is very hard,  because you can just add errors.  Now, what we did is that we proposed the atull.  They actually, based on a software project in Java,  is able to mine all the story of a project,  and is able to, it represents the source code changes  as ST nodes, and is able to apply a frequent item set  mining that is a bit different with respect  to the first that I showed you in the previous slides.  Now, the applications are similar to the one  that I showed you before.  So first of all, you would like to detect error-prone code,  then you would like to assist the developers.  And the best thing would be to generate automatically  some transformation based on existing instances.  So in this case, the approach is a bit different,  because we don't start from a snapshot,  but we start from a git repository  with different code revisions.  Then we apply a change distiller.  So we are able to gather all the edd scripts.  Then what we do is that, first of all, we group these edd  scripts, then we apply an equivalent script, create  idea, and all in the end, we apply our frequent item set  mining algorithm.  Now, let's consider an example, because it's much easier  to understand.  Let's consider that we have this commit.  So in this commit, we are adding two lines of code.  Actually, these two lines of code are more or less the same.  There's only a really small change.  Now, so what we are doing?  First of all, we are inserting an if statement.  Then we are inserting a method invocation.  Afterwards, we are adding a dis-expression.  And then we are computing the equals on the argument  that is the TCP.  Afterwards, we are returning an integer.  Now, we can say that we have two different groups of changes.  This one and this other one.  But in the end, these two groups are doing the same.  Now, what is the grouping criteria?  First of all, what we are going to do  is to group the changes into transaction.  Actually, what we do is that we group the changes based  on the method in which they are.  So we are going to have these two groups.  Of course, there are some limitations in this approach,  because our approach could be a bit naive in some cases.  For example, because we are excluding changes that  occur across different methods.  The second thing is to understand that given  two different group of changes, is to understand  if they are the same.  Otherwise, we cannot compute the ed script.  Now, the change equivalence criteria  is based on the change type, the subject, and the context.  The change type is pretty much easy to understand,  because for example, in the case before,  we are adding a line of code.  So in the end, this is an insert.  So given this edit, in the end, we know that this is the subject.  And actually, what we do is that we anonymize the identifiers,  just because otherwise it's hard to gather together  the patterns.  And then finally, we define the context.  But the context, if you think about,  is just the place in which the subject occurs.  So given these two group of changes,  we transform the edits in this kind of representation.  What we did is that we evaluate the correctness of the tool.  And actually, we applied it to our code base of our company  that is in Belgium.  We mined different repositories from Android projects.  Actually, and it's important to say that, for really understand  if our ed scripts were correct or not,  we had to manually evaluate the scripts.  And as I told you before, this is something  that you always have to do.  I mean, one of the problems in doing research in academia  is that actually, sometimes, we don't have real developers.  And so it's a bit tricky, but in the end,  we try to be developers.  So what we understand from this study  is that, first of all, in most of the cases,  you have that the majority of systematic edits  have few instances.  So in the end, you see that, and this  one of the problems of applying our mining algorithm  is having a few instances.  It means that you have to spend more computational effort.  Then another problem, because you cannot cut the search,  then another problem is that in most of the cases,  you see that on average, three or four ST level changes  disregard the number of instances.  So you have that larger instance size  can occur with the small number of instances.  So in summary, we have a technique  that is able to identify systematic edits.  In most of the cases, we see that in 12.5% of commits,  they contain systematic edits.  And mostly, all these instances are pretty, pretty much small,  but they can have a large size.  As a future work, we are trying to explore  the different configurations.  And we are trying to mine for the specific type  or systematic edits.  And also, we are trying to mine across commits.  Because one of the problems that we have today  is that we mine a single commit per time.  So if we have changes that are across commits,  we are not able to mine this kind of information.  Thank you.  Have you studied any pattern of good practices or bad practices  in terms of number of times they've been removed  or added in a code base?  Can you carry out any questions?  Yeah, the question is that when we were studying systematic  edits, if we see people?  If you notice any pattern of add-ins,  you can say, OK, this is a good practice.  Because if you've been added a lot of time,  this is a bad practice because it's already  removed.  So the question is that if we were  able to mine some best practice across the systematic edits,  actually, this is an ask question.  And actually, it's the final goal of this kind of study.  I mean, the final goal is to understand  if there are some best practice that you can apply everywhere.  But what you have to understand is  that in most of the cases for systematic edits,  you have really a small number of instances.  It means that if you mine a software repository,  you have, for example, for a systematic editor,  you have three instances.  For example, in this case, we saw that for 2,500  systematic edits, you have only three instances.  So this cannot be our best practice.  But one of the problems is that one of the problems  applying this kind of technique is scalability.  Because what we were doing is that for each project,  we are going through the history.  And we were analyzing all the history of just one project  per time.  Now, what you should do for having an information like that  is that you should mine a complete ecosystem  so that you should be able to understand  whether there are some best practice  that different developers are applying.  Because in our case, most of the repositories are,  I mean, most of the people that work on a repository  are not a lot.  I mean, in most of the cases, you  don't have thousands of developers.  So it's really hard to mine a best practice  that you could apply everywhere.  10.  Depending on your project, you found different videos  applying to the same thing.  You find that?  Different videos that apply to the same thing.  OK, so the.  We'll put the question.  You have one minute to answer.  OK.  So the question is that when mining different projects,  we found similar idioms.  Actually, this is a nice question.  And it still depends what is an idiom for you.  Because for example, I could say that one of the examples  for an idiom is that let's say that you have a project in Java  8.  You would like to go into a new feature  that you have in Java 9.  That what you can say is that, OK,  if I mine projects that are moving from one version  to another, I will find this idiom.  So if you think that that is an idiom,  then you will find this kind of idiom across projects.  But there are some idioms that are very peculiar about,  and they are really about the developers that  are implementing the project.  So in these cases, you will not find them.  Great.  So well done.  Thank you very much.  Thank you.  Thank you.  Thank you.  Thank you.  All right.  So you have water.  You're not throwing on your laptop.  OK.  Easy.  OK.  No, there's more here.  OK.  OK.  OK.  What's that?  What's that?  What's that?  What's that in the light?  OK.  OK.  And how much?  I want to eat.  Oh, I can't imagine.  Do you want some?  No, thank you.  I will finish the presentation.  presentation. I'm going to take a second.  I'm going to take a second.
Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_0_143.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_144_1931.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_1932_2459.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_2460_2843.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_2844_3335.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_3336_4667.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_4668_7487.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_7488_7991.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_7992_8387.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_8388_9575.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_9576_12695.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_12696_12983.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_12984_13211.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_13212_13391.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_13392_13487.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_13488_15239.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_15240_19043.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_19044_25511.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_25512_26135.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_26136_26843.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_26844_29147.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_29148_29327.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_29328_29375.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_29376_29807.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_29808_30575.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_30576_30755.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_30756_31895.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_31896_32339.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_32340_32423.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_32424_33203.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_33204_33263.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_33264_33695.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_33696_34223.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_34224_34715.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_34716_36383.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_36384_36611.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_36612_39659.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_39660_40463.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_40464_40991.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_40992_42083.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_42084_42131.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_42132_42215.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_42216_42575.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_42576_43187.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_43188_43919.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_43920_46595.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_46596_47375.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_47376_49319.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_49320_55619.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_55620_55679.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_55680_55835.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_55836_55907.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_55908_56291.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_56292_56375.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_56376_56471.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_56472_56627.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_56628_59507.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_59508_59555.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_59556_60119.png Mining_Source_Code_3_Mining_Idioms__Usages_and_Edits_-yYpwL_TDz8_60120_60233.png
Okay, cool. So next up, so one more last for the year. Thank you, everyone. Thank you for being here. So I'm Dadyo Dinucci. I'm a research fellow here in Brassos. So actually, I didn't work a lot to arrive here. But I work in the sister university of Welby. So I work in the Frey University of Brassos. If you've been in Brassos for a couple of days, you know some stories about Brassos. I've never been in Brassos. So today, I'm going to talk with you about mining source code, about mining idiom, usages, and edits. Actually, I will show you that these different aspects in reality have a lot in common. And I will try to show you the limitation that we have in applying these kind of techniques. But also, the novelty of applying these kind of techniques and the advantages that we could have in a few years of research. So actually, I'm a Sunday researcher in Europe. So I moved a bit during my life. I'm not Belgian. I'm Italian. I'm an Italian from the South. But then during the last years, I was in a working depth. And after a while, I moved to Brassos. So today, I'm going to talk with you about mining software repositories. We could think about that a software repository is just a Git repository or maybe an issue tracker. But actually, when we talk about software repositories, we talk about not only versioning systems and issue tracker, but also about marketplaces or about communication in which you developers use all your information. So actually, what we would like to do is to gather this information to mine these repositories just to extract this data and to create a common history for a software project. So after having all this information, what we can do is that we can, for example, apply machine learning techniques. And today, you heard a lot about this. But why we need this? Because actually, if you think about, you are providing a lot of data to public repositories. But there is something that these repositories can do for you. And actually, this is what we are trying to do. So actually, we are trying to get all your information but just to help you. So to provide you some information that you can use so that you can reduce the time that you spend coding your projects. Actually, because no one likes to debug the silly mistakes. So last year in Brussels, we started a collaboration with a company that is called Rincut and is based in Brussels. So the goal, actually, Rincut is a company that is working on compilers. So they are very good in modernized software languages. And maybe it seems to be a bit strange. But even if today we have really modern languages, we have really a lot of code that actually is still in legacy code. So actually, we are trying to help Rincut people to modernize languages. Because actually, this is an important market. There is a growing needed to have this kind of techniques. But one of the problems is that today, what Rincut the people are doing is pretty much manually. So they are doing everything manually. Without any IDE or any to support. And for example, just to understand the complexity of what they are doing, in some cases, they are trying to replicate the behavior of a compiler without running the compiler. So you have some code. You try to understand how this code really works. And we are talking about a code or something that is stranger than a code. And then you have to modernize this code to something that you can run on Azure or on your cloud or something like this. I'm talking about Azure because Rincut works with Microsoft. So the goal of this project is actually to automate the migration that requires pattern discovery. But for doing this, we are trying to mine three different use cases for three different objectives. So going in details, I will show you that actually mining codidiums or mining library usages or mining systematic edits. Now I will tell you what I'm talking about. It's not very different. But why we are trying to do this? So first of all, we would like to comprehend these programs. Because the first issue that you have when you work with legacy code is just to understand what the code is doing. Then what we would like to do is to do some anomaly detection. So actually, if you have a large code base, maybe, starting from a new piece of code, you can understand if you are making a mistake. But what is very our final goal is to build a full modernization assistance that actually is able to tell you which mistakes you are making and to create a better language without a lot of effort. So to transpose your code from one language to another. So our approach is actually divided in three different steps. The first step is actually only to import the code. Because our idea is that these assistance should be language parameter, so parametric. So what we would like to do is to have a common framework that is able to work with different languages, not only COBOL, not only Java, not only Python, but to have a common framework. For doing this, we need a meta model. Actually, this meta model should be able to gather the information and to provide them this information to our algorithms, our pattern mining algorithms. But first of all, we have to work on importing this data. To import this data, actually, at this point of our project, we have different importers. For example, we are able to import Java code from open source projects. But we are also able to import legacy systems. For example, we are able to import COBOL code. The second step after having this common meta model is to run our pattern mining algorithm. I will show you briefly. In theory, it seems that everything is easy. That we have everything that is needed to deal with this kind of issue. But in practice, I will show you that it's not so easy. And maybe we have to work several years on this. And then the third part is actually to provide the patterns that we're able to mine to developers so that developers can really understand if there are some common usages for our library or whether there are some syntactic idioms. Or for example, whether some commits are repetitive. So first of all, I will just provide you some information about idioms. Actually, this morning, Miltos was talking about idioms. Anedium is just a syntactic fragment that recourse across software projects and serves a single semantic purpose. Actually, this definition is a bit bug. Because it's a bit hard to understand what is really an idiom. But let's try to just find a simple example. So in this case, we have three different pieces of code. You see that in all these pieces of code, you have a try. Then you have a condition. And in this condition, you are invoking the method move to first. Then you have a body, which we are doing something. And then finally, you have the final for the exception. And then you close these objects. So as you can see in the end, these three pieces of code, they are doing actually the same. So and you can generalize these three pieces of code with this idiom. And maybe when you have to modernize and to move from a version of your system to another, you can use this kind of information. Now, the problem is that actually, we are talking about only three pieces of code. And actually, it's pretty straightforward to understand that these three pieces of code are something in common. But when we talk about ecosystems, when we talk about huge software repositories, in the end, we find out that it's not so easy. And of course, a developer could not do something like this. So the idea, if we would like to apply a really theoretical approach, is just to run a frequent item set algorithm. So in theory, this problem is not very hard to solve. Because what we can do is that from a piece of code, we just create a representation with that three because based on the code, you can just create an abstract syntax tree. And then you can run your algorithm maybe without any problem. But in practice, when you run it, you discover that most of the idioms that you find out, in the end, are not so interesting. In the end, they are boring. And we're boring. We mean that, OK, if I tell you that given a Java class, a Java class is composed by attributes and methods, then you say that, OK, this is not so interesting. It's not something that is new. We know about it. But the problem is that actually, it's led that you have a trade-off. I mean, from a point of view, you would like to discover very particular, very tricky idioms. But from the other point of view, you have that after a while, your search just explodes. So in the end, you are not able to gather patterns. And most of the cases, you have only auto-memory issues. So you cannot really do anything. So what we are trying to do is to explore novel pattern-mining arguments for source code. And then we are going to incorporate this information in our tool. So actually, there are various applications that you can use for mining when you mine code idioms. First of all, you could discover new syntactic pattern. Then you could discover a code that is deviated from a pattern. And then you can propose new actions to developers. So this is the overview of our framework. So as I was telling you in the general view, we have a source code importer that is able to gather this information in a common representation. Then we have some mining preprocessors that helps us to clean up the representations. And then we have the pattern miner. Actually, it's important to say that now we are running a pretty simple algorithm that is frequently mining. But we are trying to explore all the possibilities that you have with this kind of algorithm. So in the end, using the algorithm per se is not very hard. But adapt this kind of algorithm to our case study is not so easy. Also, because you have to remember that it's true that we are talking about, at least now for the first year of our project, we are talking about Java projects. But in theory, we would like to apply this knowledge to all the languages. So one of the problems is that after that you set up your algorithm, maybe your algorithm will work just for your case study, a realy small case study. I will not generalize it all. So after having our pattern miner, and actually we are exploring different kinds of algorithms, the second step, the fourth step is the pattern match. So after mining a lot of patterns, what you can do is that to apply your match to discover if in another piece of code you have these patterns. And only after these, you can provide this information to the developers so that actually the developers will able to improve their code base. So the first problem of this kind of application is that it's highly time consuming. And tweaking the algorithm is not so easy. A really something that is maybe in some cases very people don't consider about much learning is that really every, every, every small detail matter. And changing a bit the configuration means that in the end you are going to spend a lot of execution time. And maybe after spending all this time, there is such that you will have are not very useful. So another problem that you have is that in some cases, we are able to generate really a large amount of patterns, as well as redundant patterns. Some patterns are more related to the grammar of the language and not about the use of the language. So what we are trying to do is that to solve these issues, we are trying to put some constraints that help to reduce the search space. Actually, the search space in our case is very, very large. But we are trying to fix these kind of issues. Another problem is that the setting constraints is not so straightforward. I mean, really every detail matter, and setting these details is not so easy. Another issue, the last one, is that evaluating, maybe the most important issue is that evaluating the patterns is not easy at all. I mean, one of the issues that we had in the first year is that we were able to mine patterns. But in the end, even saying what is boring and what is interesting is not so easy. So it means that maybe after hours of computation, we are going to have a lot of patterns, but you don't know whether they are useful or not. And if you don't know this, it means that you are not able to tweak your algorithm. So in summary, we developed a language parameter framework to mine co-digms. Now we are running this kind of algorithm. And we are doing some work in progress to reduce the search space, applying heuristics and constraints. And we are trying to understand the real value of idioms to improve the mining process. The second part of my presentation is about mining usages. Now you know the difference between libraries and frameworks. So libraries are different by frameworks, because if you would like to use a library, you just need to understand the API and to use the APIs. While if you would like to use a framework, actually what you have to do is that you have to implement or to extend some parts of the framework. Now one of the issues that you have today with framework is that from the point of view of the developer, actually you don't know how to use a framework and how to correctly extend a framework given a functionality. So actually what you do today is that you just take your framework and you start analyzing the different way in which this framework could fit your test study. So first of all, from the developer point of view, we would like to understand how you should extend a given framework. But also another problem that you have in this case when you try to mine libraries is that from the maintainer of the framework point of view, actually the maintainer doesn't know anything about how people are using his library. So in the end, it's possible that if you are a maintainer of a library and you would like to remove a functionality that maybe no one is using, in the end you don't know this. I mean, you based on comments or based on what is your opinion, you are going to add or remove APIs. But in the end, you don't know what will be the impact of your change. So when you would like to extend a framework, what you have, and this is a definition that is from a paper of a few years ago, is that you have an extension point that is the part that you should extend, and then you have a usage that actually defines how you are going to extend your framework. But there are different kind of extension point. For example, a really simple extension point is the one in which actually in your code base, you're just using a method. This is the easiest thing. And actually, if you think about this, extending a framework in this way is not very different to use a library. The second thing that you will do is that you not only use a method, but you also customize this method before using it. The third way is that you actually extend a class providing new functionalities. Now, if you have a look to this picture, this is another work that we, and another part of Intimal from which we are working on. And then it seems that the framework is different with respect to the previous version that I showed you. But if you think about it, it's not very different. Because in every case, we need an importer, and then we need a miner, and then we need a matcher, and then afterwards, we need a visualization tool. So this is for telling you that in the end, when you try to mine different aspects of the source code, in most of the cases, there are not so many difference, at least from a really high point of view. Now, we performed a case study in which we developed an importer for Scala. So first of all, we are able to mine the source code. We are able to tag each part of the source code. And based on this tagging, what we are able is that, first of all, we are able to extract all the data that we need. So we are going, we clone the projects, then we compile the projects, we do type resolution, and just after this, we are able to understand which are the extension points. After this part, we run our miner. With respect to the previous approach, in this case, we run a subgraph mining algorithm. That is a priori. And then we visualize the data. But what is important is that, also in this case, we tried to evaluate our approach, mining several projects from Scala. We mined five different frameworks, so Spark, Kamokito, Adoop, and Play. Naturally, we saw something that was pretty much interesting. First of all, we saw that mining these kind of patterns is not very hard, but also the accuracy of these patterns. In the end, it's very high. I mean, in most of the cases, we had that the accuracy was about 90 something percent. But one thing that, for example, we are not expecting is that in most of the cases, to extend a given class, you don't have a lot of extension points. So in most of the cases, given a class, you have at most four extension points. And also, we discovered that applying our miner, most of the patterns that we were able to find were pretty much simple. So from this point of view, you can understand that, as I told you before, you have a trade-off. The trade-off is that, on the one end, you have that your patterns could be simple. On the other end, you have the accuracy. So the higher the accuracy, the simpler the patterns. But this also means that what we have to do in the future is that we have to try to gather some patterns that are more complicated. This means that maybe our accuracy will start failing. But it's also true that, as a developer, you care about complex patterns. Because if you are going to use a library, you don't need this kind of technology if the extension is easy. Last, I will talk to you about mining edits. So until this point, we'll talk about snapshots. So you have your snapshot. You analyze your snapshot. From your snapshot, you analyze your snapshot from a syntactic point of view or from the point of view of a given library or a given framework. Now, when we talk about systematic edits, we are talking about comments. So what we would like to do is that we will let's consider a repository. And in this repository, we have these changes, and then these changes, and then these changes. So we have three instances of a change. But in the end, we have only one systematic edit. So actually, it could be interesting to know about these changes, because what we will do is that if we have a new change and the change is different, we expect that the systematic changes, it's probable that actually we are going to add a bug. So systematic edits can be tedious, and of course, manually mining this data is very hard, because you can just add errors. Now, what we did is that we proposed the atull. They actually, based on a software project in Java, is able to mine all the story of a project, and is able to, it represents the source code changes as ST nodes, and is able to apply a frequent item set mining that is a bit different with respect to the first that I showed you in the previous slides. Now, the applications are similar to the one that I showed you before. So first of all, you would like to detect error-prone code, then you would like to assist the developers. And the best thing would be to generate automatically some transformation based on existing instances. So in this case, the approach is a bit different, because we don't start from a snapshot, but we start from a git repository with different code revisions. Then we apply a change distiller. So we are able to gather all the edd scripts. Then what we do is that, first of all, we group these edd scripts, then we apply an equivalent script, create idea, and all in the end, we apply our frequent item set mining algorithm. Now, let's consider an example, because it's much easier to understand. Let's consider that we have this commit. So in this commit, we are adding two lines of code. Actually, these two lines of code are more or less the same. There's only a really small change. Now, so what we are doing? First of all, we are inserting an if statement. Then we are inserting a method invocation. Afterwards, we are adding a dis-expression. And then we are computing the equals on the argument that is the TCP. Afterwards, we are returning an integer. Now, we can say that we have two different groups of changes. This one and this other one. But in the end, these two groups are doing the same. Now, what is the grouping criteria? First of all, what we are going to do is to group the changes into transaction. Actually, what we do is that we group the changes based on the method in which they are. So we are going to have these two groups. Of course, there are some limitations in this approach, because our approach could be a bit naive in some cases. For example, because we are excluding changes that occur across different methods. The second thing is to understand that given two different group of changes, is to understand if they are the same. Otherwise, we cannot compute the ed script. Now, the change equivalence criteria is based on the change type, the subject, and the context. The change type is pretty much easy to understand, because for example, in the case before, we are adding a line of code. So in the end, this is an insert. So given this edit, in the end, we know that this is the subject. And actually, what we do is that we anonymize the identifiers, just because otherwise it's hard to gather together the patterns. And then finally, we define the context. But the context, if you think about, is just the place in which the subject occurs. So given these two group of changes, we transform the edits in this kind of representation. What we did is that we evaluate the correctness of the tool. And actually, we applied it to our code base of our company that is in Belgium. We mined different repositories from Android projects. Actually, and it's important to say that, for really understand if our ed scripts were correct or not, we had to manually evaluate the scripts. And as I told you before, this is something that you always have to do. I mean, one of the problems in doing research in academia is that actually, sometimes, we don't have real developers. And so it's a bit tricky, but in the end, we try to be developers. So what we understand from this study is that, first of all, in most of the cases, you have that the majority of systematic edits have few instances. So in the end, you see that, and this one of the problems of applying our mining algorithm is having a few instances. It means that you have to spend more computational effort. Then another problem, because you cannot cut the search, then another problem is that in most of the cases, you see that on average, three or four ST level changes disregard the number of instances. So you have that larger instance size can occur with the small number of instances. So in summary, we have a technique that is able to identify systematic edits. In most of the cases, we see that in 12.5% of commits, they contain systematic edits. And mostly, all these instances are pretty, pretty much small, but they can have a large size. As a future work, we are trying to explore the different configurations. And we are trying to mine for the specific type or systematic edits. And also, we are trying to mine across commits. Because one of the problems that we have today is that we mine a single commit per time. So if we have changes that are across commits, we are not able to mine this kind of information. Thank you. Have you studied any pattern of good practices or bad practices in terms of number of times they've been removed or added in a code base? Can you carry out any questions? Yeah, the question is that when we were studying systematic edits, if we see people? If you notice any pattern of add-ins, you can say, OK, this is a good practice. Because if you've been added a lot of time, this is a bad practice because it's already removed. So the question is that if we were able to mine some best practice across the systematic edits, actually, this is an ask question. And actually, it's the final goal of this kind of study. I mean, the final goal is to understand if there are some best practice that you can apply everywhere. But what you have to understand is that in most of the cases for systematic edits, you have really a small number of instances. It means that if you mine a software repository, you have, for example, for a systematic editor, you have three instances. For example, in this case, we saw that for 2,500 systematic edits, you have only three instances. So this cannot be our best practice. But one of the problems is that one of the problems applying this kind of technique is scalability. Because what we were doing is that for each project, we are going through the history. And we were analyzing all the history of just one project per time. Now, what you should do for having an information like that is that you should mine a complete ecosystem so that you should be able to understand whether there are some best practice that different developers are applying. Because in our case, most of the repositories are, I mean, most of the people that work on a repository are not a lot. I mean, in most of the cases, you don't have thousands of developers. So it's really hard to mine a best practice that you could apply everywhere. 10. Depending on your project, you found different videos applying to the same thing. You find that? Different videos that apply to the same thing. OK, so the. We'll put the question. You have one minute to answer. OK. So the question is that when mining different projects, we found similar idioms. Actually, this is a nice question. And it still depends what is an idiom for you. Because for example, I could say that one of the examples for an idiom is that let's say that you have a project in Java 8. You would like to go into a new feature that you have in Java 9. That what you can say is that, OK, if I mine projects that are moving from one version to another, I will find this idiom. So if you think that that is an idiom, then you will find this kind of idiom across projects. But there are some idioms that are very peculiar about, and they are really about the developers that are implementing the project. So in these cases, you will not find them. Great. So well done. Thank you very much. Thank you. Thank you. Thank you. Thank you. All right. So you have water. You're not throwing on your laptop. OK. Easy. OK. No, there's more here. OK. OK. OK. What's that? What's that? What's that? What's that in the light? OK. OK. And how much? I want to eat. Oh, I can't imagine. Do you want some? No, thank you. I will finish the presentation. presentation. I'm going to take a second. I'm going to take a second.
code, about mining idiom, usages, and edits. talk with you about mining software repositories. code that actually is still in legacy code. So information to our algorithms, our pattern mining we are also able to import legacy systems. For our library or whether there are some syntactic to incorporate this information in our tool. So can use for mining when you mine code idioms. new actions to developers. So this is the kind of algorithm. So in the end, using the actually you don't know how to use a framework have a usage that actually defines how you are Last, I will talk to you about mining edits. So that if we have a new change and the change is it represents the source code changes as ST computing the equals on the argument that is the of code. So in the end, this is an insert. So a technique that is able to identify systematic able to mine this kind of information. Thank you. means that if you mine a software repository, you when mining different projects, we found similar