Towards Software Development
Total Page:16
File Type:pdf, Size:1020Kb
WDS'05 Proceedings of Contributed Papers, Part I, 36–40, 2005. ISBN 80-86732-59-2 © MATFYZPRESS Towards Software Development P. Panuška Charles University, Faculty of Mathematics and Physics, Prague, Czech Republic. Abstract. New approaches to software development have evolved recently. Among these belong not only development tools like IDEs, debuggers and Visual modelling tools but also new, modern1 styles of programming including Language Oriented Programming, Aspect Oriented Programming, Generative Programming, Generic Programming, Intentional Programming and others. This paper brings an overview of several methods that may help in software development. Introduction An amazing progress in software algorithms, hardware, GUI and group of problems we can solve has been made within last 40 years. Unfortunately, the same we cannot say about the way the software is actually made. The source code of programs has not changed and editors we use to edit, create and maintain computer programs still work with the source code mainly as with a piece of text. This is not the only relic remaining in current software development procedures. Software development is one of human tasks where most of the job must be done by people. Human resources belong to the most expensive, most limiting and most unreliable ones. People tend to make more mistakes than any kind of automatic machines. They must be trained, may strike, may get ill, need holidays, lunch breaks, baby breaks, etc. Universities can not produce an unlimited number of software engineers. Even if the number of technical colleges were doubled, it would not lead in double amount of high-quality programmers. Simply, human work is expensive and software development, as an example of fast-developing industry, must rely mainly on this expensive resource. Goals and structure of the paper The goal of this paper is to describe ways making the software development cheaper. There are fairly different ways to do so – ways decreasing the amount of work necessary to be done by humans; ways that would enable participation of broader cycle of people on software development; or ways helping programmers during analysing, design or implementation stages. This paper describes different approaches to software development that could meet the goals explained above. It also takes notice of poor customs involving software development and tools that may help programmers to complete their job. Approaches to Software Development There exist many ways to develop software. Besides of traditional modular, procedural and object oriented programming exist other, less common approaches. Some of these approaches towards programming are shortly described below. Language Oriented Programming Language Oriented Programming (LOP) brings a new attitude when designing applications. It tries to ease the program development by defining a new language – Domain Specific Language (DSL) by which the solution of the original problem can be described in a simpler way while the range of functions of the resulting program remain as complex as it would being programmed in a usual way. Instead of solving the problem in an existing programming language, it enables the architect to design Domain Specific Language (DSL) first. The process of simplifying the problem alsorequires a definition of transformation from the newly created language to any existing GPL (General Programming Language). 1By modern we mean not only new styles but also those methods that are being heavily researched nowadays even though they have been known or developed for many years. 36 PANUŠKA: TOWARDS SOFTWARE DEVELOPMENT Table 1. Examples of domain specific languages. Language Domain of language use SQL Relation databases queries HTML Description of static web pages UML Modelling language Perl Text processing Spreadsheet Vector/Matrix numerical operations TeX Typesetting language CAD Construction and technical design Table 2. Difference between the usual and LOP approaches. Task Implementation in GPL Compilation Execution Task Description in DSL Transformation into GPL Compilation Execution <-- Gain --> To demonstrate that the idea of domain specific languages is not new, remind any specialized language as SQL, CAD, HTML, etc. Table 1 shows several examples of DSL. As can be seen easily, these languages were designed specifically for one closed domain, however, very often the domain is much broader than we feel it should be. Other inconvenience can be that there is no simple way to create new domain specific languages. In [1] is proposed a way to handle these situations. It is suggested that a language and an editor must be designed for every single domain. The table below shows the difference between a usual way and the new attitude. It also claims there is a gain resulting from the new approach. The idea of DSL has another great benefit. It may employ a broader cycle of people in software development. Workers, called domain experts, may implement the solution in DSL although they do not know any GPL. The only condition is that the instance of DSL is understandable to them. On the other hand, such a language should be only formalized jargon used in their profession. There immediately arises a question – what if DSL design to solve a problem is more time consuming than solving the same in a traditional way. There are two responses answering this question. First of all, nowhere is written that every DSL may be used for one task only. DSL should be designed only if doing so is worthy – SQL is an instance of DSL that is used in many projects for querying of relation databases. There is another way to reduce time necessary for design of one particular DSL. A project – Meta Programming System (MPS) for easy description, model and design of new DSLs is being researched. It includes tools for defining syntax, semantics and no less importantly an editor in which newly created languages will be edited. Pay attention to the fact that MPS is also an instance of DSL. More on MPS can be found in [1]. Intentional Programming Intentional Programming (IP), on the other hand, pays attention to bad customs involving computer programming. It is commonly accepted that computer languages are not compatible with each other. Although it is possible to have an eerie feeling of deja vu or say a witty bon mot in English, using HTML tags in C/C++ is not always possible2. A proof that this would be possible exists – applications are very often linked from modules programmed in fairly different languages. Maybe, even worst commonly accepted limitation is that languages are not compatible with themselves. The representation of string is not the same in all languages and very often they are not uniform even in different implementations of the same language. 2Even here exist exceptions – SQL C language mixes database SQL language with procedural C language. 37 PANUŠKA: TOWARDS SOFTWARE DEVELOPMENT c.m for(;;) { … } c->m while(true) { … } c[m] do { … } while (true); (*c)[m] for all { … } (*c).m Figure 1. Unclarity in dereferencing and iterations. Another inconvenience arises when a programmer may express one idea in many different ways. Dereferencing of pointers can be done in C/C++ differently. The same is valid for cycle iteration and other language constructs. This unclarity does not simplify the programmers' lives; actually, it distracts them from details they should focus on. Instead of concentrating on abstracts and algorithms of their code, they must pay attention to unimportant concerns of the language. IP brings yet another idea into the world of programming languages. The idea points that code and its documentation should not be split but should be rather one and the same intention. In other words, comments should be written in formal, processable way. This issue is also called as self- descriptive code. More on the subject of IP is in [3] and [4]. Aspect-Oriented Programming Although Aspect-Oriented Programming (AOP) is more than fifteen years old idea, it is still being heavily researched. AOP enables developers to emphasize cross-cutting concerns in their code that would not be easy to unify into a single object or where that would be possible only when non-trivial or unclear changes into a simple code were necessary. Thanks to AOP, different concerns appearing within whole program can be separated – this leads to much clearer code which inherently contains much less bugs. Above is an example of an aspect injecting all occurrences of exception throwing in a program with a piece of code that logs this event. Pay attention to the fact that this is all what a programmer must do – the process when this logging code is interleaved into the final code is done either during compilation stage or even in runtime. Although error handling, logging and debugging are the most well-known use-cases of AOP, there are many others. JBoss Application Server, for example, uses AOP to implement many of its features. To call a method transactionally, every such method is injected with an aspect that ensures calling appropriate routines during begin and commit/rollback transaction phases. More on AOP in JBoss AS can be found in [10]. Other widely spread uses-cases of AOP are caching and deadlock detection. There are plenty of papers about AOP, this paper inspires from [5] and [6]. after() throwing (Throwable e) { log.write(e); } Figure 2. Example of exception logging aspect. Active Libraries Active Libraries (AL) does not provide implementation of passive functions, procedures and routines as traditional libraries, but they actively generate or enrich already compiled libraries. This is done during runtime any time the application code contacts the library. This can be useful for debugging, logging, tuning and other functionalities. AL may adjust provided code for different platforms that will potentially run the code. More on the subject of AL can be found in [2]. Design Patterns Design Patterns are collections of rules which should be followed when one small particular design problem is to be solved.