CSC/ECE 517 Fall 2010/ch4 4d PR: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 178: Line 178:
   }
   }
  }
  }
===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. <sup>[3]</sup>
*[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<sup>[7]</sup>.
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 <sup>[7]</sup>.
==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.<sup>[6]</sup>
The core requirements for a DSL are as follows:
*<strong>Conformity</strong>: The language must address to all the important concepts of the target domain. This is the basic requirement for any DSL.
*<strong>Supportability</strong>: 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.
*<strong>Integrability</strong>: 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.
*<strong>Longevity</strong>: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.
*<strong>Simplicity</strong>: 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.
*<strong>Quality</strong>: 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<sup>[7]</sup>.
===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:-
*<strong> Expressiveness: </strong>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.
*<strong> The Calling Framework:</strong> 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. <sup>[2]</sup>
*<strong> Overriding Default Behavior: </strong> 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. <sup>[2]</sup>
*<strong> Language technology:</strong> 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. <sup>[2]</sup>
==Open Issues or challenges related to DSLs==
The following are the open issues related to DSL that require further investigation. <sup>[7]</sup>
* 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==
==Conclusion==



Revision as of 01:41, 16 October 2010

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 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.

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");
      }
  }
}

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 Model­Driven Design and Evolution of Domain­Specific 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"