CSC/ECE 517 Fall 2012/ch1 1w9 av: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Created page with "<p>Domain-specific object-oriented languages - This page describes the domain specific object oriented languages, what languages are currently in use and how useful they are</p> ...")
 
 
(75 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<p>Domain-specific object-oriented languages - This page describes the domain specific object oriented languages, what languages are currently in use and how useful they are</p>
'''Object-Oriented Domain-Specific Languages (OODSL)'''
<p>An OODSL<ref>OODSL 1[http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=User:Snateka&printable=yes]</ref><ref>OODSL 2[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch2_S23_GP]</ref> is a [http://en.wikipedia.org/wiki/Domain-specific_language<code>Domain-specific language</code>] (DSL) that exhibits characteristics that have traditionally been attributed to [http://en.wikipedia.org/wiki/Object-oriented_programming#OOP_languages<code>Object-Oriented Languages</code>] </p>


== Definition ==
<p>Although OO languages and Domain specific languages have been around for several years, OODSLs are relatively new.</p>
Code reuse is the way in which an existing code can be used to perform a specific service regardless of the application in which it is used.<ref name = wiki_code_reuse/> It involves the use of some previously constructed software artifacts like source code, library, components, etc. An example of it can be the design patterns in a new context or in a new development project.


Software reuse is the process of creating software systems from existing software rather than building software systems from scratch.<ref name = "definition_software_reuse" />


== Overview <ref name = wiki_code_reuse/>==
== Overview ==
Code reuse is the idea that a partial computer program written at one time can be, should be, or is being used in another program written at a later time. The reuse of programming code is a common technique which attempts to save time and energy by reducing redundant work.


The software library is a good example of code reuse.  
OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.


Programmers may decide to create internal abstractions so that certain parts of their program can be reused, or may create custom libraries for their own use.


The general practice of using a prior version of an extant program as a starting point for the next version, is also a form of code reuse.
'''The General Purpose Programming way of ordering hash browns at Waffle House'''<ref>Building DSLs [http://www.code-magazine.com/article.aspx?quickid=0902041&page=1]</ref>


Some so-called code "reuse" involves simply copying some or all of the code from an existing program into a new one. While organizations can realize time to market benefits for a new product with this approach, they can subsequently be saddled with many of the same code duplication problems caused by cut and paste programming.
Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....  


Many researchers have worked to make reuse faster, easier, more systematic, and an integral part of the normal process of programming. These are some of the main goals behind the invention of object-oriented programming, which became one of the most common forms of formalized reuse.


A somewhat later invention is generic programming.
'''The OODSL way of ordering hash browns at Waffle House'''


Another, newer means is to use software "generators", programs which can create new programs of a certain type, based on a set of parameters that users choose. Fields of study about such systems are generative programming and metaprogramming.
I would like it Scattered, Smothered, and Peppered please. Thanks!


== History ==
Ad hoc code reuse has been practiced from the earliest days of programming. Programmers have always reused sections of code, templates, functions, and procedures. Software reuse as a recognized area of study in software engineering, however, dates only from 1968 when Douglas McIlroy of Bell Laboratories proposed basing the software industry on reusable components. <ref name = wiki_code_reuse/>


There are many dimensions along which we can trace the history of reuse: <ref name = history_pros_cons/>
For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.
* Software Development Life Cycle (SDLC) Model
* Prototyping, Iterative, ESP, etc.
* Requirements/Specification Method
* Business Model
* Implementation technology
=== History of software reuse based on implementation technology dimension <ref name = history_pros_cons/>===
* Mid 1980’s - Mature Third Generation Programming Languages -
Third generation languages were more portable than the earlier machine specific languages. Even though source code still had to be language, OS and platform specific. However they did achieve limited source code reuse for high value. e.g. math libraries.


* Late 1980’s - Early Object Oriented Languages and SQL DB -
Introduction of object oriented languages like Common Lisp Object System (CLOS), C++ interpreter, etc provided encapsulation and packaging technology.Packaging and common object models promoted development of language “bindings”. Systematic and repeatable object oriented development processes were also introduced during this time. Although most portability constraints remained as they were, som reuse success was achieved in the for of high value data structure libraries (e.g. GRACE and Booch parts). The first successful reusable service of SQL RDBMS was developed during this period.


* Early 1990’s - Mature OO Languages, Source Code Libraries -
OODSLs can be of 2 types:
This era saw development of mature OO languages like Smalltalk, ANSI CLOS, C++ compilers, GUI and Event Driven Programming Libraries and portable compiled software packages like shared Shared Libraries, Dynamic Link Libraries. Significant reuse research was carried out during this period(e.g. SPC CoE for Reuse/ARPA contract) which gave birth to early software reuse driven processes and reuse libraries (like management systems, not just content)


* Mid 1990’s - Early DIAE Component Packaging -
* Internal
Dynamically Integrable Autonomously Executable Components that are compiled and linked separately, integrate at run time, and run independently of each other were developed during this period. (e.g. COM and CORBA). Distributed systems which formed the foundation for Web Services and Component Based development processes were introduced.
* External
Advanced like these also gave rise to commercially successful code generators like Netron, Frame Technology and reusable component vendors like Infragistics.


* Late 1990’s - Mature DIAE Components, Cross-Protocol Bridges -
Along with introduction of Cross Protocol Bridges which allow COM and CORBA systems to participate in the same system, Light weight integration protocols like SOAP were introduced in this period. New reusable component packaging mechanisms were invented. Reuse based development processes matured with time and specialized reusable component market got established.


* 2000-2005 - Early Service Oriented Architecture Products -
Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language.
Service Oriented Architecture
Reuse of function (service), not code or component.
Rediscovery of reuse research:
Software Reuse (Asset) Management Systems
Domain Specific Reuse, Domain Languages (Software Factories)
Reuse must reuse more then code.
Reuse requires drastic process changes.
Patterns: systematic definition of large scale reusable components.
Reuse Successes:
Microsoft .Net Framework
SRMS: Flashline and LogicLibrary


== Techniques <ref name = techniques/>==
External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.
In re-using code, we have several levels of granularity


=== Single lines of code ===
== History ==
For example, in Ruby to print an array containing 5 elements we simply use the following
OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.  
<pre>
[ 'Sam', 'John', 'Gita' ].each {|name| print name, " " }
</pre>
outputs :
Sam John Gita.
 
=== Procedures, Macros ===
Procedures and macros are the low level code reuse techniques
A macro is a group of repetitive instructions in a program which are codified only once and can be used as many times
as necessary.
<pre>
Position MACRO Row, Column
PUSH AX
PUSH BX
PUSH DX
MOV AH, 02H
MOV DH, Row
MOV DL, Column
MOV BH, 0
INT 10H
POP DX
POP BX
POP AX
ENDM
</pre>
A procedure is a collection of instructions to which we can direct the flow of our program, and once the execution of these instructions is over control is given back to the next line to process of the code which called on the procedure.
<pre>
 
Adding Proc Near ; Declaration of the procedure
Mov Bx, 0 ; Content of the procedure
Mov B1, Ah
Mov Ah, 00
Add Bx, Ax
Ret ; Return directive
Add Endp ; End of procedure declaration
 
</pre>
 
=== Functions/methods ===
For example, in Ruby a method can be written as follows
<pre>
def convert_to_farenhite(temperature_in_celcius)
result = temperature_in_celcius * (9/5) +32
return result
end
</pre>
 
=== Components ===
When you are building software, objects are created in code, and reusable objects that perform specific services in different circumstances are called components.
When you use Microsoft® Office to build custom applications, you write code that leverages the power of Office components. Using an Office component means you not only do not have to write the code yourself, but you are using a component that has been tested and found reliable in different conditions.
 
=== Object orientation ===
High level languages also come with effective abstractions to build and share "abstract data types" and other "reusable libraries". Source code components are generally intended to be used as black-boxes: a public interface of usage is announced, formally or not (ruby has not equivalent of java interfaces, for example), while the realization of this interface is kept hidden (or at least intended to be). Think to C libraries, java's .jars, python's modules, ruby's gems, and so on. In many languages, "find a component, download it, and go" has become a reality!


==== Packages ====
In a nutshell, DSL<ref>DSL examples[http://www.semanticdesigns.com/products/DMS/DomainSpecificLanguage.html]</ref> is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco.  Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.
A Java package is a mechanism for organizing Java classes into namespaces similar to the modules of Modula. Java packages can be stored in compressed files called JAR files, allowing classes to download faster as a group rather than one at a time. Programmers also typically use packages to organize classes belonging to the same category or providing similar functionality.
A package provides a unique namespace for the types it contains.
Classes in the same package can access each other's package-access members.


==== Modules ====
Object-Oriented Programming (OO) is a programming paradigm that tries to apply real world principles to make programming easier. OO has been around since the 1950's. Starting with Simula and Smalltalk, OO languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.
Modules are a way of grouping together methods, classes, and constants. An example of a Ruby module is as follows
<pre>
module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
</pre>


==== Inheritance ====
OODSLs, that bring out the features of both DSLs as well as OO languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, parent classes or ancestor classes. The resulting classes are known as derived classes, subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.The basic mechanism of subclassing is simple. The child inherits all of the capabilities of its parent class—all the parent’s instance methods are available in instances of the child. Let’s look at a trivial example and then later build on it. Here’s a definition of a parent class and a child class that inherits from it:
<pre>
class Parent
def say_hello
puts "Hello from #{self}"
end
end
p = Parent.new
p.say_hello
# Subclass the parent...
class Child < Parent
end
</pre>
<pre>
c = Child.new
c.say_hello
produces:
Hello from #<Parent:0x0a40c4>
Hello from #<Child:0x0a3d68>
</pre>
The parent class defines a single instance method, say_hello. We call it by creating a new
instance of the class and store a reference to that instance in the variable p.
We then create a subclass using class Child < Parent. The < notation means we’re creating a
subclass of the thing on the right; the fact that we use less-than presumably signals that the
child class is supposed to be a specialization of the parent.
Note that the child class defines no methods, but when we create an instance of it, we can
call say_hello. That’s because the child inherits all the methods of its parent. Note also that
when we output the value of self—the current object—it shows that we’re in an instance of
class Child, even though the method we’re running is defined in the parent.


===Generators===
== Examples ==
Parser generators (lex & yacc, antlr, rats!, treetop, pyPEG, and so on.) are probably the best-known examples of application generators. Other examples include wizards that one can find in Integrated Development Environments (to design and generate code of user interfaces, for example), tools that generate classes from UML class diagrams, generators of database schemas, report generators, etc. In note in passing that the Noe library I was talking about recently is of course a kind of application generator.
=== PHP ===
[http://en.wikipedia.org/wiki/PHP<code>PHP</code>] is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is sent to the client.


===Software architectures===
=== OODSL compiler for FPGA ===
Software architectures are large-grain software frameworks. In contrast with source code components which are often black-boxes, software architecture are designed as grey-boxes: they are intended to be extended and provide specific extension points for this. We have a lot of reusable frameworks nowadays. Probably the most common are web frameworks (Ruby on Rails, django, ASP.net, ...), integrated development environment (IDE, Eclipse is worth mentioning due to its architecture), service oriented architectures (SOA), and so on.
An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=920835&userType=inst&tag=1]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware brings down the time taken for design by several notches and still results in good optimal performance.


===Design and code scavenging===
== Tools for Creating OODSL ==
Design and code scavenging is simply a form of "find, copy-paste, adapt". The well-known design patterns[3] provide an organized form of design scavenging, by providing catalogues for applying such kind of reuse. Even if invented in the context of the object-oriented programming, design patterns had a great impact far beyond that programming paradigm.
When creating an OODSL, one can either choose to start from scratch or use a tool that is already available. Creating a language from scratch gives the programmer a certain amount of flexibility to define it the way he wants to, but it takes a lot of time. Therefore, in general, software tools are used to aid in the process of creating Domain Specific Languages. This is because it not only saves time, but also helps to make the language easy to use due to familiarity with the syntax of the underlying language.
=== Boo ===
Boo<ref>Boo Home[http://boo.codehaus.org/Home]</ref> is an open source object oriented language that is used to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes their creation easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well ([http://en.wikipedia.org/wiki/Duck_typing <code>Duck typing</code>]).


Code scavenging is less organized as few such catalogues exists. Every day however, the web gives use better ways to apply such a reuse technique: google code search, github's gist, pastie, and so on. I also remember having read an book about Eclipse[4] whose authors encouraged applying the monkey see, monkey do rule, that is, copy pasting code from other Eclipse plugins whose source code is available.
=== Visual Studio ===
Application generators
Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than paying much attention to the internal details of the compiler.<ref>Domain specific development[http://www.domainspecificdevelopment.com/]</ref> Visual tools are used that help focus on the business requirements of the OODSL rather than worrying about how it works internally.
=== Groovy ===
Groovy <ref>Groovy Home[http://groovy.codehaus.org/]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java, making designing of new OODSLs easier and similar to programming in Java. [http://java.dzone.com/articles/groovy-dsl-simple-example<code>An example for developing an OODSL in Groovy</code>].


===Transformational systems===
== OODSL vs. non-OODSL ==
Transformational systems are the holy grail of computer science, nothing less! In that paradigm, software developers actually describe the behavior of the software using a high-level specification language (related to VHLL described before). In a second phase, the specifications are transformed in order to produce an executable system. The transformations are meant to enhance efficiency without changing the semantics.
When defining a DSL, choosing whether to go with an OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be well suited for some situations whereas in other situations, they might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.


Transformational systems emphasizes the what instead of the how. They actually bet on the concision of declarative statements over procedural ones to achieve effective reuse. While general purpose transformation systems remain mostly research topics, notable results have been achieved in some specific domains: relational systems come with effective query optimizers, some rapid prototyping approaches uses transformations from high-level descriptions down to code, etc.
== Advantages and Disadvantages ==
Some of the advantages of OODSLs would be:
* Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and using real world paradigms.
* Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than in non-OODSLs.
* Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.


===Very High Level Languages (VHLL)===
Very High Level Languages, also known as executable specification languages, are languages with very high level of abstraction. They are somewhat difficult to capture precisely and may lead to software reuse that is very specific to specialized domains. However, I would say that the recent advent of Domain Specific Languages (DSLs) and good support for them in dynamic languages (ruby, python, clojure, ...) can be seen as promoting and helping building VHLLs.


== Best practices <ref name = best_practices />==
Though OODSLs in general have several advantages over other languages, one must also consider their disadvantages:
Here are some of the best practices to be followed to make sure that the code that is being written is reusable.
* Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
* They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.


* The first consideration is to write code that uses a consistent naming convention, that is formatted properly, and that contains useful comments.
== A Running Example ==
* Examine the code to make sure that all the procedures have a single, specific purpose. Make sure that the procedure can be describedin a short, plain sentence. For example, "This procedure accept two numbers and calculates the product of those two numbers" If a procedure can not be described simply and clearly in a sentence, then it probably does too many things. Break down complicated procedures into smaller ones that do one thing each. Procedures should contain only code that clearly belongs together.
Given here is a simple example <ref>Example DSL in groovy[http://java.dzone.com/articles/groovy-dsl-simple-example]</ref> for creating an OODSL. The DSL defined here simply prints the text we have specified in the program. This is defined in [http://en.wikipedia.org/wiki/Groovy_(programming_language)<code>Groovy</code>].
* Avoid making specific reference to named application objects.
* Try to minimize the number of arguments in a procedure and pass in only what is actually required by the procedure. In addition, make sure the procedures use all the arguments passed to them.
* Group related procedures and the constants they use together in the same module, and where appropriate, consider grouping related procedures together in a class module with a clearly defined interface.
* Keep procedures in standard modules and not in modules behind forms or documents. The code in form modules should be only the code that is tied directly to the form itself and the code required for calling general procedures stored in standard modules.
* Communicate between procedures by passing data as arguments to the procedures. Persist data by writing it to disk. Avoid using a procedure to write to a global variable so another procedure can read data from that global variable. Avoid communicating with another procedure by passing data out of the application, for example, using one procedure to write data to a disk file so another procedure can read that data.


== Advantages <ref name = history_pros_cons/>==
The definition of our new OODSL is as follows:
* '''Efficiency''' - Software reuse increases the software productivity and decreases the time required for the development of a software by reducing the time spent in designing or in coding
<pre>
* '''Standardization''' - By using the technique of software reuse, a company can improve software system interoperability and needs less people for software development. This provides a competitive advantage for the company and helps to produce better quality software and standardized software.
package com.solutionsfit.dsl.memotemplate
* '''Consistency''' - Reuse of UI widgets in MacOS and Win32 leads to common “look-and-feel” between applications
import groovy.xml.MarkupBuilder
* '''Debugging''' -
class MemoDsl {
* '''Reliability''' - Systems that incorporate a high level of reusable components are more reliable and more easily constructed. Reused design/code is often tested design/code.
String toString
* '''Profit!''' - Software reuse technique helps the company to reduce the costs involved in software development and maintenance.
String fromString
* '''Reduced Risk''' - Software reuse also reduces the risk involved in software development process.
String messageString
* '''Component Market''' - Reuse can lead to a market for component software. Real-world examples: ActiveX components, Hypercard stacks, Java packages, even software tools, such as xerces and xalan from xml.apache.org (they are often included in other software systems)
def sections = []
/**
* Make a closure. Main definition of the DSL program
*/
def static make(closure) {
MemoDsl memoDsl = new MemoDsl()
closure.delegate = memoDsl
closure()
}
/**
* Store the values in the local variables
*/
def to(String toString){
this.toString = toString
}
def from(String fromText){
this.fromString = bodyString
}
def message(String messageString){
this.messageString = messageString
}
/**
* The getText method gets called by the DSL by delegation
*/
def getText(){
doText(this)
}
private static doText(MemoDsl memodsl){
String template = "Memo\nTo: ${memoDsl.toText}\nFrom: ${memoDsl.fromText}\n${memoDsl.body}\n"
def sectionStrings =""
for (s in memoDsl.sections) {
sectionStrings += s.title.toUpperCase() + "\n" + s.body + "\n"
}
template += sectionStrings
println template
}
}
</pre>


== Trade-offs for code reuse at various levels of components <ref name=trade_offs/>==
A sample program in our newly developed OODSL would be:
Different types of application code require varying levels of investment to achieve successful reuse
<pre>
package com.solutionsfit.dsl.memotemplate


* Reusable GUI objects reduce development time and improve quality and consistency but provide only modest payback in terms of overall application development costs.
class MemolDslTest extends GroovyTestCase {
* Server-side components that constitute reusable business logic can provide significant payback but require extensive up-front analysis and design. They also require an architectural foundation but may experience a short shelf life.
void testDslUsage_outputText() {
* Infrastructure components and services frameworks are generic services for transactions, messaging, security, and database connectivity. They eliminate the need to repeatedly build infrastructure that all applications use, but require extensive analysis and design, and complex programming. These standards-based components can often be purchased off-the-shelf.
MemoDsl.make {
* High-level patterns allow organizations to achieve design reuse and identify components with high reuse potential, but developers must build or acquire the components.
to "Nirav Assar"
* Packaged applications provide the only guaranteed form of reuse, letting user companies acquire functionality for significantly less than the cost of building it themselves. However, these applications may not offer the exact functionality an organization needs; the subsequent customization that's required will add to the cost.
from "Barack Obama"
 
message "How are things? We are doing well. Take care"
== Practical problems <ref name = history_pros_cons/>==
text
Although software reuse provides many benefits for the developers, there are some disadvantages.  
}
 
}
=== Disadvantages for developers who reuse the code ===
}
* Mismatch - Reused code or design may not completely match the situation, in that case, reusing the code may incur additional time and effort.
</pre>
* Non-functional characteristics of code may not match the situation - Consider a database that can scale to 10,000s of items, but you need it to scale to 100,000s of items.
* Expense - Some components may be too expensive for the project’s budget. For instance, SGML (a precursor to HTML and XML) tools sell for 5000 dollars a license!
 
=== Disadvantages for developers who develop reusable code ===
* Building reusable objects requires extensive analysis and design. The developer needs to understand and take into consideration all the generalities while coding the reusable module.
* The developer needs to invest extra time in testing and quality assurance, optimization, and documentation. All this takes time and labor, which increases the cost of the code.
* IT departments must also add to the payback equation the cost of tools to support reuse, such as version control and repositories.
* The cost of administering an ongoing reuse program must be considered.
With all these elements, it becomes apparent that reuse doesn't come cheap.
 
== Conclusion ==
The only way you can avoid code depreciation is through reuse but you need to be disciplined and follow a strict process. Reuse enables you to do more with less.


== References ==
== References ==
<references>
<references/>
 
<ref name = techniques> http://www.revision-zero.org/reuse</ref>
<ref name = definition_software_reuse> http://www.biglever.com/papers/Krueger_AcmReuseSurvey.pdf </ref>
<ref name = cde> http://www.codeproject.com/Articles/7746/Value-of-Code-Part-II-Reusing-Code </ref>
<ref name = frameworks> http://www.inf.ufsc.br/~vilain/framework-thiago/p39-johnson.pdf </ref>
<ref name = history_pros_cons> http://www.cs.colorado.edu/~kena/classes/3308/f04/lectures/lecture10.pdf </ref>
<ref name = fgh> Software Reuse History- Thomas Pole </ref>
<ref name = wiki_code_reuse> http://en.wikipedia.org/wiki/Code_reuse </ref>
<ref name = trade_offs> http://www.informationweek.com/708/08iuhid.htm </ref>
<ref name = best_practices> http://msdn.microsoft.com/en-us/library/office/aa189298%28v=office.10%29 </ref>
 
</references>

Latest revision as of 23:47, 14 September 2012

Object-Oriented Domain-Specific Languages (OODSL)

An OODSL<ref>OODSL 1[1]</ref><ref>OODSL 2[2]</ref> is a Domain-specific language (DSL) that exhibits characteristics that have traditionally been attributed to Object-Oriented Languages

Although OO languages and Domain specific languages have been around for several years, OODSLs are relatively new.


Overview

OO languages can be either general purpose like C++, Java and Ruby, or domain specific, like Jquery and Kiddo. The following example shows how the two kinds of languages would work if used in the real world.


The General Purpose Programming way of ordering hash browns at Waffle House<ref>Building DSLs [3]</ref>

Harvest the potato, wash it, and chop it into little pieces. Put the pieces in a pan with oil and fry till they turn golden brown, and then drain the oil away and put them on a plate. Now cut some jalapeno peppers and spread on the potatoes. Then add cheese, which you can get by milking a cow and.....


The OODSL way of ordering hash browns at Waffle House

I would like it Scattered, Smothered, and Peppered please. Thanks!


For a person who works at Waffle House, or goes there regularly to eat, it is a no brainer that the second method is much more efficient. OODSLs take advantage of the context within which communication takes place. By using implicitly understood jargon, the task at hand can be accomplished in a way that is easier to comprehend for a specialized type of user.


OODSLs can be of 2 types:

  • Internal
  • External


Internal OODSLs are languages that are built on top of existing languages. An internal OODSL makes use of the host language syntax to provide the feel of a domain specific language. It is not universally defined as to when a language/library becomes an OODSL. JQuery is one such example. It is a JavaScript library, which offers an easy way to perform functions like element selection. It can also be argued that JavaScript itself is a domain specific language.

External OODSLs are those that are built from scratch. With the current technology, it is far more easy to churn out several internal OODSLs than to build one from scratch. External OODSLs have their own syntax, as well as their own methods of compilation/interpretation.

History

OODSLs cannot be spoken about without first a brief introduction to Domain Specific Languages and the Object-Oriented programming paradigm.

In a nutshell, DSL<ref>DSL examples[4]</ref> is a language that is specific to a particular domain. DSLs are different from general purpose programming languages like C++ and Java. They take advantage of the fact that there are groups of users who rather than communicating every single thing, are able to implicitly understand certain terms and notations. This makes communication much more efficient for such a group. Eg: 2 basketball fans will talk in basketball jargon. Not everyone will understand what zone defence, 3 pointers and jump ball mean. The jargon serves the specific purpose of easing communication between 2 basketball fans. Some would argue that DSLs have been around for a far longer time dating back to even before the advent of computers. Subway maps, electronics circuit diagrams all demonstrate properties of a DSL. Since then, DSLs have come a long way. Domain Specific Languages (DSLs), as they are spoken about now, have been around since the 1970's and their origin can be traced back to a tool called Draco. Since Draco, computers have made it possible to design a whole host of other useful DSLs. Some of the more popular ones among them are SQL, Prolog, Verilog, HTML etc.

Object-Oriented Programming (OO) is a programming paradigm that tries to apply real world principles to make programming easier. OO has been around since the 1950's. Starting with Simula and Smalltalk, OO languages have come a long way since then, and has grown to become one of the most popular programming paradigms employed worldwide. Some of the modern object oriented languages include static languages like C++, Java, C#, and dynamic languages like Perl, Ruby etc.

OODSLs, that bring out the features of both DSLs as well as OO languages are a fairly recent invention. OODSLs have been around since the 1980's/1990's. They are now primarily used in the realm of web development, game development, and are also used in certain specialized industries like music.

Examples

PHP

PHP is an OODSL that is commonly used for web development. It is an open source web development framework that is designed to make web development simpler and easier. The language can be perceived as a general purpose language, but it also has domain specific components designed for the web domain alone. PHP is in general embedded into HTML to perform server side computations before the page is sent to the client.

OODSL compiler for FPGA

An object oriented domain specific compiler was developed for programming Field Programmable Gate Arrays.<ref>Object-Oriented Domain Specific Compilers for Programming FPGAs[5]</ref> The compiler allows the hardware programmer to make use of object-oriented style while programming. The research paper claims that this way of programming the hardware brings down the time taken for design by several notches and still results in good optimal performance.

Tools for Creating OODSL

When creating an OODSL, one can either choose to start from scratch or use a tool that is already available. Creating a language from scratch gives the programmer a certain amount of flexibility to define it the way he wants to, but it takes a lot of time. Therefore, in general, software tools are used to aid in the process of creating Domain Specific Languages. This is because it not only saves time, but also helps to make the language easy to use due to familiarity with the syntax of the underlying language.

Boo

Boo<ref>Boo Home[6]</ref> is an open source object oriented language that is used to create Domain Specific languages. Defining basic data structures like array, hash, variables etc are inherently supported in Boo and it makes their creation easier. Although Boo is a statically typed language, these restrictions can be bent once in a while so that the type of objects can be found and manipulated in run time as well (Duck typing).

Visual Studio

Visual Studio has Domain-specific language tools that are designed to help the designer to build a language focusing on the language grammar and characteristics rather than paying much attention to the internal details of the compiler.<ref>Domain specific development[7]</ref> Visual tools are used that help focus on the business requirements of the OODSL rather than worrying about how it works internally.

Groovy

Groovy <ref>Groovy Home[8]</ref> is a dynamic language for the Java Virtual Machine. Also, the syntax is groovy is similar to that of Java, making designing of new OODSLs easier and similar to programming in Java. An example for developing an OODSL in Groovy.

OODSL vs. non-OODSL

When defining a DSL, choosing whether to go with an OODSL or a non-OODSL depends on several factors like the domain for which it is defined, existing DSLs for that domain etc. Non-OODSLs are domain specific languages that do not necessarily embrace object oriented concepts like abstraction, polymorphism etc. OODSLs can be well suited for some situations whereas in other situations, they might be an overkill. Defining a new OODSL when there is an already widely accepted non-OODSL may not be very useful. For example, HTML is the standard method for displaying web pages and it is non-OODSL. Defining a new non-OODSL that replaces HTML may not prove to be significantly advantageous.

Advantages and Disadvantages

Some of the advantages of OODSLs would be:

  • Since OODSLs, by their name, are object oriented, they give the developer an easier alternative to model their applications based on business goals and using real world paradigms.
  • Because of their object oriented nature, the code is generally simple to understand and therefore code maintenance would be easier in OODSLs than in non-OODSLs.
  • Object oriented concepts like encapsulation and abstraction give the code better security when they are modified in the future.


Though OODSLs in general have several advantages over other languages, one must also consider their disadvantages:

  • Defining an object oriented language in general takes more time than defining a normal language because we have to properly define it to include OO concepts.
  • They may not be well-suited for all domains and environments. Sometimes there may be a simpler non-OODSL way to achieve the task.

A Running Example

Given here is a simple example <ref>Example DSL in groovy[9]</ref> for creating an OODSL. The DSL defined here simply prints the text we have specified in the program. This is defined in Groovy.

The definition of our new OODSL is as follows:

package com.solutionsfit.dsl.memotemplate
import groovy.xml.MarkupBuilder
class MemoDsl {
	String toString
	String fromString
	String messageString
	def sections = []
	/**
	* Make a closure. Main definition of the DSL program
	*/
	def static make(closure) {
		MemoDsl memoDsl = new MemoDsl()
		closure.delegate = memoDsl
		closure()
	}
	/**
	* Store the values in the local variables
	*/
	def to(String toString){
		this.toString = toString
	}
	def from(String fromText){
		this.fromString = bodyString
	}
	def message(String messageString){
		this.messageString = messageString
	}
	/**
	* The getText method gets called by the DSL by delegation
	*/
	def getText(){
		doText(this)
	}
	private static doText(MemoDsl memodsl){
		String template = "Memo\nTo: ${memoDsl.toText}\nFrom: 	${memoDsl.fromText}\n${memoDsl.body}\n"
		def sectionStrings =""
		for (s in memoDsl.sections) {
			sectionStrings += s.title.toUpperCase() + "\n" + s.body + "\n"
		}
		template += sectionStrings
		println template
	}
}

A sample program in our newly developed OODSL would be:

package com.solutionsfit.dsl.memotemplate

class MemolDslTest extends GroovyTestCase {
	void testDslUsage_outputText() {
		MemoDsl.make {
			to "Nirav Assar"
			from "Barack Obama"
			message "How are things? We are doing well. Take care"
			text
		}
	}
}

References

<references/>