Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-29T20:05:04Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://en.wikipedia.org/wiki/Namespace Namespaces] give you control over the visibility of the properties and methods that you create in a program.

==Overview==

A namespace is a way to keep names organized. Lets use an analogy to [http://en.wikipedia.org/wiki/File_system file system] in the computer which uses [http://en.wikipedia.org/wiki/Directory_%28file_systems%29 directories] and sub-directories. Namespaces in this context could be viewed as the path to a file in the directory/sub-directory which can uniquely identify each file. User can create more than one files with same name in different directories or sub-directories as they are in different namespaces.[http://snook.ca/archives/javascript/javascript_name]
Another advantage of namespace is logical grouping of source code.

[[Image:Namespaces.jpg|frame|center]]
Above figure depicts the use of namespace in programming language. The left part of the diagram shows variable "var" used by two different contexts. Now, the context which wants to use the variable "var" should have some means of distinguishing between its declarations. This is where namespaces comes into account. As shown in the second part of the diagram each variable "var" can now be identified independently.
==Types of Namespaces==
Different languages support namespace either using implicit types or explicitly by using keyword 'namespace'.

===Implicit Namespaces===

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts. Some of the constructs of implicit namespaces in different languages are [http://en.wikipedia.org/wiki/Interface_%28Java%29 interfaces], [http://en.wikipedia.org/wiki/Java_package packages], [http://en.wikipedia.org/wiki/Scope_%28programming%29 scope], [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attributes], etc.

====Blocks====
Blocks are often used as an abstraction to resolve naming conflicts. In many languages blocks determine scope of the variables. Hence a variable declared in a particular block has its scope within the block. Hence, we can think of a block as a namespace.

Below is the example that shows how a block resolves naming ambiguities.

main()
{
int i=5;
------
------
{
int i=10;
------
------
//printing I here gives value equal to 10
}
//printing I here gives value equal to 5
}
The above program depicts the concept of [http://en.wikipedia.org/wiki/Global_variable global] and [http://en.wikipedia.org/wiki/Local_variable local] variable initialization which can be viewed as a example of implicit namespace handled by programming language constructs. Disadvantage of this type of namespace is that programmer has to keep track of all variables in program and their namespaces.

====Objects====

In JavaScript[http://www.codeproject.com/KB/scripting/jsnamespaces.aspx], a namespace is actually an [http://en.wikipedia.org/wiki/Object_%28programming%29 object] which is used to reference methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in [http://en.wikipedia.org/wiki/JavaScript_language Javascript]:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();

The above example shows the use of object to reference the methods in its namespace. Hence the functions above are called using the object.

====Packages====

Packages[http://www.javacamp.org/javavscsharp/namespace.html] can be used as a mechanism to organize [http://en.wikipedia.org/wiki/Class_%28programming%29 classes] into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in [http://en.wikipedia.org/wiki/Java_language Java]:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

The above code snippet shows how a package can behave as a namespace in some programming language. Here, package A and package B are two different namespaces with variable var in each of them.

====Modules====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby programming language:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end

module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end

require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

The above code snippet shows the use of modules in a form of namespace in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].The methods are referenced using the name of the module as shown in the code. Hence there is no clash on method name 'sin'.

====Attributes====
XML namespaces[http://en.wikipedia.org/wiki/XML_namespace] provide method for qualifying element and attribute names by associating them with namespaces identified by unique [http://en.wikipedia.org/wiki/URI Uniform Resource Identifier] URI references. For example, Id could be in both vocabularies, employee and student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.

A namespace is declared using the reserved [http://en.wikipedia.org/wiki/XML XML] attribute xmlns, the value of which must be an [http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier Internationalized Resource Identifier] (IRI),
usually a Uniform Resource Identifier (URI) reference.

Below is an example of a attributes as a namespace in XML:

<root
xmlns:fruits="http://www.w3schools.com/fruits"
xmlns:furniture="http://www.w3schools.com/furniture">
<fruits:table>
<fruits:tr>
<fruits:td>Apples</fruits:td>
<fruits:td>Bananas</fruits:td>
</fruits:tr>
</fruits:table>
<furniture:table>
<furniture:name>Sofa</f:name>
</furniture:table>
</root>

The above XML creates the namespace "fruits" and "furniture" in the attribute of xmlns in XML. This way we define namespaces in XML.

===Explicit Namespaces===

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules. Hence some languages use keyword "namespaces" for declaring namespaces. For example, [http://en.wikipedia.org/wiki/C_language C], [http://en.wikipedia.org/wiki/C%2B%2B CPP], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29 C#].
Below is the CPP code which depicts use of namespace keyword.

namespace Square{
int length = 4;
}

namespace Rectangle{
int length = 12;
int breath = 8;
}

int main () {
cout << Square::length << endl; //output 4
cout << Rectangle::length << endl; //output 12
return 0;
}

The above code snippet tells us the use of explicit namespace by using the keyword "namespace" in C++. It defines length in two different namespaces using the keyword namespace.When the length is referenced it is referenced using the name of the namespace.

Similarly, PHP[http://www.php.net/manual/en/language.namespaces.definition.php> uses the namespace keyword to distinguish between identifiers.Below is an example of PHP using namespace keyword:

<?php
Namespace A;
Const NAME = ‘this is constant’
Function FUN()
{
-----
-----
return _MYVARIABLE_;
}
Class C
{
function print_this()
{
------
------
return _THIS_METHOD_;
}
}
?>

The above example denotes the use of namespace keyword in PHP language. Hence in the code const NAME,function fun() and class C are defined in Namespace A. Therefore, they are referenced using the namespace A.
Similarly, C# also uses namespace keyword to distinguish names. Below is the code of C# showing use of namespace keyword.

namespace A
{
public class A1
{
static void Main()
{
B.B1.welcome();
}
}
}
namespace B
{
public class B1
{
public static void welcome()
{
Console.WriteLine("Welcome");
}
}
}

The above code snippet shows the use of namespace keyword in C# language. Here, function main in namespace A calls to function 'welcome' from namespace B by referring its namespace_name.class_name.function_name.

==Conclusion==
Every programming language support namespaces at different abstraction level. They are not just containers but designed to allow simple,fast and efficient usage and understanding of the code. Namespaces actually provide luxury to declare multiple variable with same name which in turn protect code with name clashes. Using namespace generally gives a better structure to program which makes easier to maintain when the code length increases. In summary, different languages have different methods of providing namespace functionality be it explicit or implicit to provide better coding experience to the user.

==References==
== References ==

# [http://snook.ca/archives/javascript/javascript_name NameSpace]
# [http://www.codeproject.com/KB/scripting/jsnamespaces.aspx Namespaces in Javascript]
# [http://www.javacamp.org/javavscsharp/namespace.html Namespace vs. Packages]
# [http://en.wikipedia.org/wiki/XML_namespace XML Namespace]
# [http://www.php.net/manual/en/language.namespaces.definition.php PHP Manual by Mehdi Achour, Friedhelm Betz, Antony Dovgal, Nuno Lopes, Hannes Magnusson]
Georg Richter
Damien Seguy
Jakub Vrana
# Explicit Namespaces, Franz Achermann and Oscar Nierstrasz, Software Composition Group, University of Berne

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-29T19:48:47Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. Namespaces [http://www.google.com/search?hl=en&defl=en&q=define:Namespace&sa=X&ei=Gqy_TMyYK8OC8ga_ioGCBQ&sqi=2&ved=0CBMQkAE] give you control over the visibility of the properties and methods that you create in a program.

==Overview==

A namespace is a way to keep names organized[http://snook.ca/archives/javascript/javascript_name]. Lets use an analogy to [http://en.wikipedia.org/wiki/File_system file system] in the computer which uses [http://en.wikipedia.org/wiki/Directory_%28file_systems%29 directories] and sub-directories. Namespaces in this context could be viewed as the path to a file in the directory/sub-directory which can uniquely identify each file. User can create more than one files with same name in different directories or sub-directories as they are in different namespaces.
Another advantage of namespace is logical grouping of source code.

[[Image:Namespaces.jpg|frame|center]]
Above figure depicts the use of namespace in programming language. The identifier "var" is used in both the namespaces and while using them we need to specify to which namespace they belong to.

==Types of Namespaces==
Different languages support namespace either using implicit types or explicitly by using keyword 'namespace'.

===Implicit Namespaces===

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts. Some of the constructs of implicit namespaces in different languages are [http://en.wikipedia.org/wiki/Interface_%28Java%29 interfaces], [http://en.wikipedia.org/wiki/Java_package packages], [http://en.wikipedia.org/wiki/Scope_%28programming%29 scope], [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attributes], etc.

====Blocks====
Blocks are often used as an abstraction to resolve naming conflicts. In many languages blocks determine scope of the variables. Hence a variable declared in a particular block has its scope within the block. Hence, we can think of a block as a namespace.

Below is the example that shows how a block resolves naming ambiguities.

main()
{
int i=5;
------
------
{
int i=10;
------
------
//printing I here gives value equal to 10
}
//printing I here gives value equal to 5
}
The above program depicts the concept of [http://en.wikipedia.org/wiki/Global_variable global] and [http://en.wikipedia.org/wiki/Local_variable local] variable initialization which can be viewed as a example of implicit namespace handled by programming language constructs. Disadvantage of this type of namespace is that programmer has to keep track of all variables in program and their namespaces.

====Objects====

In JavaScript[http://www.codeproject.com/KB/scripting/jsnamespaces.aspx], a namespace is actually an [http://en.wikipedia.org/wiki/Object_%28programming%29 object] which is used to reference methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in [http://en.wikipedia.org/wiki/JavaScript_language Javascript]:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();

The above example shows the use of object to reference the methods in its namespace. Hence the functions above are called using the object.

====Packages====

Packages[http://www.javacamp.org/javavscsharp/namespace.html] can be used as a mechanism to organize [http://en.wikipedia.org/wiki/Class_%28programming%29 classes] into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in [http://en.wikipedia.org/wiki/Java_language Java]:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

The above code snippet shows how a package can behave as a namespace in some programming language. Here, package A and package B are two different namespaces with variable var in each of them.

====Modules====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby programming language:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end

module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end

require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

The above code snippet shows the use of modules in a form of namespace in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].The methods are referenced using the name of the module as shown in the code. Hence there is no clash on method name 'sin'.

====Attributes====
XML namespaces[http://en.wikipedia.org/wiki/XML_namespace] provide method for qualifying element and attribute names by associating them with namespaces identified by unique [http://en.wikipedia.org/wiki/URI URI] references. For example, Id could be in both vocabularies, employee and student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.

A namespace is declared using the reserved [http://en.wikipedia.org/wiki/XML XML] attribute xmlns, the value of which must be an [http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier Internationalized Resource Identifier] (IRI),
usually a Uniform Resource Identifier (URI) reference.

Below is an example of a attributes as a namespace in XML:

<root
xmlns:fruits="http://www.w3schools.com/fruits"
xmlns:furniture="http://www.w3schools.com/furniture">
<fruits:table>
<fruits:tr>
<fruits:td>Apples</fruits:td>
<fruits:td>Bananas</fruits:td>
</fruits:tr>
</fruits:table>
<furniture:table>
<furniture:name>Sofa</f:name>
</furniture:table>
</root>

The above XML creates the namespace "fruits" and "furniture" in the attribute of xmlns in XML. This way we define namespaces in XML.

===Explicit Namespaces===

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules. Hence some languages use keyword "namespaces" for declaring namespaces. For example, [http://en.wikipedia.org/wiki/C_language C], [http://en.wikipedia.org/wiki/C%2B%2B CPP], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29 C#].
Below is the CPP code which depicts use of namespace keyword.

namespace Square{
int length = 4;
}

namespace Rectangle{
int length = 12;
int breath = 8;
}

int main () {
cout << Square::length << endl; //output 4
cout << Rectangle::length << endl; //output 12
return 0;
}

The above code snippet tells us the use of explicit namespace by using the keyword "namespace" in C++. It defines length in two different namespaces using the keyword namespace.When the length is referenced it is referenced using the name of the namespace.

Similarly, PHP[http://www.php.net/manual/en/language.namespaces.definition.php> uses the namespace keyword to distinguish between identifiers.Below is an example of PHP using namespace keyword:

<?php
Namespace A;
Const NAME = ‘this is constant’
Function FUN()
{
-----
-----
return _MYVARIABLE_;
}
Class C
{
function print_this()
{
------
------
return _THIS_METHOD_;
}
}
?>

The above example denotes the use of namespace keyword in PHP language. Hence in the code const NAME,function fun() and class C are defined in Namespace A. Therefore, they are referenced using the namespace A.
Similarly, C# also uses namespace keyword to distinguish names. Below is the code of C# showing use of namespace keyword.

namespace A
{
public class A1
{
static void Main()
{
B.B1.welcome();
}
}
}
namespace B
{
public class B1
{
public static void welcome()
{
Console.WriteLine("Welcome");
}
}
}

The above code snippet shows the use of namespace keyword in C# language. Here, function main in namespace A calls to function 'welcome' from namespace B by referring its namespace_name.class_name.function_name.

==Conclusion==
Every programming language support namespaces at different abstraction level. They are not just containers but designed to allow simple,fast and efficient usage and understanding of the code. Namespaces actually provide luxury to declare multiple variable with same name which in turn protect code with name clashes. Using namespace generally gives a better structure to program which makes easier to maintain when the code length increases. In summary, different languages have different methods of providing namespace functionality be it explicit or implicit to provide better coding experience to the user.

==References==
== References ==

# [http://www.google.com/search?hl=en&defl=en&q=define:Namespace&sa=X&ei=Gqy_TMyYK8OC8ga_ioGCBQ&sqi=2&ved=0CBMQkAE Namespace]
# [http://snook.ca/archives/javascript/javascript_name NameSpace]
# [http://www.codeproject.com/KB/scripting/jsnamespaces.aspx Namespaces in Javascript]
# [http://www.javacamp.org/javavscsharp/namespace.html Namespace vs. Packages]
# [http://en.wikipedia.org/wiki/XML_namespace XML Namespace]
# [http://www.php.net/manual/en/language.namespaces.definition.php PHP Manual by Mehdi Achour, Friedhelm Betz, Antony Dovgal, Nuno Lopes, Hannes Magnusson]
Georg Richter
Damien Seguy
Jakub Vrana
# Explicit Namespaces, Franz Achermann and Oscar Nierstrasz, Software Composition Group, University of Berne

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-21T03:32:09Z

Rsoni: /* Attributes */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://www.google.com/search?hl=en&defl=en&q=define:Namespace&sa=X&ei=Gqy_TMyYK8OC8ga_ioGCBQ&sqi=2&ved=0CBMQkAE Namespaces] give you control over the visibility of the properties and methods that you create in a program.

==Overview==

A namespace is a way to keep names organized. Lets use an analogy to [http://en.wikipedia.org/wiki/File_system file system] in the computer which uses [http://en.wikipedia.org/wiki/Directory_%28file_systems%29 directories] and sub-directories. Namespaces in this context could be viewed as the path to a file in the directory/sub-directory which can uniquely identify each file. User can create more than one files with same name in different directories or sub-directories as they are in different namespaces.

[[Image:Namespaces.jpg|frame|center]]
Above figure depicts the use of namespace in programming language. The identifier "var" is used in both the namespaces and while using them we need to specify to which namespace they belong to.

==Types of Namespaces==
Different languages support namespace either using implicit types or explicitly by using keyword 'namespace'.

===Implicit Namespaces===

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts. Some of the constructs of implicit namespaces in different languages are [http://en.wikipedia.org/wiki/Interface_%28Java%29 interfaces], [http://en.wikipedia.org/wiki/Java_package packages], [http://en.wikipedia.org/wiki/Scope_%28programming%29 scope], [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attributes], etc.

====Blocks====
Blocks are often used as an abstraction to resolve naming conflicts. In many languages blocks determine scope of the variables. Hence a variable declared in a particular block has its scope within the block. Hence, we can think of a block as a namespace.

Below is the example that shows how a block resolves naming ambiguities.

main()
{
int i=5;
------
------
{
int i=10;
------
------
//printing I here gives value equal to 10
}
//printing I here gives value equal to 5
}
The above program depicts the concept of [http://en.wikipedia.org/wiki/Global_variable global] and [http://en.wikipedia.org/wiki/Local_variable local] variable initialization which can be viewed as a example of implicit namespace handled by programming language constructs. Disadvantage of this type of namespace is that programmer has to keep track of all variables in program and their namespaces.

====Objects====

In JavaScript, a namespace is actually an [http://en.wikipedia.org/wiki/Object_%28programming%29 object] which is used to reference methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in [http://en.wikipedia.org/wiki/JavaScript_language Javascript]:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();

The above example shows the use of object to reference the methods in its namespace. Hence the functions above are called using the object.

====Packages====

Packages can be used as a mechanism to organize [http://en.wikipedia.org/wiki/Class_%28programming%29 classes] into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in [http://en.wikipedia.org/wiki/Java_language Java]:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

The above code snippet shows how a package can behave as a namespace in some programming language. Here, package A and package B are two different namespaces with variable var in each of them.

====Modules====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby programming language:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end

module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end

require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

The above code snippet shows the use of modules in a form of namespace in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].The methods are referenced using the name of the module as shown in the code. Hence there is no clash on method name 'sin'.

====Attributes====
XML namespaces provide method for qualifying element and attribute names by associating them with namespaces identified by unique [http://en.wikipedia.org/wiki/URI URI] references. For example, Id could be in both vocabularies, employee and student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.

A namespace is declared using the reserved [http://en.wikipedia.org/wiki/XML XML] attribute xmlns, the value of which must be an [http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier Internationalized Resource Identifier] (IRI),
usually a Uniform Resource Identifier (URI) reference.

Below is an example of a attributes as a namespace in XML:

<root
xmlns:fruits="http://www.w3schools.com/fruits"
xmlns:furniture="http://www.w3schools.com/furniture">
<fruits:table>
<fruits:tr>
<fruits:td>Apples</fruits:td>
<fruits:td>Bananas</fruits:td>
</fruits:tr>
</fruits:table>
<furniture:table>
<furniture:name>Sofa</f:name>
</furniture:table>
</root>

The above XML creates the namespace "fruits" and "furniture" in the attribute of xmlns in XML. This way we define namespaces in XML.

===Explicit Namespaces===

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules. Hence some languages use keyword "namespaces" for declaring namespaces. For example, [http://en.wikipedia.org/wiki/C_language C], [http://en.wikipedia.org/wiki/C%2B%2B CPP], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29 C#].
Below is the CPP code which depicts use of namespace keyword.

namespace Square{
int length = 4;
}

namespace Rectangle{
int length = 12;
int breath = 8;
}

int main () {
cout << Square::length << endl; //output 4
cout << Rectangle::length << endl; //output 12
return 0;
}

The above code snippet tells us the use of explicit namespace by using the keyword "namespace" in C++. It defines length in two different namespaces using the keyword namespace.When the length is referenced it is referenced using the name of the namespace.

Similarly, PHP uses the namespace keyword to distinguish between identifiers.Below is an example of PHP using namespace keyword:

<?php
Namespace A;
Const NAME = ‘this is constant’
Function FUN()
{
-----
-----
return _MYVARIABLE_;
}
Class C
{
function print_this()
{
------
------
return _THIS_METHOD_;
}
}
?>

The above example denotes the use of namespace keyword in PHP language.
Similarly, C# also uses namespace keyword to distinguish names. Below is the code of C# showing use of namespace keyword.

namespace A
{
public class A1
{
static void Main()
{
B.B1.welcome();
}
}
}
namespace B
{
public class B1
{
public static void welcome()
{
Console.WriteLine("Welcome");
}
}
}

The above code snippet shows the use of namespace keyword in C# language. Here, function main in namespace A calls to function 'welcome' from namespace B by referring its namespace_name.class_name.function_name.

==Conclusion==
Every programming language support namespaces at different abstraction level. They are not just containers but designed to allow simple,fast and efficient usage and understanding of the code. Namespaces actually provide luxury to declare multiple variable with same name which in turn protect code with name clashes. Using namespace generally gives a better structure to program which makes easier to maintain when the code length increases. In summary, different languages have different methods of providing namespace functionality be it explicit or implicit to provide better coding experience to the user.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-21T03:31:39Z

Rsoni: /* Attributes */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://www.google.com/search?hl=en&defl=en&q=define:Namespace&sa=X&ei=Gqy_TMyYK8OC8ga_ioGCBQ&sqi=2&ved=0CBMQkAE Namespaces] give you control over the visibility of the properties and methods that you create in a program.

==Overview==

A namespace is a way to keep names organized. Lets use an analogy to [http://en.wikipedia.org/wiki/File_system file system] in the computer which uses [http://en.wikipedia.org/wiki/Directory_%28file_systems%29 directories] and sub-directories. Namespaces in this context could be viewed as the path to a file in the directory/sub-directory which can uniquely identify each file. User can create more than one files with same name in different directories or sub-directories as they are in different namespaces.

[[Image:Namespaces.jpg|frame|center]]
Above figure depicts the use of namespace in programming language. The identifier "var" is used in both the namespaces and while using them we need to specify to which namespace they belong to.

==Types of Namespaces==
Different languages support namespace either using implicit types or explicitly by using keyword 'namespace'.

===Implicit Namespaces===

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts. Some of the constructs of implicit namespaces in different languages are [http://en.wikipedia.org/wiki/Interface_%28Java%29 interfaces], [http://en.wikipedia.org/wiki/Java_package packages], [http://en.wikipedia.org/wiki/Scope_%28programming%29 scope], [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attributes], etc.

====Blocks====
Blocks are often used as an abstraction to resolve naming conflicts. In many languages blocks determine scope of the variables. Hence a variable declared in a particular block has its scope within the block. Hence, we can think of a block as a namespace.

Below is the example that shows how a block resolves naming ambiguities.

main()
{
int i=5;
------
------
{
int i=10;
------
------
//printing I here gives value equal to 10
}
//printing I here gives value equal to 5
}
The above program depicts the concept of [http://en.wikipedia.org/wiki/Global_variable global] and [http://en.wikipedia.org/wiki/Local_variable local] variable initialization which can be viewed as a example of implicit namespace handled by programming language constructs. Disadvantage of this type of namespace is that programmer has to keep track of all variables in program and their namespaces.

====Objects====

In JavaScript, a namespace is actually an [http://en.wikipedia.org/wiki/Object_%28programming%29 object] which is used to reference methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in [http://en.wikipedia.org/wiki/JavaScript_language Javascript]:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();

The above example shows the use of object to reference the methods in its namespace. Hence the functions above are called using the object.

====Packages====

Packages can be used as a mechanism to organize [http://en.wikipedia.org/wiki/Class_%28programming%29 classes] into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in [http://en.wikipedia.org/wiki/Java_language Java]:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

The above code snippet shows how a package can behave as a namespace in some programming language. Here, package A and package B are two different namespaces with variable var in each of them.

====Modules====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby programming language:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end

module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end

require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

The above code snippet shows the use of modules in a form of namespace in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].The methods are referenced using the name of the module as shown in the code. Hence there is no clash on method name 'sin'.

====Attributes====
XML namespaces provide method for qualifying element and attribute names by associating them with namespaces identified by unique [http://en.wikipedia.org/wiki/URI URI] references. For example, Id could be in both vocabularies, employee and student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.

A namespace is declared using the reserved [http://en.wikipedia.org/wiki/XML XML] attribute xmlns, the value of which must be an [http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier Internationalized Resource Identifier] (IRI),
usually a Uniform Resource Identifier (URI) reference.

Below is an example of a attributes as a namespace in XML:

<root
xmlns:fruits=" http://www.w3schools.com/fruits "
xmlns:furniture="http://www.w3schools.com/furniture">
<fruits:table>
<fruits:tr>
<fruits:td>Apples</fruits:td>
<fruits:td>Bananas</fruits:td>
</fruits:tr>
</fruits:table>
<furniture:table>
<furniture:name>Sofa</f:name>
</furniture:table>
</root>

The above XML creates the namespace "fruits" and "furniture" in the attribute of xmlns in XML. This way we define namespaces in XML.

===Explicit Namespaces===

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules. Hence some languages use keyword "namespaces" for declaring namespaces. For example, [http://en.wikipedia.org/wiki/C_language C], [http://en.wikipedia.org/wiki/C%2B%2B CPP], [http://en.wikipedia.org/wiki/PHP PHP], [http://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29 C#].
Below is the CPP code which depicts use of namespace keyword.

namespace Square{
int length = 4;
}

namespace Rectangle{
int length = 12;
int breath = 8;
}

int main () {
cout << Square::length << endl; //output 4
cout << Rectangle::length << endl; //output 12
return 0;
}

The above code snippet tells us the use of explicit namespace by using the keyword "namespace" in C++. It defines length in two different namespaces using the keyword namespace.When the length is referenced it is referenced using the name of the namespace.

Similarly, PHP uses the namespace keyword to distinguish between identifiers.Below is an example of PHP using namespace keyword:

<?php
Namespace A;
Const NAME = ‘this is constant’
Function FUN()
{
-----
-----
return _MYVARIABLE_;
}
Class C
{
function print_this()
{
------
------
return _THIS_METHOD_;
}
}
?>

The above example denotes the use of namespace keyword in PHP language.
Similarly, C# also uses namespace keyword to distinguish names. Below is the code of C# showing use of namespace keyword.

namespace A
{
public class A1
{
static void Main()
{
B.B1.welcome();
}
}
}
namespace B
{
public class B1
{
public static void welcome()
{
Console.WriteLine("Welcome");
}
}
}

The above code snippet shows the use of namespace keyword in C# language. Here, function main in namespace A calls to function 'welcome' from namespace B by referring its namespace_name.class_name.function_name.

==Conclusion==
Every programming language support namespaces at different abstraction level. They are not just containers but designed to allow simple,fast and efficient usage and understanding of the code. Namespaces actually provide luxury to declare multiple variable with same name which in turn protect code with name clashes. Using namespace generally gives a better structure to program which makes easier to maintain when the code length increases. In summary, different languages have different methods of providing namespace functionality be it explicit or implicit to provide better coding experience to the user.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-21T03:26:34Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://www.google.com/search?hl=en&defl=en&q=define:Namespace&sa=X&ei=Gqy_TMyYK8OC8ga_ioGCBQ&sqi=2&ved=0CBMQkAE Namespaces] give you control over the visibility of the properties and methods that you create in a program.

==Overview==

A namespace is a way to keep names organized. Lets use an analogy to [http://en.wikipedia.org/wiki/File_system file system] in the computer which uses [http://en.wikipedia.org/wiki/Directory_%28file_systems%29 directories] and sub-directories. Namespaces in this context could be viewed as the path to a file in the directory/sub-directory which can uniquely identify each file. User can create more than one files with same name in different directories or sub-directories as they are in different namespaces.

[[Image:Namespaces.jpg|frame|center]]
Above figure depicts the use of namespace in programming language. The identifier "var" is used in both the namespaces and while using them we need to specify to which namespace they belong to.

==Types of Namespaces==
Different languages support namespace either using implicit types or explicitly by using keyword 'namespace'.

===Implicit Namespaces===

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts. Some of the constructs of implicit namespaces in different languages are [http://en.wikipedia.org/wiki/Interface_%28Java%29 interfaces], [http://en.wikipedia.org/wiki/Java_package packages], [http://en.wikipedia.org/wiki/Scope_%28programming%29 scope], [http://en.wikipedia.org/wiki/Attribute_%28computing%29 attributes], etc.

====Blocks====
Blocks are often used as an abstraction to resolve naming conflicts. In many languages blocks determine scope of the variables. Hence a variable declared in a particular block has its scope within the block. Hence, we can think of a block as a namespace.

Below is the example that shows how a block resolves naming ambiguities.

main()
{
int i=5;
------
------
{
int i=10;
------
------
//printing I here gives value equal to 10
}
//printing I here gives value equal to 5
}
The above program depicts the concept of [http://en.wikipedia.org/wiki/Global_variable global] and [http://en.wikipedia.org/wiki/Local_variable local] variable initialization which can be viewed as a example of implicit namespace handled by programming language constructs. Disadvantage of this type of namespace is that programmer has to keep track of all variables in program and their namespaces.

====Objects====

In JavaScript, a namespace is actually an [http://en.wikipedia.org/wiki/Object_%28programming%29 object] which is used to reference methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in [http://en.wikipedia.org/wiki/JavaScript_language Javascript]:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();

The above example shows the use of object to reference the methods in its namespace. Hence the functions above are called using the object.

====Packages====

Packages can be used as a mechanism to organize [http://en.wikipedia.org/wiki/Class_%28programming%29 classes] into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in [http://en.wikipedia.org/wiki/Java_language Java]:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

The above code snippet shows how a package can behave as a namespace in some programming language. Here, package A and package B are two different namespaces with variable var in each of them.

====Modules====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby programming language:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end

module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end

require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

The above code snippet shows the use of modules in a form of namespace in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].The methods are referenced using the name of the module as shown in the code. Hence there is no clash on method name 'sin'.

====Attributes====
XML namespaces provide method for qualifying element and attribute names by associating them with namespaces identified by unique [http://en.wikipedia.org/wiki/URI URI] references. For example, Id could be in both vocabularies, employee and student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.

A namespace is declared using the reserved [http://en.wikipedia.org/wiki/XML XML] attribute xmlns, the value of which must be an [http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier Internationalized Resource Identifier] (IRI),
usually a Uniform Resource Identifier (URI) reference.

Below is an example of a attributes as a namespace in XML:

<root
xmlns:fruits=" http://www.w3schools.com/fruits "
xmlns:furniture="http://www.w3schools.com/furniture">
<fruits:table>
<fruits:tr>
<fruits:td>Apples</fruits:td>
<fruits:td>Bananas</fruits:td>
</fruits:tr>
</fruits:table>
<furniture:table>
<furniture:name>Sofa</f:name>
</furniture:table>
</root>

The above XML creates the namespace "fruits" and "furniture" in the attribute of xmlns in XML. This way we define namespaces in XML.

===Explicit Namespaces===

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules. Hence some languages use keyword "namespaces" for declaring namespaces. For example, C, CPP, PHP, C#.
Below is the CPP code which depicts use of namespace keyword.

namespace Square{
int length = 4;
}

namespace Rectangle{
int length = 12;
int breath = 8;
}

int main () {
cout << Square::length << endl; //output 4
cout << Rectangle::length << endl; //output 12
return 0;
}

The above code snippet tells us the use of explicit namespace by using the keyword "namespace" in C++. It defines length in two different namespaces using the keyword namespace.When the length is referenced it is referenced using the name of the namespace.

Similarly, PHP uses the namespace keyword to distinguish between identifiers.Below is an example of PHP using namespace keyword:

<?php
Namespace A;
Const NAME = ‘this is constant’
Function FUN()
{
-----
-----
return _MYVARIABLE_;
}
Class C
{
function print_this()
{
------
------
return _THIS_METHOD_;
}
}
?>

The above example denotes the use of namespace keyword in PHP language.
Similarly, C# also uses namespace keyword to distinguish names. Below is the code of C# showing use of namespace keyword.

namespace A
{
public class A1
{
static void Main()
{
B.B1.welcome();
}
}
}
namespace B
{
public class B1
{
public static void welcome()
{
Console.WriteLine("Welcome");
}
}
}

The above code snippet shows the use of namespace keyword in C# language. Here, function main in namespace A calls to function 'welcome' from namespace B by referring its namespace_name.class_name.function_name.

==Conclusion==
Every programming language support namespaces at different abstraction level. They are not just containers but designed to allow simple,fast and efficient usage and understanding of the code. Namespaces actually provide luxury to declare multiple variable with same name which in turn protect code with name clashes. Using namespace generally gives a better structure to program which makes easier to maintain when the code length increases. In summary, different languages have different methods of providing namespace functionality be it explicit or implicit to provide better coding experience to the user.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-19T04:41:37Z

Rsoni:

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-17T05:09:04Z

Rsoni:

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T01:57:50Z

Rsoni:

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T01:47:46Z

Rsoni:

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T01:41:28Z

Rsoni:

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T01:40:14Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespaces.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Blocks=====
Blocks are often used as an abstraction to resolve naming conflicts. In many languages blocks determine scope of the variables. Hence a variable declared in a particular block has its scope within the block. Hence, we can think of a block as a namespace.

Below is the example that shows how a block resolves naming ambiguities.

main()
{
int i=5;
------
------
{
int i=10;
------
------
//printing I here gives value equal to 10
}
//printing I here gives value equal to 5
}

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in Javascript:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Attributes=====
XML namespaces provide method for qualifying element and attribute names by associating them with namespaces identified by unique URI references.For example, Id could be in both vocabularies,employee, student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.

A namespace is declared using the reserved XML attribute xmlns, the value of which must be an Internationalized Resource Identifier (IRI),
usually a Uniform Resource Identifier (URI) reference.

Below is an example of a attributes as a namespace in XML:

<root
xmlns:fruits="http://www.w3schools.com/fruits"
xmlns:furniture="http://www.w3schools.com/furniture">
<fruits:table>
<fruits:tr>
<fruits:td>Apples</fruits:td>
<fruits:td>Bananas</fruits:td>
</fruits:tr>
</fruits:table>
<furniture:table>
<furniture:name>Sofa</f:name>
</furniture:table>
</root>

====Explicit Namespaces====

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules. Hence some languages use keyword "namespaces" for declaring namespaces. For example, C, Cpp, PHP, C#.
Below is the CPP code which depicts use of namespace keyword.

namespace Square{
int length = 4;
}

namespace Rectangle{
int length = 12;
int breath = 8;
}

int main () {
cout << Square::length << endl; //output 4
cout << Rectangle::length << endl; //output 12
cout << length << endl;
return 0;
}

Similarly, PHP uses the namespace keyword to distinguish between identifiers.Below is an example of PHP using namespace keyword:

<?php
Namespace A;
Const NAME = ‘this is constant’
Function FUN()
{
-----
-----
return _MYVARIABLE_;
}
Class C
{
function print_this()
{
------
------
return _THIS_METHOD_;
}
}
?>

Similarly, C# also uses namespace keyword to distinguish names. Below is the code of C# showing use of namespace keyword.

namespace A
{
public class A1
{
static void Main()
{
B.B1.welcome();
}
}
}
namespace B
{
public class B1
{
public static void welcome()
{
Console.WriteLine("Welcome");
}
}
}
===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T01:29:10Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespaces.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in Javascript:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();

=====Attributes=====
XML namespaces provide method for qualifying element and attribute names by associating them with namespaces identified by unique URI references.For example, Id could be in both vocabularies,employee, student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.

A namespace is declared using the reserved XML attribute xmlns, the value of which must be an Internationalized Resource Identifier (IRI),
usually a Uniform Resource Identifier (URI) reference.

Below is an example of a attributes as a namespace in XML:

<root
xmlns:fruits="http://www.w3schools.com/fruits"
xmlns:furniture="http://www.w3schools.com/furniture">
<fruits:table>
<fruits:tr>
<fruits:td>Apples</fruits:td>
<fruits:td>Bananas</fruits:td>
</fruits:tr>
</fruits:table>
<furniture:table>
<furniture:name>Sofa</f:name>
</furniture:table>
</root>

====Explicit Namespaces====

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules. Hence some languages use keyword "namespaces" for declaring namespaces. For example, C, Cpp, PHP, C#.
Below is the CPP code which depicts use of namespace keyword.

namespace Square{
int length = 4;
}

namespace Rectangle{
int length = 12;
int breath = 8;
}

int main () {
cout << Square::length << endl; //output 4
cout << Rectangle::length << endl; //output 12
cout << length << endl;
return 0;
}

Similarly, PHP uses the namespace keyword to distinguish between identifiers.Below is an example of PHP using namespace keyword:

<?php
Namespace A;
Const NAME = ‘this is constant’
Function FUN()
{
-----
-----
return _MYVARIABLE_;
}
Class C
{
function print_this()
{
------
------
return _THIS_METHOD_;
}
}
?>

Similarly, C# also uses namespace keyword to distinguish names. Below is the code of C# showing use of namespace keyword.

namespace A
{
public class A1
{
static void Main()
{
B.B1.welcome();
}
}
}
namespace B
{
public class B1
{
public static void welcome()
{
Console.WriteLine("Welcome");
}
}
}
===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T01:14:43Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespaces.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in Javascript:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();

=====Attributes=====
XML namespaces provide method for qualifying element and attribute names by associating them with namespaces identified by unique URI references.For example, Id could be in both vocabularies,employee, student, hence we can provide uniqueness for each vocabulary using namespaces to avoid conflicts.

A namespace is declared using the reserved XML attribute xmlns, the value of which must be an Internationalized Resource Identifier (IRI),
usually a Uniform Resource Identifier (URI) reference.

Below is an example of a attributes as a namespace in XML:

<root
xmlns:fruits="http://www.w3schools.com/fruits"
xmlns:furniture="http://www.w3schools.com/furniture">
<fruits:table>
<fruits:tr>
<fruits:td>Apples</fruits:td>
<fruits:td>Bananas</fruits:td>
</fruits:tr>
</fruits:table>
<furniture:table>
<furniture:name>Sofa</f:name>
</furniture:table>
</root>

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T00:15:26Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespaces.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in Javascript:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();
Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

File:Namespaces.jpg

2010-10-16T00:15:08Z

Rsoni:

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T00:14:28Z

Rsoni: /* Objects */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in Javascript:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();
Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T00:13:27Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

Below is an example of a modules in Ruby:

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();
Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T00:12:58Z

Rsoni: /* Objects */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces in Javascript.

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();
Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T00:09:49Z

Rsoni: /* Objects */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces.

var Val = {
Hello: function() {
alert("Hello...!!!");
},
Goodbye: function() {
alert("Goodbye...!!");
}
}
// In a nearby piece of code...
Val.Hello();
Val.Goodbye();
Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-16T00:02:40Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

=====Objects=====
In JavaScript, a namespace is actually an object which is used to references methods, properties and other objects.Objects are all we need to create namespaces.

var Val = {

Hello: function() {
alert("Hello...!!!");
},

Goodbye: function() {
alert("Goodbye...!!");
}

}

// In a nearby piece of code...

Val.Hello();
Val.Goodbye();
Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:48:08Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end
module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end
require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:47:38Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

=====Modules=====

In some languages, different constructs are used to identify namespaces. Languages like Ruby maintains namespace at higher level of abstraction known as modules which can be thought to be similar to packages in Java.

Below is an example of a modules in Ruby:

module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
end

module Moral
VERY_BAD = 0
BAD = 1
def Moral.sin(badness)
# ...
end
end

require 'trig'
require 'moral'
y = Trig.sin(Trig::PI/4)
wrongdoing = Moral.sin(Moral::VERY_BAD)

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:37:57Z

Rsoni: /* Packages */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:37:06Z

Rsoni: /* Packages */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;

class A1 {

int var = 4;

}

package B;

class B1 {

int var = 12;

}

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:36:39Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:34:24Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a package in Java:

package A;
class A1 {
int var = 4;
}
package B;
class B1 {
int var = 12;
}

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:32:08Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Below is an example of a namespace in C++:

<source lang="cpp">
namespace Box1{
int boxSide = 4;
}

namespace Box2{
int boxSide = 12;
}

int main () {
cout << Box1::boxSide << endl; //output 4
cout << Box2::boxSide << endl; //output 12
return 0;
}
</source>

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

File:Package.jpg

2010-10-15T23:30:20Z

Rsoni:

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:28:51Z

Rsoni: /* Packages */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:20:38Z

Rsoni: /* Overview */

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

<source lang="java">

package A;
class A1{
int var = 4;
}

package B;
class B1{
int var = 12;
}

</source>

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T23:19:19Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

====Implicit Namespaces====

'''Implicit Namespaces''' are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

=====Packages=====

Packages can be used as a mechanism to organize classes into namespaces which are mapped to file system. A unique namespace is provided by each package which gives flexibility to define same identifier name over different packages.

<source lang="java">
package A;
class A1{
int var = 4;
}

package B;
class B1{
int var = 12;
}

</source>

Explicit Namespaces

Namespaces can be explicitly manipulated and composed, making it quite a simple matter to combine, rename and compose packages or modules.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T22:16:51Z

Rsoni:

'''Namespaces''' is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

==Overview==

A namespace is a way to keep names organized.Lets use an analogy to file system in the computer which uses directories and sub directories.Namespaces in this context could be viewed as the path to a file in the directory/subdirectory which can uniquely identify each file.

[[Image:Namespace.jpg|frame|center]]
===Types of Namespaces===

Implicit Namespaces are the abstraction defined by language itself in order to resolve name conflicts.Some of the constructs of implicit namespaces in different languages are records,dictionaries,objects, environments,packages,interface,scope resolution.

Explicit Namespaces

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

File:Namespace.jpg

2010-10-15T22:16:15Z

Rsoni:

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T20:52:17Z

Rsoni:

'''Namespaces'''is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context. [http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces] give you control over the visibility of the properties and methods that you create.

=Overview=

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

[http://en.wikipedia.org/wiki/General-purpose_programming_language General Programming languages] are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"

CSC/ECE 517 Fall 2010/ch4 4d PR

2010-10-15T20:49:21Z

Rsoni:

'''Namespaces'''
Namespace is a set of names which are bound together to form unique identifier in order to resolve conflict with same names from different context.[http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f9e.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f91 Namespaces ] give you control over the visibility of the properties and methods that you create.

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

[http://en.wikipedia.org/wiki/General-purpose_programming_language General Programming languages] are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic.

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL[7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs [7].

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages.[6]

The core requirements for a DSL are as follows:

*Conformity: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.

*Supportability: it is feasible to provide DSL support via domain specific popular tools, for typical model and program management. It will be of great ease if the DSL support is provided via tools, which are already used by the people of specified domain. The host tool can easily take care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the domain. This is essential for easy adaptation of existing applications to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

There are associated risk and opportunities related to any DSL which decides its success. Before deciding on the creation of the new DSL, one should always make sure that the amount of opportunities related to its creation are more than the risk involved. The following are the typical risks and opportunities related to any DSL[7].
===The Opportunities===

* DSLs allows a solution to be expressed more particularly in the domain of the problem, thus development of DSL programs is easy for the domain experts.

* Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

* DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

* They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

* It enables programs to be validated and optimized at the domain level.

* Since it is specific to a language improves its ability to be tested.

* It gives better end user experience.

* They are easy and exciting for the problem domain experts.

===The Risks===

* The cost of designing, implementing and maintaining DSL is high.

* The additional cost of educating the users to learn DSL.

* The domain experts need to have knowledge about language design principles in order to develop it a DSL.

* The scope of DSL is not defined.

* It is difficult to balance between domain-specificity and general-purpose programming constructs.

* It does not have a strong development tool support as compared to other general purpose programming languages. Eg. [http://en.wikipedia.org/wiki/NetBeans NetBeans] and [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] for Java, C++, etc.

==DSL v/s Object Oriented Frameworks==

Domain Specific object oriented languages can be easily used to develop readable and maintainable applications in a particular domain. Whereas construction of closely related programs in any domain can be achieved easily using object oriented framework.

They can be compared on the basis following criterion:-

* Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

* The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

* Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

* Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

The following are the open issues related to DSL that require further investigation. [7]

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] Matteo Bordin, Tullio Vardanega "A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components"

[2] Van Deursen "Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study"

[3] Jan Heering, Marjan Mernik "Domain-Specific Languages for Software Engineering"

[4] Martin Karlsch "A model-driven framework for domain specific languages demonstrated on a test automation language"

[5] Uwe Zdun "Concepts for ModelDriven Design and Evolution of DomainSpecific Languages" 

[6] Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack "Requirements for Domain-Specific Languages"

[7] Paul Klint, Joost Visser "Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen"