Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch7 7e GP

2010-11-28T06:32:09Z

Gpascar:

= Protected Variations Pattern =
GRASP stands for General Responsibility Assignment Software Patterns and defines nine patterns, of which '''protected variations ''' is one [1].
<blockquote>The protected variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.[1]</blockquote>

== Description ==
What this means is that any points where one system (A) touches another (B) where the implementation of that other system (B) contains variations in it's implementation. A good example of this is a standard plugin system. For example, an author may develop a plugin for Microsoft Outlook (a popular enterprise mail application). The '''protected variations pattern''' means that plugin should be wrapped within some kind of protection that would insulate Outlook from errant behaviors of that plugin. It may be disastrous if the plugin generated some sort of error that caused the entire application to crash.

== Solution ==
The solution to these problems is very dependent on the system being analyzed. The first step is to identify all of the points of predicted variation of instability. Then a developer needs to create a stable ''interface'' around those points [2]. This solution has many potential problems in and of itself. It assumes a developer is intimately familiar with the entire system and all potential points of variation or instability. Second, it assumes a developer knows the perfect way to insulate the system from the variation. Finally, it employs the word ''interface'' in a very broad sense. It may be a single component, like a very simple object or an external system, like a web server.

=== Insulation ===
Protecting a system from variations requires a thorough understanding of how the system may be exploited by the variation and what potential problems may arise from such a variation. For example, a database driver subsystem within the Java language may be insulated by catching ''SQLException'' exceptions.
<code>
...
try {
variant_method();
} catch ( SQLException e ) {
// Handle exception
}
...
</code>

However, what happens if the variant method generates an ''Exception'' that is not a subclass of ''SQLException''? In this scenario the ''Exception'' would bubble up out of the protected area. The obvious solution is to catch all ''Exception''s.
<code>
...
try {
variant_method();
} catch ( Throwable e ) {
// Handle exception
}
...
</code>

However, this has potentially undesirable effects also. What happens if there is a system-level exception, such as the system runs out of memory? This seems like an exception that would need to be communicated to a higher level and not consumed in the protection scheme.

The answer is, it depends. Generally there will be a documented contract within the ''interface'' of the variant. The protection then checks that these error conditions don't violate the contract. This is good design and should be part of a system's design regardless.

== Examples ==
Before discussing a specific example, it is important to understand that the '''protected variations''' pattern is present in almost every aspect of design. Consider virtual machines, plugin containers, sandboxes, configuration files and operating systems as specializations of the this pattern [3]. Generally examples are classified by the type of mechanisms that have motivated the '''protected variations''' pattern in the first place. The following sections have followed those first described by Larman, but with updated examples.

=== Data-Driven Designs ===
Any piece of data that is read into a system in order to affect the system's behavior in some manner. For example, in a Ruby on Rails application the ''database.yml'' file defines database drivers to load and configuration parameters for these drivers. Some drivers require the definition of a username and password, while others require the definition of a file path, it is up to the driver as to which parameters to require.

=== Service Lookup ===
This specialization uses a lookup service as a stable interface that is used to find a particular implementation of a component through the use of something like a naming service. The classic example of this is the Java Naming and Directory Interface (JNDI), another example is the Ruby Gem system. Using standard commands through the stable gem tool allows a developer to lookup and install gems to perform potentially unstable operations.

=== Interpreter-Driven Designs ===
The premise behind interpreter-driven designs is an interpreter loads a particular file and executes the commands within that file to affect some result. The stable interface being the interpreter and the variant the interpreted code file that is loaded. The Ruby interpreter is a great example of this.

=== Reflective or Meta-Level Designs ===
This specialization refers to not designing a stable system to a particular interface or implementation, but introspecting that interface at run-time. For example, a Ruby class would have its methods introspected to find the correct implementation that would then be executed within another protection level.
<code>
class Variant_1
def vvv
@very_very_verbose = true
end
end
class Variant_2
def vv
@very_verbose = true
end
end

v = Variant_1.new # or Variant_2.new
if ( v.methods.include? "vvv" )
m = v.method :vvv
elsif ( v.methods.include? "vv" )
m = v.method :vv
end

protect_method_call( m.call )
</code>

== Conclusion ==
When implemented correctly the '''protected variations''' pattern can provide stability to a system that needs to open itself up to potentially unsafe or unstable variations. The benefits include [3]
* Extensions required for new variations are easy to add.
* New implementations can be introduced without affecting clients.
* Coupling is lowered.
* The impact or cost of changes can be lowered.

This pattern is the same as information hiding and the open-closed principal in almost every regard.

== References ==
# [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP (object-oriented design)]
# [http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/ProtectedVariations.html Worcester Polytechnic Institute - CS4233: Class 4 Patterns - GRASP]
# Craig Larman (2004) ''Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition'', ISBN : 0131489062

CSC/ECE 517 Fall 2010/ch7 7e GP

2010-11-28T06:17:40Z

Gpascar:

= Protected Variations Pattern =
GRASP stands for General Responsibility Assignment Software Patterns and defines nine patterns, of which '''protected variations ''' is one [1].
<blockquote>The protected variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.[1]</blockquote>

== Description ==
What this means is that any points where one system (A) touches another (B) where the implementation of that other system (B) contains variations in it's implementation. A good example of this is a standard plugin system. For example, an author may develop a plugin for Microsoft Outlook (a popular enterprise mail application). The '''protected variations pattern''' means that plugin should be wrapped within some kind of protection that would insulate Outlook from errant behaviors of that plugin. It may be disastrous if the plugin generated some sort of error that caused the entire application to crash.

== Solution ==
The solution to these problems is very dependent on the system being analyzed. The first step is to identify all of the points of predicted variation of instability. Then a developer needs to create a stable ''interface'' around those points [2]. This solution has many potential problems in and of itself. It assumes a developer is intimately familiar with the entire system and all potential points of variation or instability. Second, it assumes a developer knows the perfect way to insulate the system from the variation. Finally, it employs the word ''interface'' in a very broad sense. It may be a single component, like a very simple object or an external system, like a web server.

=== Insulation ===
Protecting a system from variations requires a thorough understanding of how the system may be exploited by the variation and what potential problems may arise from such a variation. For example, a database driver subsystem within the Java language may be insulated by catching ''SQLException'' exceptions.
<code>
...
try {
variant_method();
} catch ( SQLException e ) {
// Handle exception
}
...
</code>

However, what happens if the variant method generates an ''Exception'' that is not a subclass of ''SQLException''? In this scenario the ''Exception'' would bubble up out of the protected area. The obvious solution is to catch all ''Exception''s.
<code>
...
try {
variant_method();
} catch ( Throwable e ) {
// Handle exception
}
...
</code>

However, this has potentially undesirable effects also. What happens if there is a system-level exception, such as the system runs out of memory? This seems like an exception that would need to be communicated to a higher level and not consumed in the protection scheme.

The answer is, it depends. Generally there will be a documented contract within the ''interface'' of the variant. The protection then checks that these error conditions don't violate the contract. This is good design and should be part of a system's design regardless.

== Examples ==
Before discussing a specific example, it is important to understand that the '''protected variations''' pattern is present in almost every aspect of design. Consider virtual machines, plugin containers, sandboxes, configuration files and operating systems as specializations of the this pattern [3]. Generally examples are classified by the type of mechanisms that have motivated the '''protected variations''' pattern in the first place. The following sections have followed those first described by Larman, but with updated examples.

=== Data-Driven Designs ===
Any piece of data that is read into a system in order to affect the system's behavior in some manner. For example, in a Ruby on Rails application the ''database.yml'' file defines database drivers to load and configuration parameters for these drivers. Some drivers require the definition of a username and password, while others require the definition of a file path, it is up to the driver as to which parameters to require.

=== Service Lookup ===
This specialization uses a lookup service as a stable interface that is used to find a particular implementation of a component through the use of something like a naming service. The classic example of this is the Java Naming and Directory Interface (JNDI), another example is the Ruby Gem system. Using standard commands through the stable gem tool allows a developer to lookup and install gems to perform potentially unstable operations.

=== Interpreter-Driven Designs ===
The premise behind interpreter-driven designs is an interpreter loads a particular file and executes the commands within that file to affect some result. The stable interface being the interpreter and the variant the interpreted code file that is loaded. The Ruby interpreter is a great example of this.

=== Reflective or Meta-Level Designs ===
This specialization refers to not designing a stable system to a particular interface or implementation, but introspecting that interface at run-time. For example, a Ruby class would have its methods introspected to find the correct implementation that would then be executed within another protection level.
<code>
class Variant_1
def vvv
@very_very_verbose = true
end
end
class Variant_2
def vv
@very_verbose = true
end
end

v = Variant_1.new # or Variant_2.new
if ( v.methods.include? "vvv" )
m = v.method :vvv
elsif ( v.methods.include? "vv" )
m = v.method :vv
end

protect_method_call( m.call )
</code>

== Conclusion ==
When implemented correctly the '''protected variations''' pattern can provide stability to a system that needs to open itself up to potentially unsafe or unstable variations. The benefits include [3]
* Extensions required for new variations are easy to add.
* New implementations can be introduced without affecting clients.
* Coupling is lowered.
* The impact or cost of changes can be lowered.

This pattern is the same as information hiding and the open-closed principal in almost every regard.

== References ==
[1] http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29

[2] http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/ProtectedVariations.html

[3] Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, Addison Wesley, 2004, Section 25.4.

CSC/ECE 517 Fall 2010/ch7 7e GP

2010-11-24T01:48:05Z

Gpascar:

= Protected Variations pattern =

CSC/ECE 517 Fall 2010/ch1 S10 ms

2010-11-24T01:47:45Z

Gpascar:

*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]

*[[CSC/ECE 517 Fall 2010/ch1 1a br]]

*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]

*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]

*[[CSC/ECE 517 Fall 2010/ch1 1e az]]

*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]

*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]

*[[CSC/ECE 517 Fall 2010/ch1 25 ag]]

*[[CSC/ECE 517 Fall 2010/ch2 2b dg]]

*[[CSC/ECE 517 Fall 2010/ch1 2e RI]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]

*[[CSC/ECE 517 Fall 2010/ch2 2a CB]]

*[[CSC/ECE 517 Fall 2010/ch2 2a mw]]

*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 NS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 SS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 NR]]

*[[CSC/ECE 517 Fall 2010/ch2 S20 TT]]

*[[CSC/ECE 517 Fall 2010/ch2 2d AS]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 rm]]

*[[CSC/ECE 517 Fall 2010/ch3 3a SN]]

*[[CSC/ECE 517 Fall 2010/ch3 3b ka]]

*[[CSC/ECE 517 Fall 2010/ch3 3e br]]

*[[CSC/ECE 517 Fall 2010/ch3 3f lj]]

*[[CSC/ECE 517 Fall 2010/ch3 3h az]]

*[[CSC/ECE 517 Fall 2010/ch3 3h PW]]

*[[CSC/ECE 517 Fall 2010/ch3 3i IC]]

*[[CSC/ECE 517 Fall 2010/ch3 3i MM]]

*[[CSC/ECE 517 Fall 2010/ch3 3j KS]]

*[[CSC/ECE 517 Fall 2010/ch3 S30 SK]]

*[[CSC/ECE 517 Fall 2010/ch3 4b mt]]

*[[CSC/ECE 517 Fall 2010/ch4 4e ms]]

*[[CSC/ECE 517 Fall 2010/ch4 4f sv]]

*[[CSC/ECE 517 Fall 2010/ch4 4g HW]]

*[[CSC/ECE 517 Fall 2010/ch4 4g km]]

*[[CSC/ECE 517 Fall 2010/ch4 4h am]]

*[[CSC/ECE 517 Fall 2010/ch5 5b mt]]

*[[CSC/ECE 517 Fall 2010/ch5 5b jz]]

*[[CSC/ECE 517 Fall 2010/ch5 5c ck]]

*[[CSC/ECE 517 Fall 2010/ch5 5c IC]]

*[[CSC/ECE 517 Fall 2010/ch5 5f SN]]

*[[CSC/ECE 517 Fall 2010/ch5 5a KR]]

*[[CSC/ECE 517 Fall 2010/ch5 5b RR]]

*[[CSC/ECE 517 Fall 2010/ch5 5e ms]]

*[[CSC/ECE 517 Fall 2010/chd 6d isb]]

*[[CSC/ECE 517 Fall 2010/ch6 6b SK]]

*[[CSC/ECE 517 Fall 2010/ch6 6c AW]]

*[[CSC/ECE 517 Fall 2010/ch6 6d bb]]

*[[CSC/ECE 517 Fall 2010/ch6 6h AS]]

*[[CSC/ECE 517 Fall 2010/ch6 6f AZ]]

*[[CSC/ECE 517 Fall 2010/ch6 6b AK]]

*[[CSC/ECE 517 Fall 2010/ch6 6g ss]]

*[[CSC/ECE 517 Fall 2010/ch6 6d NM]]

*[[ CSC/ECE 517 Fall 2010/ch6 6a PC]]

*[[ CSC/ECE 517 Fall 2010/ch2 4d RB]]

*[[ CSC/ECE 517 Fall 2010/ch7 7e GP]]

CSC/ECE 517 Fall 2010/ch4 4h GP

2010-11-24T01:45:55Z

Gpascar:

CSC/ECE 517 Fall 2010/ch4 4h GP

2010-11-24T01:33:38Z

Gpascar:

= Static-analysis tools for Ruby =
TODO by gpascar

CSC/ECE 517 Fall 2010/ch1 S10 ms

2010-11-24T01:32:31Z

Gpascar:

*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]

*[[CSC/ECE 517 Fall 2010/ch1 1a br]]

*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]

*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]

*[[CSC/ECE 517 Fall 2010/ch1 1e az]]

*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]

*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]

*[[CSC/ECE 517 Fall 2010/ch1 25 ag]]

*[[CSC/ECE 517 Fall 2010/ch2 2b dg]]

*[[CSC/ECE 517 Fall 2010/ch1 2e RI]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]

*[[CSC/ECE 517 Fall 2010/ch2 2a CB]]

*[[CSC/ECE 517 Fall 2010/ch2 2a mw]]

*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 NS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 SS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 NR]]

*[[CSC/ECE 517 Fall 2010/ch2 S20 TT]]

*[[CSC/ECE 517 Fall 2010/ch2 2d AS]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 rm]]

*[[CSC/ECE 517 Fall 2010/ch3 3a SN]]

*[[CSC/ECE 517 Fall 2010/ch3 3b ka]]

*[[CSC/ECE 517 Fall 2010/ch3 3e br]]

*[[CSC/ECE 517 Fall 2010/ch3 3f lj]]

*[[CSC/ECE 517 Fall 2010/ch3 3h az]]

*[[CSC/ECE 517 Fall 2010/ch3 3h PW]]

*[[CSC/ECE 517 Fall 2010/ch3 3i IC]]

*[[CSC/ECE 517 Fall 2010/ch3 3i MM]]

*[[CSC/ECE 517 Fall 2010/ch3 3j KS]]

*[[CSC/ECE 517 Fall 2010/ch3 S30 SK]]

*[[CSC/ECE 517 Fall 2010/ch3 4b mt]]

*[[CSC/ECE 517 Fall 2010/ch4 4e ms]]

*[[CSC/ECE 517 Fall 2010/ch4 4f sv]]

*[[CSC/ECE 517 Fall 2010/ch4 4g HW]]

*[[CSC/ECE 517 Fall 2010/ch4 4g km]]

*[[CSC/ECE 517 Fall 2010/ch4 4h am]]

*[[CSC/ECE 517 Fall 2010/ch4 4h GP]]

*[[CSC/ECE 517 Fall 2010/ch5 5b mt]]

*[[CSC/ECE 517 Fall 2010/ch5 5b jz]]

*[[CSC/ECE 517 Fall 2010/ch5 5c ck]]

*[[CSC/ECE 517 Fall 2010/ch5 5c IC]]

*[[CSC/ECE 517 Fall 2010/ch5 5f SN]]

*[[CSC/ECE 517 Fall 2010/ch5 5a KR]]

*[[CSC/ECE 517 Fall 2010/ch5 5b RR]]

*[[CSC/ECE 517 Fall 2010/ch5 5e ms]]

*[[CSC/ECE 517 Fall 2010/chd 6d isb]]

*[[CSC/ECE 517 Fall 2010/ch6 6b SK]]

*[[CSC/ECE 517 Fall 2010/ch6 6c AW]]

*[[CSC/ECE 517 Fall 2010/ch6 6d bb]]

*[[CSC/ECE 517 Fall 2010/ch6 6h AS]]

*[[CSC/ECE 517 Fall 2010/ch6 6f AZ]]

*[[CSC/ECE 517 Fall 2010/ch6 6b AK]]

*[[CSC/ECE 517 Fall 2010/ch6 6g ss]]

*[[CSC/ECE 517 Fall 2010/ch6 6d NM]]

*[[ CSC/ECE 517 Fall 2010/ch6 6a PC]]

*[[ CSC/ECE 517 Fall 2010/ch2 4d RB]]

CSC/ECE 517 Fall 2010/ch2 S23 GP

2010-10-01T15:18:04Z

Gpascar: /* Internal vs. External */

== Introduction to Object-Oriented Domain-Specific Languages ==
Domain-specific Languages, or DSLs, are programming languages or a subset of other languages that are used to solve domain specific problems. This is in opposition to general purpose programming languages that are used for all problems. The advantage of DSLs over general purpose languages is they are more targeted to a specific set of problems that may be higher level than is necessary for a general purpose language. Domain-specific languages are very ubiquitous, even though it may not be apparent. Here are examples of some domain-specific languages:
* CSS
* SQL
* Regular Expressions
* UnrealScript <sup>[3]</sup>

General purpose languages contain more functionality than DSLs and generally provide specific system level access. Of course this may be a misnomer since a DSL may be developed specifically to handle system level APIs, like file systems. Examples of general purpose languages include:
* Java
* C++
* C#

Object-oriented Domain-specific Languages (OODSLs) differ from traditional DSLs in the same way that traditional languages differ from their object-oriented counterparts. An OOP uses "objects", which are data structures that contain both data members and methods. Therefore, OODSLs are simply DSLs that employ and object-oriented paradigm. Examples of OODSLs are:
* Scalable Vector Graphics (SVG) <sup>[7]</sup>
* Extensible Application Markup Language (XAML) <sup>[6]</sup>
* Kiddo
* Spring Configuration

== Internal vs. External ==
Among OODSLs there is a distinction between internal OODSLs and external OODSLs <sup>[5]</sup>. Internal or embedded OODSLs give a "host" language domain-specific extensions or elements. For example, an internal OODSL may extend a general purpose language to allow for easier implementation of generating graphics through the use of specific APIs. An example of an embedded OODSL is JavaScript hosted within an HTML document.

However, there is a fuzzy line between embedded OODSLs and 3rd party libraries. For example, the drawing methods of a Graphics object within Java may be considered an embedded OODSL or just a series of library APIS that are used in a contractual way.

External OODSLs are languages that are not hosted within another language, but are compiled or interpreted in a standalone manner. These OODSLs usually have a complete tool set and development environment behind them. It is up to the language implementer, but external OODSLs are generally interpreted instead of compiled. However, an OODSL does not necessarily need to be compiled into executable code. An OODSL may be a representation of something else. The CSound OODSL compiles an Orchestra and Score markup files into audio. Another example is compiling or converting SVG into a rasterized image, such as Portable Network Graphics (PNG).

== Practical Example: Java Swing and SVG ==
One way to illustrate the benefits of OODSLs is to compare a OODSL and a general purpose language performing the same task. The following practical example illustrates how a language like Java and an OODSL perform painting tasks. Both examples will draw a square button with the word ''Button'' in the center. The Java code is taken from a common [http://en.wikipedia.org/wiki/Java_Swing Swing] construct where a JButton overrides its paintComponent method to draw something more custom than the Swing default look and feel. The Java Graphics API is used to perform both vector and raster drawing operations within a Java application. These operations could be used for either drawing user interfaces or directly onto in-memory images for later display. Here is an example of drawing a square button using a Java Graphics object.

<pre>
@Override
protected void paintComponent(Graphics g) {
// Save the current context's color
Color savedColor = g.getColor();

// Fill the shape
g.setColor(Color.gray);
g.fillRect(0, 0, getWidth(), getHeight());

// Draw the text
g.setColor(Bolor.black);
g.drawString("Button", 2, getHeight()-3);

// Draw the border
g.setColor(Color.black);
g.drawRect(0, 0, getWidth()-1, getHeight()-1);

// Restore the context's color
g.setColor(savedColor);
}
</pre>

This is quite procedural despite it being a methodology within an object-oriented language. Using a general purpose language like Java to perform something as domain-specific as graphics generation can lead to a lot of redundant overhead that is taken care of in a specialized language. This example illustrated the saving and restoring of the Graphic object's ''Color'' attribute, but could have required the saving and subsequent restoration of multiple properties, such as the current ''Transform'', ''Stroke'' or ''Font''. An OODSL would provide a more robust and flexible set of drawing and graphics APIs that would ideally perform the redundant tasks like saving and restoring the graphics state attributes, as is the case with SVG. Here is the same example written in using this OODSL.

<pre>
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="10%" height="10%" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%"
style="fill:rgb(128,128,128);stroke-width:1;stroke:rgb(0,0,0)" />
<text x="35%" y="50%">Button</text>
</svg>
</pre>

This code is more declarative, object-oriented and much less procedural. Instead of using a method to draw a rectangle the rectangle itself is an object with many data members used to define how the rectangle is rendered. Ironically, the style attribute of the rectangle is a subset of CSS, another OODSL. Since SVG is a language specific to the vector and imagery domain it provides capabilities (like opacity and gradients) that may be difficult to perform in general purpose languages without specialized libraries or an internal OODSL.

The SVG declaration could be "compiled" into an image format (such as JPG) as opposed to the Java code, which can only paint on the Graphics context passed into it. The point is the SVG implementation is more versatile within the image domain in performing the same or similar methods as a general purpose language like Java.

== When should OODSLs be used? ==
In order to determine if a OODSL should be used or created you must first examine the advantages of OODSLs. If the problem domain is a well-known domain that already has an OODSL defined for it then it may be useful to use this OODSL, after all it was created for a reason. If the selected OODSL does not fully support the operations needed for the problem domain then maybe a different OODSL is needed or the OODSL needs to be extended.

If, however, there is no existing OODSL defined then creating a new OODSL may be the answer. This usually happens when there is a well-defined or at least well-understood domain where certain operations are performed over and over again. For example, a good candidate for an OODSL is robotics. Consider a robotic arm in a factory that needs to perform repetitive tasks such as picking up an object from one conveyor belt and moving it to another. If there is a OODSL that defines the movements of the arm then new behaviors could be easily added to the armature and existing actions can be easily changed. These changes in behavior may even be performed by a technician or subject matter expert (SME) instead of a developer.

== Conclusion ==
Object-oriented Domain-specific Languages provide a level of abstraction to a given domain. This abstraction may result in enhanced capabilities (such as rapid prototyping) or a greater control or understanding of that domain. It may also enable non-developers, like SMEs, to write "code" that utilizes the OODSL to affect a system or generate some sort of output. OODSLs are classified as either internal or external where internal is an OODSL that "lives" within a host language and external is a standalone language in its own right. General purpose languages are good for just that, general purpose development. OODSLs are very focused and are prevalent in almost every niche of computing.

== References ==
* [1] Mernik, M., Heering, J., and Sloane, A. M. 2005. When and how to develop domain-specific languages. ACM Comput. Surv. 37, 4 (Dec. 2005), 316-344. DOI= http://doi.acm.org/10.1145/1118890.1118892
* [2] "Domain-specific Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/Domain-specific_language.
* [3] "UnrealScript." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/UnrealScript.
* [4] "InfoQ: What's a Ruby DSL and What Isn't?" ''InfoQ: Tracking Change and Innovation in the Enterprise Software Development Community.'' Web. 08 Sept. 2010. http://www.infoq.com/news/2007/06/dsl-or-not.
* [5] "MF Bliki: DomainSpecificLanguage." ''Martin Fowler.'' Web. 08 Sept. 2010. http://www.martinfowler.com/bliki/DomainSpecificLanguage.html.
* [6] "Extensible Application Markup Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/XAML.
* [7] "Scalable Vector Graphics." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/SVG.

CSC/ECE 517 Fall 2010/ch2 S23 GP

2010-10-01T15:17:25Z

Gpascar: /* Introduction to Object-Oriented Domain-Specific Languages */

== Introduction to Object-Oriented Domain-Specific Languages ==
Domain-specific Languages, or DSLs, are programming languages or a subset of other languages that are used to solve domain specific problems. This is in opposition to general purpose programming languages that are used for all problems. The advantage of DSLs over general purpose languages is they are more targeted to a specific set of problems that may be higher level than is necessary for a general purpose language. Domain-specific languages are very ubiquitous, even though it may not be apparent. Here are examples of some domain-specific languages:
* CSS
* SQL
* Regular Expressions
* UnrealScript <sup>[3]</sup>

General purpose languages contain more functionality than DSLs and generally provide specific system level access. Of course this may be a misnomer since a DSL may be developed specifically to handle system level APIs, like file systems. Examples of general purpose languages include:
* Java
* C++
* C#

Object-oriented Domain-specific Languages (OODSLs) differ from traditional DSLs in the same way that traditional languages differ from their object-oriented counterparts. An OOP uses "objects", which are data structures that contain both data members and methods. Therefore, OODSLs are simply DSLs that employ and object-oriented paradigm. Examples of OODSLs are:
* Scalable Vector Graphics (SVG) <sup>[7]</sup>
* Extensible Application Markup Language (XAML) <sup>[6]</sup>
* Kiddo
* Spring Configuration

== Internal vs. External ==
Among OODSLs there is a distinction between internal OODSLs and external OODSLs. Internal or embedded OODSLs give a "host" language domain-specific extensions or elements. For example, an internal OODSL may extend a general purpose language to allow for easier implementation of generating graphics through the use of specific APIs. An example of an embedded OODSL is JavaScript hosted within an HTML document.

However, there is a fuzzy line between embedded OODSLs and 3rd party libraries. For example, the drawing methods of a Graphics object within Java may be considered an embedded OODSL or just a series of library APIS that are used in a contractual way.

External OODSLs are languages that are not hosted within another language, but are compiled or interpreted in a standalone manner. These OODSLs usually have a complete tool set and development environment behind them. It is up to the language implementer, but external OODSLs are generally interpreted instead of compiled. However, an OODSL does not necessarily need to be compiled into executable code. An OODSL may be a representation of something else. The CSound OODSL compiles an Orchestra and Score markup files into audio. Another example is compiling or converting SVG into a rasterized image, such as Portable Network Graphics (PNG).

== Practical Example: Java Swing and SVG ==
One way to illustrate the benefits of OODSLs is to compare a OODSL and a general purpose language performing the same task. The following practical example illustrates how a language like Java and an OODSL perform painting tasks. Both examples will draw a square button with the word ''Button'' in the center. The Java code is taken from a common [http://en.wikipedia.org/wiki/Java_Swing Swing] construct where a JButton overrides its paintComponent method to draw something more custom than the Swing default look and feel. The Java Graphics API is used to perform both vector and raster drawing operations within a Java application. These operations could be used for either drawing user interfaces or directly onto in-memory images for later display. Here is an example of drawing a square button using a Java Graphics object.

<pre>
@Override
protected void paintComponent(Graphics g) {
// Save the current context's color
Color savedColor = g.getColor();

// Fill the shape
g.setColor(Color.gray);
g.fillRect(0, 0, getWidth(), getHeight());

// Draw the text
g.setColor(Bolor.black);
g.drawString("Button", 2, getHeight()-3);

// Draw the border
g.setColor(Color.black);
g.drawRect(0, 0, getWidth()-1, getHeight()-1);

// Restore the context's color
g.setColor(savedColor);
}
</pre>

This is quite procedural despite it being a methodology within an object-oriented language. Using a general purpose language like Java to perform something as domain-specific as graphics generation can lead to a lot of redundant overhead that is taken care of in a specialized language. This example illustrated the saving and restoring of the Graphic object's ''Color'' attribute, but could have required the saving and subsequent restoration of multiple properties, such as the current ''Transform'', ''Stroke'' or ''Font''. An OODSL would provide a more robust and flexible set of drawing and graphics APIs that would ideally perform the redundant tasks like saving and restoring the graphics state attributes, as is the case with SVG. Here is the same example written in using this OODSL.

<pre>
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="10%" height="10%" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%"
style="fill:rgb(128,128,128);stroke-width:1;stroke:rgb(0,0,0)" />
<text x="35%" y="50%">Button</text>
</svg>
</pre>

This code is more declarative, object-oriented and much less procedural. Instead of using a method to draw a rectangle the rectangle itself is an object with many data members used to define how the rectangle is rendered. Ironically, the style attribute of the rectangle is a subset of CSS, another OODSL. Since SVG is a language specific to the vector and imagery domain it provides capabilities (like opacity and gradients) that may be difficult to perform in general purpose languages without specialized libraries or an internal OODSL.

The SVG declaration could be "compiled" into an image format (such as JPG) as opposed to the Java code, which can only paint on the Graphics context passed into it. The point is the SVG implementation is more versatile within the image domain in performing the same or similar methods as a general purpose language like Java.

== When should OODSLs be used? ==
In order to determine if a OODSL should be used or created you must first examine the advantages of OODSLs. If the problem domain is a well-known domain that already has an OODSL defined for it then it may be useful to use this OODSL, after all it was created for a reason. If the selected OODSL does not fully support the operations needed for the problem domain then maybe a different OODSL is needed or the OODSL needs to be extended.

If, however, there is no existing OODSL defined then creating a new OODSL may be the answer. This usually happens when there is a well-defined or at least well-understood domain where certain operations are performed over and over again. For example, a good candidate for an OODSL is robotics. Consider a robotic arm in a factory that needs to perform repetitive tasks such as picking up an object from one conveyor belt and moving it to another. If there is a OODSL that defines the movements of the arm then new behaviors could be easily added to the armature and existing actions can be easily changed. These changes in behavior may even be performed by a technician or subject matter expert (SME) instead of a developer.

== Conclusion ==
Object-oriented Domain-specific Languages provide a level of abstraction to a given domain. This abstraction may result in enhanced capabilities (such as rapid prototyping) or a greater control or understanding of that domain. It may also enable non-developers, like SMEs, to write "code" that utilizes the OODSL to affect a system or generate some sort of output. OODSLs are classified as either internal or external where internal is an OODSL that "lives" within a host language and external is a standalone language in its own right. General purpose languages are good for just that, general purpose development. OODSLs are very focused and are prevalent in almost every niche of computing.

== References ==
* [1] Mernik, M., Heering, J., and Sloane, A. M. 2005. When and how to develop domain-specific languages. ACM Comput. Surv. 37, 4 (Dec. 2005), 316-344. DOI= http://doi.acm.org/10.1145/1118890.1118892
* [2] "Domain-specific Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/Domain-specific_language.
* [3] "UnrealScript." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/UnrealScript.
* [4] "InfoQ: What's a Ruby DSL and What Isn't?" ''InfoQ: Tracking Change and Innovation in the Enterprise Software Development Community.'' Web. 08 Sept. 2010. http://www.infoq.com/news/2007/06/dsl-or-not.
* [5] "MF Bliki: DomainSpecificLanguage." ''Martin Fowler.'' Web. 08 Sept. 2010. http://www.martinfowler.com/bliki/DomainSpecificLanguage.html.
* [6] "Extensible Application Markup Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/XAML.
* [7] "Scalable Vector Graphics." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/SVG.

CSC/ECE 517 Fall 2010/ch2 S23 GP

2010-10-01T14:50:54Z

Gpascar:

== Introduction to Object-Oriented Domain-Specific Languages ==
Domain-specific Languages, or DSLs, are programming languages or a subset of other languages that are used to solve domain specific problems. This is in opposition to general purpose programming languages that are used for all problems. The advantage of DSLs over general purpose languages is they are more targeted to a specific set of problems that may be higher level than is necessary for a general purpose language. Domain-specific languages are very ubiquitous, even though it may not be apparent. Here are examples of some domain-specific languages:
* CSS
* SQL
* Regular Expressions
* UnrealScript <sup>[3]</sup>

General purpose languages contain more functionality than DSLs and generally provide specific system level access. Of course this may be a misnomer since a DSL may be developed specifically to handle system level APIs, like file systems. Examples of general purpose languages include:
* Java
* C++
* C#

Object-oriented Domain-specific Languages (OODSLs) differ from traditional DSLs in the same way that traditional languages differ from their object-oriented counterparts. An OOP uses "objects", which are data structures that contain both data members and methods. Therefore, OODSLs are simply DSLs that employ and object-oriented paradigm. Examples of OODSLs are:
* Scalable Vector Graphics (SVG)
* Extensible Application Markup Language (XAML) <sup>[6]</sup>
* Kiddo
* Spring Configuration

== Internal vs. External ==
Among OODSLs there is a distinction between internal OODSLs and external OODSLs. Internal or embedded OODSLs give a "host" language domain-specific extensions or elements. For example, an internal OODSL may extend a general purpose language to allow for easier implementation of generating graphics through the use of specific APIs. An example of an embedded OODSL is JavaScript hosted within an HTML document.

However, there is a fuzzy line between embedded OODSLs and 3rd party libraries. For example, the drawing methods of a Graphics object within Java may be considered an embedded OODSL or just a series of library APIS that are used in a contractual way.

External OODSLs are languages that are not hosted within another language, but are compiled or interpreted in a standalone manner. These OODSLs usually have a complete tool set and development environment behind them. It is up to the language implementer, but external OODSLs are generally interpreted instead of compiled. However, an OODSL does not necessarily need to be compiled into executable code. An OODSL may be a representation of something else. The CSound OODSL compiles an Orchestra and Score markup files into audio. Another example is compiling or converting SVG into a rasterized image, such as Portable Network Graphics (PNG).

== Practical Example: Java Swing and SVG ==
One way to illustrate the benefits of OODSLs is to compare a OODSL and a general purpose language performing the same task. The following practical example illustrates how a language like Java and an OODSL perform painting tasks. Both examples will draw a square button with the word ''Button'' in the center. The Java code is taken from a common [http://en.wikipedia.org/wiki/Java_Swing Swing] construct where a JButton overrides its paintComponent method to draw something more custom than the Swing default look and feel. The Java Graphics API is used to perform both vector and raster drawing operations within a Java application. These operations could be used for either drawing user interfaces or directly onto in-memory images for later display. Here is an example of drawing a square button using a Java Graphics object.

<pre>
@Override
protected void paintComponent(Graphics g) {
// Save the current context's color
Color savedColor = g.getColor();

// Fill the shape
g.setColor(Color.gray);
g.fillRect(0, 0, getWidth(), getHeight());

// Draw the text
g.setColor(Bolor.black);
g.drawString("Button", 2, getHeight()-3);

// Draw the border
g.setColor(Color.black);
g.drawRect(0, 0, getWidth()-1, getHeight()-1);

// Restore the context's color
g.setColor(savedColor);
}
</pre>

This is quite procedural despite it being a methodology within an object-oriented language. Using a general purpose language like Java to perform something as domain-specific as graphics generation can lead to a lot of redundant overhead that is taken care of in a specialized language. This example illustrated the saving and restoring of the Graphic object's ''Color'' attribute, but could have required the saving and subsequent restoration of multiple properties, such as the current ''Transform'', ''Stroke'' or ''Font''. An OODSL would provide a more robust and flexible set of drawing and graphics APIs that would ideally perform the redundant tasks like saving and restoring the graphics state attributes, as is the case with SVG. Here is the same example written in using this OODSL.

<pre>
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="10%" height="10%" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%"
style="fill:rgb(128,128,128);stroke-width:1;stroke:rgb(0,0,0)" />
<text x="35%" y="50%">Button</text>
</svg>
</pre>

This code is more declarative, object-oriented and much less procedural. Instead of using a method to draw a rectangle the rectangle itself is an object with many data members used to define how the rectangle is rendered. Ironically, the style attribute of the rectangle is a subset of CSS, another OODSL. Since SVG is a language specific to the vector and imagery domain it provides capabilities (like opacity and gradients) that may be difficult to perform in general purpose languages without specialized libraries or an internal OODSL.

The SVG declaration could be "compiled" into an image format (such as JPG) as opposed to the Java code, which can only paint on the Graphics context passed into it. The point is the SVG implementation is more versatile within the image domain in performing the same or similar methods as a general purpose language like Java.

== When should OODSLs be used? ==
In order to determine if a OODSL should be used or created you must first examine the advantages of OODSLs. If the problem domain is a well-known domain that already has an OODSL defined for it then it may be useful to use this OODSL, after all it was created for a reason. If the selected OODSL does not fully support the operations needed for the problem domain then maybe a different OODSL is needed or the OODSL needs to be extended.

If, however, there is no existing OODSL defined then creating a new OODSL may be the answer. This usually happens when there is a well-defined or at least well-understood domain where certain operations are performed over and over again. For example, a good candidate for an OODSL is robotics. Consider a robotic arm in a factory that needs to perform repetitive tasks such as picking up an object from one conveyor belt and moving it to another. If there is a OODSL that defines the movements of the arm then new behaviors could be easily added to the armature and existing actions can be easily changed. These changes in behavior may even be performed by a technician or subject matter expert (SME) instead of a developer.

== Conclusion ==
Object-oriented Domain-specific Languages provide a level of abstraction to a given domain. This abstraction may result in enhanced capabilities (such as rapid prototyping) or a greater control or understanding of that domain. It may also enable non-developers, like SMEs, to write "code" that utilizes the OODSL to affect a system or generate some sort of output. OODSLs are classified as either internal or external where internal is an OODSL that "lives" within a host language and external is a standalone language in its own right. General purpose languages are good for just that, general purpose development. OODSLs are very focused and are prevalent in almost every niche of computing.

== References ==
* [1] Mernik, M., Heering, J., and Sloane, A. M. 2005. When and how to develop domain-specific languages. ACM Comput. Surv. 37, 4 (Dec. 2005), 316-344. DOI= http://doi.acm.org/10.1145/1118890.1118892
* [2] "Domain-specific Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/Domain-specific_language.
* [3] "UnrealScript." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/UnrealScript.
* [4] "InfoQ: What's a Ruby DSL and What Isn't?" ''InfoQ: Tracking Change and Innovation in the Enterprise Software Development Community.'' Web. 08 Sept. 2010. http://www.infoq.com/news/2007/06/dsl-or-not.
* [5] "MF Bliki: DomainSpecificLanguage." ''Martin Fowler.'' Web. 08 Sept. 2010. http://www.martinfowler.com/bliki/DomainSpecificLanguage.html.
* [6] "Extensible Application Markup Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/XAML.
* [7] "Scalable Vector Graphics." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/SVG.

CSC/ECE 517 Fall 2010/ch2 S20 st

2010-09-18T20:07:07Z

Gpascar:

*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE 517 Fall 2010/ch1 1a br]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]

*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]

*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]

*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]

*[[CSC/ECE 517 Fall 2010/ch1 1e az]]

*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]

CSC/ECE 517 Fall 2010/ch1 S23 GP

2010-09-18T20:05:58Z

Gpascar: CSC/ECE 517 Fall 2010/ch1 S23 GP moved to CSC/ECE 517 Fall 2010/ch2 S23 GP: I was mistaken when I thought I was chapter 1.

#REDIRECT [[CSC/ECE 517 Fall 2010/ch2 S23 GP]]

CSC/ECE 517 Fall 2010/ch2 S23 GP

2010-09-18T20:05:58Z

Gpascar: CSC/ECE 517 Fall 2010/ch1 S23 GP moved to CSC/ECE 517 Fall 2010/ch2 S23 GP: I was mistaken when I thought I was chapter 1.

== Introduction to Object-Oriented Domain-Specific Languages ==
Domain-specific Languages, or DSLs, are programming languages or a subset of other languages that are used to solve domain specific problems. This is in opposition to general purpose programming languages that are used for all problems. The advantage of DSLs over general purpose languages are they are more targeted to a specific set of problems that may be higher level than is necessary for a general purpose language. Domain-specific languages are is use everyday, even though it may not be apparent. Here are examples of some domain-specific languages:
* CSS
* SQL
* Regular Expressions
* UnrealScript

General purpose languages contain more functionality than DSLs and generally provide specific system level access. Of course this may be a misnomer since a DSL may be developed specifically to handle system level APIs, like file systems. Examples of general purpose languages include:
* Java
* C++
* C#

Object-oriented Domain-specific Languages (OODSLs) differ from traditional DSLs in the same way that traditional languages differ from their object-oriented counterparts. An OOP uses "objects", which are data structures that contain both data members and methods. Therefore, OODSLs are simply DSLs that exmploy and object-oriented paradigm. Examples of OODSLs are:
* Scalable Vector Graphics (SVG)
* Extensible Application Markup Language (XAML)
* Kiddo
* Spring Configuration

== Internal vs. External ==
Among OODSLs there is a distinction between internal OODSLs and external OODSLs. Internal or embedded OODSLs give a "host" language domain-specific extensions or elements. For example, an internal OODSL may extend a general purpose language to allow for easier implementation of generating graphics through the use of specific APIs. An example of an embedded OODSL is Javascript hosted within an HTML document.

However, there is a fuzzy line between embedded OODSLs and 3rd party libraries. For example, the drawing methods of a Graphics object within Java may be considered an embedded OODSL or just a series of library APIS that are used in a contractual way.

External OODSLs are languages that are not hosted within another language, but are compiled or interpreted in a standalone manner. These OODSLs usually have a complete toolset and development environment behind them. It is up to the language implementor, but external OODSLs are generally interpreted instead of compiled. However, a OODSL does not necessarily need to be compiled into executable code. A OODSL may be a representation of something else. The CSound OODSL compiles a an Orchestra and Score markup files into audio. Another example is compiling or converting SVG into a rasterized image, such as Portable Networg Graphics (PNG).

== Practical Example: Java Swing and SVG ==
One way to illustrate the benefits of OODSLs is to compare a OODSL and a general purpose language performing the same task. The following practical example illustrates how a language like Java and an OODSL perform painting tasks. Both examples will draw a square button with the word ''Button'' in the center. The Java code is taken from a common [http://en.wikipedia.org/wiki/Java_Swing Swing] construct where a JButton overrides it's paintComponent method to draw something more custom than the Swing default look and feel. The Java Graphics API is used to perform both vector and raster drawing operations within a Java application. These operations could be used for either drawing user interfaces or directly onto in-memory images for later display. Here is an example of drawing a square button using a Java Graphics object.

<pre>
@Override
protected void paintComponent(Graphics g) {
// Save the current context's color
Color savedColor = g.getColor();

// Fill the shape
g.setColor(Color.gray);
g.fillRect(0, 0, getWidth(), getHeight());

// Draw the text
g.setColor(Bolor.black);
g.drawString("Button", 2, getHeight()-3);

// Draw the border
g.setColor(Color.black);
g.drawRect(0, 0, getWidth()-1, getHeight()-1);

// Restore the context's color
g.setColor(savedColor);
}
</pre>

This is quite procedural despite it being a methodology within an object-oriented language. Using a general purpose language like Java to perform something as domain-specific as graphics generation can lead to a lot of redundant overhead that is taken care of in a specialized language. This example illustrated the saving and restoring of the Graphic object's ''Color'' attribute, but could have required the saving and subsequent restoration of multiple properties, such as the current ''Transform'', ''Stroke'' or ''Font''. An OODSL would provide a more robust and flexible set of drawing and graphics APIs that would ideally perform the redundant tasks like saving and restoring the graphics state attributes, as is the case with SVG. Here is the same example written in using this OODSL.

<pre>
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="10%" height="10%" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%"
style="fill:rgb(128,128,128);stroke-width:1;stroke:rgb(0,0,0)" />
<text x="35%" y="50%">Button</text>
</svg>
</pre>

This code is more declarative, object-oriented and much less procedural. Instead of using a method to draw a rectangle the rectangle itself is an object with many data members used to define how the rectangle is rendered. Ironically, the style attribute of the rectangle is a subset of CSS, another OODSL. Since SVG is a language specific to the vector and imagery domain it provides capabilities (like opacity and gradients) that may be difficult to perform in general purpose languages without specialized libraries or an internal OODSL.

The SVG declaration could be "compiled" into an image format (such as JPG) as opposed to the Java code, which can only paint on the Graphics context passed into it. The point is, the SVG implementation is more versatile within the image domain in performing the same or similar methods as a general purpose language like Java.

== When should OODSLs be used? ==
In order to determine if a OODSL should be used or created you must first examine the advantages of OODSLs. If the problem domain is a well-known domain that already has an OODSL defined for it then it may be useful to use this OODSL, after all it was created for a reason. If the selected OODSL does not fully support the operations needed for the problem domain then maybe a different OODSL is needed or the OODSL needs to be extended.

If, however, there is no existing OODSL defined then creating a new OODSL may be the answer. This usually happens when there is a well-defined or at least well-understood domain where certain operations are performed over and over again. For example, a good candidate for an OODSL is robotics. Consider a robotic arm in a factory that needs to perform repetetive tasks such as picking up an object from one conveyor belt and moving it to another. If there is a OODSL that defines the movements of the arm then new behaviors could be easily added to the armature and existing actions can be easily changed. These changes in behavior may even be performed by a technician or subject matter expert (SME) instead of a developer.

== Conclusion ==
Object-oriented Domain-specific Languages provide a level of abstraction to a given domain. This abstraction may result in enhanced capabilities (such as rapid prototyping) or a greater control or understanding of that domain. It may also enable non-developers, like SMEs, to write "code" that utilizes the OODSL to affect a system or generate some sort of output. OODSLs are classified as either internal or external where internal is an OODSL that "lives" within a host language and external is a standalone language in its own right. General purpose languages are good for just that, general purpose development. OODSLs are very focused and are prevalent in almost every niche of computing.

== References ==
*Mernik, M., Heering, J., and Sloane, A. M. 2005. When and how to develop domain-specific languages. ACM Comput. Surv. 37, 4 (Dec. 2005), 316-344. DOI= http://doi.acm.org/10.1145/1118890.1118892
*"Domain-specific Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/Domain-specific_language.
*"UnrealScript." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/UnrealScript.
*"InfoQ: What's a Ruby DSL and What Isn't?" ''InfoQ: Tracking Change and Innovation in the Enterprise Software Development Community.'' Web. 08 Sept. 2010. http://www.infoq.com/news/2007/06/dsl-or-not.
*"MF Bliki: DomainSpecificLanguage." ''Martin Fowler.'' Web. 08 Sept. 2010. http://www.martinfowler.com/bliki/DomainSpecificLanguage.html.
*"Extensible Application Markup Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/XAML.
*"Scalable Vector Graphics." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/SVG.

CSC/ECE 517 Fall 2010/ch2 S23 GP

2010-09-09T02:49:41Z

Gpascar:

== Introduction to Object-Oriented Domain-Specific Languages ==
Domain-specific Languages, or DSLs, are programming languages or a subset of other languages that are used to solve domain specific problems. This is in opposition to general purpose programming languages that are used for all problems. The advantage of DSLs over general purpose languages are they are more targeted to a specific set of problems that may be higher level than is necessary for a general purpose language. Domain-specific languages are is use everyday, even though it may not be apparent. Here are examples of some domain-specific languages:
* CSS
* SQL
* Regular Expressions
* UnrealScript

General purpose languages contain more functionality than DSLs and generally provide specific system level access. Of course this may be a misnomer since a DSL may be developed specifically to handle system level APIs, like file systems. Examples of general purpose languages include:
* Java
* C++
* C#

Object-oriented Domain-specific Languages (OODSLs) differ from traditional DSLs in the same way that traditional languages differ from their object-oriented counterparts. An OOP uses "objects", which are data structures that contain both data members and methods. Therefore, OODSLs are simply DSLs that exmploy and object-oriented paradigm. Examples of OODSLs are:
* Scalable Vector Graphics (SVG)
* Extensible Application Markup Language (XAML)
* Kiddo
* Spring Configuration

== Internal vs. External ==
Among OODSLs there is a distinction between internal OODSLs and external OODSLs. Internal or embedded OODSLs give a "host" language domain-specific extensions or elements. For example, an internal OODSL may extend a general purpose language to allow for easier implementation of generating graphics through the use of specific APIs. An example of an embedded OODSL is Javascript hosted within an HTML document.

However, there is a fuzzy line between embedded OODSLs and 3rd party libraries. For example, the drawing methods of a Graphics object within Java may be considered an embedded OODSL or just a series of library APIS that are used in a contractual way.

External OODSLs are languages that are not hosted within another language, but are compiled or interpreted in a standalone manner. These OODSLs usually have a complete toolset and development environment behind them. It is up to the language implementor, but external OODSLs are generally interpreted instead of compiled. However, a OODSL does not necessarily need to be compiled into executable code. A OODSL may be a representation of something else. The CSound OODSL compiles a an Orchestra and Score markup files into audio. Another example is compiling or converting SVG into a rasterized image, such as Portable Networg Graphics (PNG).

== Practical Example: Java Swing and SVG ==
One way to illustrate the benefits of OODSLs is to compare a OODSL and a general purpose language performing the same task. The following practical example illustrates how a language like Java and an OODSL perform painting tasks. Both examples will draw a square button with the word ''Button'' in the center. The Java code is taken from a common [http://en.wikipedia.org/wiki/Java_Swing Swing] construct where a JButton overrides it's paintComponent method to draw something more custom than the Swing default look and feel. The Java Graphics API is used to perform both vector and raster drawing operations within a Java application. These operations could be used for either drawing user interfaces or directly onto in-memory images for later display. Here is an example of drawing a square button using a Java Graphics object.

<pre>
@Override
protected void paintComponent(Graphics g) {
// Save the current context's color
Color savedColor = g.getColor();

// Fill the shape
g.setColor(Color.gray);
g.fillRect(0, 0, getWidth(), getHeight());

// Draw the text
g.setColor(Bolor.black);
g.drawString("Button", 2, getHeight()-3);

// Draw the border
g.setColor(Color.black);
g.drawRect(0, 0, getWidth()-1, getHeight()-1);

// Restore the context's color
g.setColor(savedColor);
}
</pre>

This is quite procedural despite it being a methodology within an object-oriented language. Using a general purpose language like Java to perform something as domain-specific as graphics generation can lead to a lot of redundant overhead that is taken care of in a specialized language. This example illustrated the saving and restoring of the Graphic object's ''Color'' attribute, but could have required the saving and subsequent restoration of multiple properties, such as the current ''Transform'', ''Stroke'' or ''Font''. An OODSL would provide a more robust and flexible set of drawing and graphics APIs that would ideally perform the redundant tasks like saving and restoring the graphics state attributes, as is the case with SVG. Here is the same example written in using this OODSL.

<pre>
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="10%" height="10%" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%"
style="fill:rgb(128,128,128);stroke-width:1;stroke:rgb(0,0,0)" />
<text x="35%" y="50%">Button</text>
</svg>
</pre>

This code is more declarative, object-oriented and much less procedural. Instead of using a method to draw a rectangle the rectangle itself is an object with many data members used to define how the rectangle is rendered. Ironically, the style attribute of the rectangle is a subset of CSS, another OODSL. Since SVG is a language specific to the vector and imagery domain it provides capabilities (like opacity and gradients) that may be difficult to perform in general purpose languages without specialized libraries or an internal OODSL.

The SVG declaration could be "compiled" into an image format (such as JPG) as opposed to the Java code, which can only paint on the Graphics context passed into it. The point is, the SVG implementation is more versatile within the image domain in performing the same or similar methods as a general purpose language like Java.

== When should OODSLs be used? ==
In order to determine if a OODSL should be used or created you must first examine the advantages of OODSLs. If the problem domain is a well-known domain that already has an OODSL defined for it then it may be useful to use this OODSL, after all it was created for a reason. If the selected OODSL does not fully support the operations needed for the problem domain then maybe a different OODSL is needed or the OODSL needs to be extended.

If, however, there is no existing OODSL defined then creating a new OODSL may be the answer. This usually happens when there is a well-defined or at least well-understood domain where certain operations are performed over and over again. For example, a good candidate for an OODSL is robotics. Consider a robotic arm in a factory that needs to perform repetetive tasks such as picking up an object from one conveyor belt and moving it to another. If there is a OODSL that defines the movements of the arm then new behaviors could be easily added to the armature and existing actions can be easily changed. These changes in behavior may even be performed by a technician or subject matter expert (SME) instead of a developer.

== Conclusion ==
Object-oriented Domain-specific Languages provide a level of abstraction to a given domain. This abstraction may result in enhanced capabilities (such as rapid prototyping) or a greater control or understanding of that domain. It may also enable non-developers, like SMEs, to write "code" that utilizes the OODSL to affect a system or generate some sort of output. OODSLs are classified as either internal or external where internal is an OODSL that "lives" within a host language and external is a standalone language in its own right. General purpose languages are good for just that, general purpose development. OODSLs are very focused and are prevalent in almost every niche of computing.

== References ==
*Mernik, M., Heering, J., and Sloane, A. M. 2005. When and how to develop domain-specific languages. ACM Comput. Surv. 37, 4 (Dec. 2005), 316-344. DOI= http://doi.acm.org/10.1145/1118890.1118892
*"Domain-specific Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/Domain-specific_language.
*"UnrealScript." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/UnrealScript.
*"InfoQ: What's a Ruby DSL and What Isn't?" ''InfoQ: Tracking Change and Innovation in the Enterprise Software Development Community.'' Web. 08 Sept. 2010. http://www.infoq.com/news/2007/06/dsl-or-not.
*"MF Bliki: DomainSpecificLanguage." ''Martin Fowler.'' Web. 08 Sept. 2010. http://www.martinfowler.com/bliki/DomainSpecificLanguage.html.
*"Extensible Application Markup Language." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/XAML.
*"Scalable Vector Graphics." ''Wikipedia, the Free Encyclopedia.'' Web. 08 Sept. 2010. http://en.wikipedia.org/wiki/SVG.

CSC/ECE 517 Fall 2010/ch2 S23 GP

2010-09-08T23:16:01Z

Gpascar:

== Introduction to Object-Oriented Domain-Specific Languages ==
Domain-specific Languages, or DSLs, are programming languages or a subset of other languages that are used to solve domain specific problems. This is in opposition to general purpose programming languages that are used for all problems. The advantage of DSLs over general purpose languages are they are more targeted to a specific set of problems that may be higher level than is necessary for a general purpose language. Domain-specific languages are is use everyday, even though it may not be apparent. Here are examples of some domain-specific languages:
* CSS
* SQL
* Regular Expressions
* UnrealScript

General purpose languages contain more functionality than DSLs and generally provide specific system level access. Of course this may be a misnomer since a DSL may be developed specifically to handle system level APIs, like file systems. Examples of general purpose languages include:
* Java
* C++
* C#

Object-oriented Domain-specific Languages (OODSLs) differ from traditional DSLs in the same way that traditional languages differ from their object-oriented counterparts. An OOP uses "objects", which are data structures that contain both data members and methods. Therefore, OODSLs are simply DSLs that exmploy and object-oriented paradigm. Examples of OODSLs are:
* Scalable Vector Graphics (SVG)
* Extensible Application Markup Language (XAML)
* Kiddo
* Spring Configuration

== Internal vs. External ==
Among OODSLs there is a distinction between internal OODSLs and external OODSLs. Internal or embedded OODSLs give a "host" language domain-specific extensions or elements. For example, an internal OODSL may extend a general purpose language to allow for easier implementation of generating graphics through the use of specific APIs. An example of an embedded OODSL is Javascript hosted within an HTML document.

However, there is a fuzzy line between embedded OODSLs and 3rd party libraries. For example, the drawing methods of a Graphics object within Java may be considered an embedded OODSL or just a series of library APIS that are used in a contractual way.

External OODSLs are languages that are not hosted within another language, but are compiled or interpreted in a standalone manner. These OODSLs usually have a complete toolset and development environment behind them. It is up to the language implementor, but external OODSLs are generally interpreted instead of compiled. However, a OODSL does not necessarily need to be compiled into executable code. A OODSL may be a representation of something else. The CSound OODSL compiles a an Orchestra and Score markup files into audio. Another example is compiling or converting SVG into a rasterized image, such as Portable Networg Graphics (PNG).

== Practical Example: Java Swing and SVG ==
One way to illustrate the benefits of OODSLs is to compare a OODSL and a general purpose language performing the same task. The following practical example illustrates how a language like Java and an OODSL perform painting tasks. Both examples will draw a square button with the word ''Button'' in the center. The Java code is taken from a common [http://en.wikipedia.org/wiki/Java_Swing Swing] construct where a JButton overrides it's paintComponent method to draw something more custom than the Swing default look and feel. The Java Graphics API is used to perform both vector and raster drawing operations within a Java application. These operations could be used for either drawing user interfaces or directly onto in-memory images for later display. Here is an example of drawing a square button using a Java Graphics object.

<pre>
@Override
protected void paintComponent(Graphics g) {
// Save the current context's color
Color savedColor = g.getColor();

// Fill the shape
g.setColor(Color.gray);
g.fillRect(0, 0, getWidth(), getHeight());

// Draw the text
g.setColor(Bolor.black);
g.drawString("Button", 2, getHeight()-3);

// Draw the border
g.setColor(Color.black);
g.drawRect(0, 0, getWidth()-1, getHeight()-1);

// Restore the context's color
g.setColor(savedColor);
}
</pre>

This is quite procedural despite it being a methodology within an object-oriented language. Using a general purpose language like Java to perform something as domain-specific as graphics generation can lead to a lot of redundant overhead that is taken care of in a specialized language. This example illustrated the saving and restoring of the Graphic object's ''Color'' attribute, but could have required the saving and subsequent restoration of multiple properties, such as the current ''Transform'', ''Stroke'' or ''Font''. An OODSL would provide a more robust and flexible set of drawing and graphics APIs that would ideally perform the redundant tasks like saving and restoring the graphics state attributes, as is the case with SVG. Here is the same example written in using this OODSL.

<pre>
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="10%" height="10%" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%"
style="fill:rgb(128,128,128);stroke-width:1;stroke:rgb(0,0,0)" />
<text x="35%" y="50%">Button</text>
</svg>
</pre>

This code is more declarative, object-oriented and much less procedural. Instead of using a method to draw a rectangle the rectangle itself is an object with many data members used to define how the rectangle is rendered. Ironically, the style attribute of the rectangle is a subset of CSS, another OODSL. Since SVG is a language specific to the vector and imagery domain it provides capabilities (like opacity and gradients) that may be difficult to perform in general purpose languages without specialized libraries or an internal OODSL.

The SVG declaration could be "compiled" into an image format (such as JPG) as opposed to the Java code, which can only paint on the Graphics context passed into it. The point is, the SVG implementation is more versatile within the image domain in performing the same or similar methods as a general purpose language like Java.

== When should OODSLs be used? ==
In order to determine if a OODSL should be used or created you must first examine the advantages of OODSLs. If the problem domain is a well-known domain that already has an OODSL defined for it then it may be useful to use this OODSL, after all it was created for a reason. If the selected OODSL does not fully support the operations needed for the problem domain then maybe a different OODSL is needed or the OODSL needs to be extended.

If, however, there is no existing OODSL defined then creating a new OODSL may be the answer. This usually happens when there is a well-defined or at least well-understood domain where certain operations are performed over and over again. For example, a good candidate for an OODSL is robotics. Consider a robotic arm in a factory that needs to perform repetetive tasks such as picking up an object from one conveyor belt and moving it to another. If there is a OODSL that defines the movements of the arm then new behaviors could be easily added to the armature and existing actions can be easily changed. These changes in behavior may even be performed by a technician or subject matter expert (SME) instead of a developer.

== Conclusion ==
Object-oriented Domain-specific Languages provide a level of abstraction to a given domain. This abstraction may result in enhanced capabilities (such as rapid prototyping) or a greater control or understanding of that domain. It may also enable non-developers, like SMEs, to write "code" that utilizes the OODSL to affect a system or generate some sort of output. OODSLs are classified as either internal or external where internal is an OODSL that "lives" within a host language and external is a standalone language in its own right. General purpose languages are good for just that, general purpose development. OODSLs are very focused and are prevalent in almost every niche of computing.

== References ==
*[http://portal.acm.org/citation.cfm?id=1118890.1118892 ACM - When and how to develop domain-specific languages]
*[http://en.wikipedia.org/wiki/Domain-specific_language Wikipedia - Domain-specific Language]
*[http://en.wikipedia.org/wiki/UnrealScript Wikipedia - UnrealScript]
*[http://www.infoq.com/news/2007/06/dsl-or-not What's a Ruby DSL and what isn't?]
*[http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Martin Fowler - Domain-specific Language]
*[http://en.wikipedia.org/wiki/XAML Wikipedia - Extensible Application Markup Language]
*[http://en.wikipedia.org/wiki/SVG Wikipedia - Scalable Vector Graphics]

CSC/ECE 517 Fall 2010/ch2 S23 GP

2010-09-08T21:41:38Z

Gpascar:

== Introduction to Object-Oriented Domain-Specific Languages ==
Domain-specific Languages, or DSLs, are programming languages or a subset of other languages that are used to solve domain specific problems. This is in opposition to general purpose programming languages that are used for all problems. The advantage of DSLs over general purpose languages are they are more targeted to a specific set of problems that may be higher level than is necessary for a general purpose language. Domain-specific languages are is use everyday, even though it may not be apparent. Here are examples of some domain-specific languages:
* CSS
* SQL
* Regular Expressions
* UnrealScript

General purpose languages contain more functionality than DSLs and generally provide specific system level access. Of course this may be a misnomer since a DSL may be developed specifically to handle system level APIs, like file systems. Examples of general purpose languages include:
* Java
* C++
* C#

Object-oriented Domain-specific Languages (OODSLs) differ from traditional DSLs in the same way that traditional languages differ from their object-oriented counterparts. An OOP uses "objects", which are data structures that contain both data members and methods. Therefore, OODSLs are simply DSLs that exmploy and object-oriented paradigm. Examples of OODSLs are:
* Scalable Vector Graphics (SVG)
* Extensible Application Markup Language (XAML)
* Kiddo
* Spring Configuration

== Internal vs. External ==
Among OODSLs there is a distinction between internal OODSLs and external OODSLs. Internal or embedded OODSLs give a "host" language domain-specific extensions or elements. For example, an internal OODSL may extend a general purpose language to allow for easier implementation of generating graphics through the use of specific APIs. An example of an embedded OODSL is Javascript hosted within an HTML document.

However, there is a fuzzy line between embedded OODSLs and 3rd party libraries. For example, the drawing methods of a Graphics object within Java may be considered an embedded OODSL or just a series of library APIS that are used in a contractual way.

External OODSLs are languages that are not hosted within another language, but are compiled or interpreted in a standalone manner. These OODSLs usually have a complete toolset and development environment behind them. It is up to the language implementor, but external OODSLs are generally interpreted instead of compiled. However, a OODSL does not necessarily need to be compiled into executable code. A OODSL may be a representation of something else. The CSound OODSL compiles a an Orchestra and Score markup files into audio. Another example is compiling or converting SVG into a rasterized image, such as Portable Networg Graphics (PNG).

== Practical Example: Java2D and SVG ==
One way to illustrate the benefits of OODSLs is to compare a OODSL and a general purpose language performing the same task. The following practical example illustrates how a language like Java and an OODSL perform painting tasks. Both examples will draw a square button with the word ''Button'' in the center. The Java code is taken from a common [http://en.wikipedia.org/wiki/Java_Swing Swing] construct where a JButton overrides it's paintComponent method to draw something more custom than the Swing default look and feel. The Java Graphics API is used to perform both vector and raster drawing operations within a Java application. These operations could be used for either drawing user interfaces or directly onto in-memory images for later display. Here is an example of drawing a square button using a Java Graphics object.

<pre>
@Override
protected void paintComponent(Graphics g) {
// Save the current context's color
Color savedColor = g.getColor();

// Fill the shape
g.setColor(Color.gray);
g.fillRect(0, 0, getWidth(), getHeight());

// Draw the text
g.setColor(Bolor.black);
g.drawString("Button", 2, getHeight()-3);

// Draw the border
g.setColor(Color.black);
g.drawRect(0, 0, getWidth()-1, getHeight()-1);

// Restore the context's color
g.setColor(savedColor);
}
</pre>

This is quite procedural and while minimally illustrated can lead to a lot of housekeeping. In the previous example the Graphic object's color needed to be saved and then restored. An OODSL would provide a more robust and flexible set of drawing and graphics APIs. Such is the case with SVG, here is the same example written in using this OODSL.

<pre>
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="10%" height="10%" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%"
style="fill:rgb(128,128,128);stroke-width:1;stroke:rgb(0,0,0)" />
<text x="35%" y="50%">Button</text>
</svg>
</pre>

This code is more declarative, supports more options (like opacity and gradients) and is quite domain focused. Also, it is more object-oriented than the previous Java code since each shape is an object with attributes as opposed to Java's procedural drawing methodology. The SVG declaration could be "compiled" into an image format (such as JPG) as opposed to the Java code, which can only paint on the Graphics context passed into it. The point is the SVG implementation is more versatile within the image domain in performing the same or similar methods as a general purpose language like Java.

== When should OODSLs be used? ==
In order to determine if a OODSL should be used or created you must first examine the advantages of OODSLs. If the problem domain is a well-known domain that already has an OODSL defined for it then it may be useful to use this OODSL, after all it was created for a reason. If the selected OODSL does not fully support the operations needed for the problem domain then maybe a different OODSL is needed or the OODSL needs to be extended.

If, however, there is no existing OODSL defined then creating a new OODSL may be the answer. This usually happens when there is a well-defined or at least well-understood domain where certain operations are performed over and over again. For example, a good candidate for an OODSL is robotics. Consider a robotic arm in a factory that needs to perform repetetive tasks such as picking up an object from one conveyor belt and moving it to another. If there is a OODSL that defines the movements of the arm then new behaviors could be easily added to the armature and existing actions can be easily changed. These changes in behavior may even be performed by a technician or subject matter expert (SME) instead of a developer.

== Conclusion ==
Object-oriented Domain-specific Languages provide a level of abstraction to a given domain. This abstraction may result in enhanced capabilities (such as rapid prototyping) or a greater control or understanding of that domain. It may also enable non-developers, like SMEs, to write "code" that utilizes the OODSL to affect a system or generate some sort of output. OODSLs are classified as either internal or external where internal is an OODSL that "lives" within a host language and external is a standalone language in its own right. General purpose languages are good for just that, general purpose development. OODSLs are very focused and are prevalent in almost every niche of computing.

== References ==
*[http://portal.acm.org/citation.cfm?id=1118890.1118892 ACM - When and how to develop domain-specific languages]
*[http://en.wikipedia.org/wiki/Domain-specific_language Wikipedia - Domain-specific Language]
*[http://en.wikipedia.org/wiki/UnrealScript Wikipedia - UnrealScript]
*[http://www.infoq.com/news/2007/06/dsl-or-not What's a Ruby DSL and what isn't?]
*[http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Martin Fowler - Domain-specific Language]
*[http://en.wikipedia.org/wiki/XAML Wikipedia - Extensible Application Markup Language]
*[http://en.wikipedia.org/wiki/SVG Wikipedia - Scalable Vector Graphics]

CSC/ECE 517 Fall 2010/ch2 S23 GP

2010-09-08T04:48:07Z

Gpascar:

== Introduction to Object-Oriented Domain-Specific Languages ==
Domain-specific Languages, or DSLs, are programming languages or a subset of other languages that are used to solve domain specific problems. This is in opposition to general purpose programming languages that are used for all problems. The advantage of DSLs over general purpose languages are they are more targeted to a specific set of problems that may be higher level than is necessary for a general purpose language. Domain-specific languages are is use everyday, even though it may not be apparent. Here are examples of some domain-specific languages:
* CSS
* SQL
* Regular Expressions
* UnrealScript

General purpose languages contain more functionality than DSLs and generally provide specific system level access. Of course this may be a misnomer since a DSL may be developed specifically to handle system level APIs, like file systems. Examples of general purpose languages include:
* Java
* C++
* C#

Object-oriented Domain-specific Languages (OODSLs) differ from traditional DSLs in the same way that traditional languages differ from their object-oriented counterparts. An OOP uses "objects", which are data structures that contain both data members and methods. Therefore, OODSLs are simply DSLs that exmploy and object-oriented paradigm. Examples of OODSLs are:
* Scalable Vector Graphics (SVG)
* Extensible Application Markup Language (XAML)
* Kiddo
* Spring Configuration

== Internal vs. External ==
Among OODSLs there is a distinction between internal OODSLs and external OODSLs. Internal or embedded OODSLs give a "host" language domain-specific extensions or elements. For example, an internal OODSL may extend a general purpose language to allow for easier implementation of generating graphics through the use of specific APIs. An example of an embedded OODSL is Javascript hosted within an HTML document.

However, there is a fuzzy line between embedded OODSLs and 3rd party libraries. For example, the drawing methods of a Graphics object within Java may be considered an embedded OODSL or just a series of library APIS that are used in a contractual way.

External OODSLs are languages that are not hosted within another language, but are compiled or interpreted in a standalone manner. These OODSLs usually have a complete toolset and development environment behind them. It is up to the language implementor, but external OODSLs are generally interpreted instead of compiled. However, a OODSL does not necessarily need to be compiled into executable code. A OODSL may be a representation of something else. The CSound OODSL compiles a an Orchestra and Score markup files into audio. Another example is compiling or converting SVG into a rasterized image, such as Portable Networg Graphics (PNG).

== Practical Example: Java2D and SVG ==
The Java2D API is used to perform both vector and raster drawing operations within a Java application. These operations could be used for either drawing user interfaces or directly onto in-memory images for later display. Here is an example of drawing a square button using the Java2D API.

<pre>
@Override
protected void paintComponent(Graphics g) {
// Save the current context's color
Color savedColor = g.getColor();

// Fill the shape
g.setColor(Color.gray);
g.fillRect(0, 0, getWidth(), getHeight());

// Draw the text
g.setColor(Bolor.black);
g.drawString("Button", 2, getHeight()-3);

// Draw the border
g.setColor(Color.black);
g.drawRect(0, 0, getWidth()-1, getHeight()-1);

// Restore the context's color
g.setColor(savedColor);
}
</pre>

This is quite procedural and while minimally illustrated can lead to a lot of housekeeping. In the previous example the Graphic object's color needed to be saved and then restored. An OODSL would provide a more robust and flexible set of drawing and graphics APIs. Such is the case with SVG, here is the same example written in SVG.

<pre>
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

<svg width="10%" height="10%" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect width="100%" height="100%"
style="fill:rgb(128,128,128);stroke-width:1;stroke:rgb(0,0,0)" />
<text x="35%" y="50%">Button</text>
</svg>
</pre>

This code is more declarative, supports more options (like opacity and gradients) and is quite domain focused. Also, it is more object-oriented than the previous Java code since each shape is an object with attributes as opposed to Java's procedural drawing methodology.

== When should OODSLs be used? ==
In order to determine if a OODSL should be used or created you must first examine the advantages of OODSLs. If the problem domain is a well-known domain that already has an OODSL defined for it then it may be useful to use this OODSL, after all it was created for a reason. If the selected OODSL does not fully support the operations needed for the problem domain then maybe a different OODSL is needed or the OODSL needs to be extended.

If, however, there is no existing OODSL defined then creating a new OODSL may be the answer. This usually happens when there is a well-defined or at least well-understood domain where certain operations are performed over and over again. For example, a good candidate for an OODSL is robotics. Consider a robotic arm in a factory that needs to perform repetetive tasks such as picking up an object from one conveyor belt and moving it to another. If there is a OODSL that defines the movements of the arm then new behaviors could be easily added to the armature and existing actions can be easily changed. These changes in behavior may even be performed by a technician or subject matter expert (SME) instead of a developer.

== Conclusion ==
Object-oriented Domain-specific Languages provide a level of abstraction to a given domain. This abstraction may result in enhanced capabilities (such as rapid prototyping) or a greater control or understanding of that domain. It may also enable non-developers, like SMEs, to write "code" that utilizes the OODSL to affect a system or generate some sort of output. OODSLs are classified as either internal or external where internal is an OODSL that "lives" within a host language and external is a standalone language in its own right. General purpose languages are good for just that, general purpose development. OODSLs are very focused and are prevalent in almost every niche of computing.

== References ==
*[http://portal.acm.org/citation.cfm?id=1118890.1118892 ACM - When and how to develop domain-specific languages]
*[http://en.wikipedia.org/wiki/Domain-specific_language Wikipedia - Domain-specific Language]
*[http://en.wikipedia.org/wiki/UnrealScript Wikipedia - UnrealScript]
*[http://www.infoq.com/news/2007/06/dsl-or-not What's a Ruby DSL and what isn't?]
*[http://www.martinfowler.com/bliki/DomainSpecificLanguage.html Martin Fowler - Domain-specific Language]
*[http://en.wikipedia.org/wiki/XAML Wikipedia - Extensible Application Markup Language]
*[http://en.wikipedia.org/wiki/SVG Wikipedia - Scalable Vector Graphics]

CSC/ECE 517 Fall 2010/ch2 S20 st

2010-09-08T04:31:44Z

Gpascar:

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE_517_Fall_2010/ch1_1a_br]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S23 GP]]