Category Archives: Academic
10 Benefits of Code Generation
Let’s get to the point. Here is the list:
- SW Quality: In every field: performance, reliability, security…
- Standarization: not only in source code but in user interface, database structures….
- Centralization: global policies such as error handling, exception management, data display format, data validation, permissions check, etc. are centralized on the generator. This kind of policies are also known as cross-cutting concerns and is an issue tackled by Aspect Oriented Programming (AOP) in traditional programming. Centralization avoids the issue.
- Refactoring: related to the previous benefit, code refactoring is easy an safe.
- Productivity: Lower cost and lower time-to-market (or release time).
- Analytical skills: code generation requires a deeper domain analysis before implementing the solution via the generator.
- Design Skills: requires a good architect with a wider view.
- Healthy Growth: prevents architecture degradation.
- Team Member Integration: development culture or rules induction are facilitated by code generation.
- Level of abstraction: programming in a more abstract way, besides easier to understand (is more intentional), opens the door to new features such as: unit test generation, self-documenting, data population, semantics, machine reasoning and others.
Code generation is not easy, implementing a generator requires time and effort, and even more if it’s a language workbench but, clearly, benefits are huge.
View all Academic Posts.
View all Academic Posts.
Best Practices in Code Generation
The most common mistake when we generate code is seeing it as a black box, thinking that the important thing is “what it does” and not “how it does it”. This is wrong. Here again, quality matters.
Here are some of the features a good generated code should have:
Here are some of the features a good generated code should have:
- Independent: manual code and generated code must be on a different file or artifact, otherwise there is a risk of losing the first one if we have to re-generate the code (and we will).
- Immutable: it must not be changed, for two reasons: is dangerous, as every unknown code, and for the same reason as the previous case.
- Readable: that means meaningful variable and function names, comments, indentation, organized in folders, files, etc. The generated code should be presentable to be visited by developers: to know how it works and, why not?, to learn from it. We should always be proud of the code we generate.
- Extensible: for different reasons you may need to implement manually some particular functionalities, so generated code should leave some doors open. The best way is to design the generated code under a Framework approach where manual code can extend only some allowed functionalities and in a safe environment.
- Structured: raising the level of abstraction requires a good knowledge of the field you are dealing with. Bad structured code can be a symptom that the domain is not completely under control. A good code generation requires a good architect.
- Robust: generated code can fail, of course. Error handling, exception management, input validation, internal validations, etc must be always included in code. This kind of security policies can be easily implemented when generating code and it must be one of the reason of its quality.
- Powerful: having said the above, we should see code generation as a way to write a more powerful code, that means that we can use some strategies in the generated code that we would never use when hand made (usually for maintenance reasons).
To sum up, best practices in code generation are a mixture of traditional best practices and a wider way of thinking.
View all Academic Posts.
View all Academic Posts.
Why Code Generation?
Code generation is not a new style or technique, it’s the path followed by programming languages to deal with complexity, from binary coding to first, second and next generation languages. It’s what compilers have been doing for ages.
The key subject here is “deal with complexity”, the more complex is your problem more abstract has to be your thinking. In other words, you need to raise the level of abstraction. And this rule applies equally to the tool used to solve the problem: the programming language.
Therefore, we can state that “raising the level of abstraction is the goal pursued by the evolution of programming languages”.
The common languages used today to solve the problems( Java, C#, C++, Delphi…), are known as general purpose languages (GPLs), and here is the problem, they are “general purpose”, it means they can solve “all” the problems but from a global perspective. They can solve them from a level of abstraction wide enough to reach the solution but not as high as we need on each particular problem. There is a gap between the level of abstraction we use to deal with the problem and the level of abstraction we use to solve it via GPLs.
How can we bridge that gap? Obviously, with code generation.
As a conclusion, to tackle properly a problem, we need to find a particular language to define the solution in the level of abstraction each particular problem requires. In order to make that solution computable, we need to generate code, usually in the nearest lower level: GPL’s.
Those particular languages are known as DSLs: Domain-Specific Languages, but this subject will be addressed in another post.
As a conclusion, we can note that this approach does not only apply to business problems but also to solving technical problems. For example, the new challenges offered desktop-web applications require a more abstract approach that integrates all technologies: HTML, CSS, JavaScrpit, AJAX and others.
View all Academic Posts.
The key subject here is “deal with complexity”, the more complex is your problem more abstract has to be your thinking. In other words, you need to raise the level of abstraction. And this rule applies equally to the tool used to solve the problem: the programming language.
Therefore, we can state that “raising the level of abstraction is the goal pursued by the evolution of programming languages”.
The common languages used today to solve the problems( Java, C#, C++, Delphi…), are known as general purpose languages (GPLs), and here is the problem, they are “general purpose”, it means they can solve “all” the problems but from a global perspective. They can solve them from a level of abstraction wide enough to reach the solution but not as high as we need on each particular problem. There is a gap between the level of abstraction we use to deal with the problem and the level of abstraction we use to solve it via GPLs.
How can we bridge that gap? Obviously, with code generation.
As a conclusion, to tackle properly a problem, we need to find a particular language to define the solution in the level of abstraction each particular problem requires. In order to make that solution computable, we need to generate code, usually in the nearest lower level: GPL’s.
Those particular languages are known as DSLs: Domain-Specific Languages, but this subject will be addressed in another post.
As a conclusion, we can note that this approach does not only apply to business problems but also to solving technical problems. For example, the new challenges offered desktop-web applications require a more abstract approach that integrates all technologies: HTML, CSS, JavaScrpit, AJAX and others.
View all Academic Posts.
Glossary
We start the academic posts series with the glossary of terms of the methodology.
- AOP
- Aspect-oriented programming is a programming paradigm which allows the separation of cross-cutting concerns. Different aspects, such as security, accounting log, notifications, etc. can be defined in isolated areas. The final comprehensive behavior of the system would be obtained using a weaving process.
- Domain
- A domain is an area, of business in our case, in which resides a particular knowledge and specific terminology to define it.
- DSL
- Domain Specific Language. Programming language designed to represent the concepts of a given domain. It can be a textual or graphical.
- FM
- Feature Model. Model to represent the communes and optional parts that can have a product of a product line. Used in PLE.
- FW
- Framework. A software framework is a reusable software platform to develop software applications. It is an abstraction where its generic functionality can be selectively changed by additional code providing application-specific software.
- LW
- Language Workbench. Tool that allows defining and using formal languages: abstract and concrete syntax and static and dynamic semantics. It could be consider as a tool for designing the language, the compiler and the IDE.
- MDA
- Model Driven Architecture. OMG standard for software development based on model. It can be considered as a particular case of MDSD.
- MDSD
- Model-driven Software Development. Programming paradigm focused on software development at the level of the models.
- Meta-model
- Rules, buildings, relationships, etc. that define the models that can build in a given domain.
- PLE
- Product Line Engineering. Discipline for the creation of software through product lines (SPL).
- SPL
- Software Product Lines. Development methodology focused on the production of software as is done in the production of other goods: sharing common processes and isolating individual ones.
View all Academic Posts.
Software Automation. Introduction.
Software development automation, as other automation processes, aims at delegating to the machine some of the tasks involved in this production process. The goal is to achieve a faster development methodology, and therefore a lower cost, and a higher quality of the final product.
SW automation has been a goal pursued previously but not very successfully. Design standards as UML or CASE tools (Computer Aided Software Engineering) have not achieved the expected results. The main cause is that they provide a generic solution (“general purpose”) to solve the set of problems faced by SW.
On the contrary, the new automation approaches provide the tools to design, in a simple and quick way, languages to describe each particular problem. It is this specific approach, not a general purpose, which has enabled success stories in sw automation.
Automation is mainly associated with code generation because, at the end of the day, the source code is the result of this production process, but we should bear in mind that, once these methodologies are used, programming moves from being a set of functional statements to become a knowledge representation where a number of disciplines, such as semantics or automated reasoning, can be applied.
We can conclude this introduction saying that throughout modern history, software has optimized every production process, now it’s time to optimize its own.
With this article we start a series where we will describe in depth this discipline and its implementation in Bheudek.
View all Academic Posts.
SW automation has been a goal pursued previously but not very successfully. Design standards as UML or CASE tools (Computer Aided Software Engineering) have not achieved the expected results. The main cause is that they provide a generic solution (“general purpose”) to solve the set of problems faced by SW.
On the contrary, the new automation approaches provide the tools to design, in a simple and quick way, languages to describe each particular problem. It is this specific approach, not a general purpose, which has enabled success stories in sw automation.
Automation is mainly associated with code generation because, at the end of the day, the source code is the result of this production process, but we should bear in mind that, once these methodologies are used, programming moves from being a set of functional statements to become a knowledge representation where a number of disciplines, such as semantics or automated reasoning, can be applied.
We can conclude this introduction saying that throughout modern history, software has optimized every production process, now it’s time to optimize its own.
With this article we start a series where we will describe in depth this discipline and its implementation in Bheudek.
View all Academic Posts.
Bheudek 