Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T04:31:58Z

Nbshah2: /* Waterfall */

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile Methodology==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:agile.gif|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

===Comparison with Agile===

*Customer requirements: For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure: The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction: For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost): As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:spiral.png|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design: The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:iterative.gif|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: In iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Insufficient customer involvement can result in confused and incomplete requirement document and bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequent sync calls and sharing wiki pages.
*Even though some projects are characterized by slow Rate of change making them fall into other software development category, they can be good candidates for agile if other agile development methods can be applied to the project effectively

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==

[1] http://www.buzzle.com/articles/waterfall-model-vs-agile.html

[2] M. A. Awad, "A Comparison between Agile and Traditional Software Development Methodologies"

[3] Boehm B, "A Spiral Model of Software Development and Enhancement"ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986

[4] Rashina H, Philippe K, James N and Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:41:35Z

Nbshah2: /* References */

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements: For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure: The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction: For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost): As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design: The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: In iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==

[1] http://www.buzzle.com/articles/waterfall-model-vs-agile.html

[2] M. A. Awad, "A Comparison between Agile and Traditional Software Development Methodologies"

[3] Boehm B, "A Spiral Model of Software Development and Enhancement"ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986

[4] Rashina H, Philippe K, James N and Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:41:20Z

Nbshah2: /* References */

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements: For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure: The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction: For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost): As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design: The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: In iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==

[1] *http://www.buzzle.com/articles/waterfall-model-vs-agile.html

[2] M. A. Awad, "A Comparison between Agile and Traditional Software Development Methodologies"

[3] Boehm B, "A Spiral Model of Software Development and Enhancement"ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986

[4] Rashina H, Philippe K, James N and Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:34:53Z

Nbshah2: /* Comparison with Agile */

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements: For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure: The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction: For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost): As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design: The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: In iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==
*http://www.buzzle.com/articles/waterfall-model-vs-agile.html
*M. A. Awad, A Comparison between Agile and Traditional Software Development Methodologies
*Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
*Rashina H, Philippe K, James N, Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:33:27Z

Nbshah2: /* Comparison with Agile */

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements: For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure: The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction: For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost): As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design: The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: in iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==
*http://www.buzzle.com/articles/waterfall-model-vs-agile.html
*M. A. Awad, A Comparison between Agile and Traditional Software Development Methodologies
*Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
*Rashina H, Philippe K, James N, Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:31:26Z

Nbshah2: /* Comparison with Agile */

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements – For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure - The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction – For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost) – As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design: The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: in iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==
*http://www.buzzle.com/articles/waterfall-model-vs-agile.html
*M. A. Awad, A Comparison between Agile and Traditional Software Development Methodologies
*Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
*Rashina H, Philippe K, James N, Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:27:15Z

Nbshah2: /* Software development methodologies */

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements – For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure - The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction – For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost) – As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design:The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: in iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==
*http://www.buzzle.com/articles/waterfall-model-vs-agile.html
*M. A. Awad, A Comparison between Agile and Traditional Software Development Methodologies
*Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
*Rashina H, Philippe K, James N, Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:26:11Z

Nbshah2:

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Different types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology Agile] means – moving quickly and lightly. Similarly, the goal of [http://en.wikipedia.org/wiki/Agile_software_development Agile methodology] is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*[http://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process (AUP)]- simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*[http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method Dynamic Systems Development Method (DSDM)]- iterative and incremental approach that emphasizes continuous user involvement
*[http://en.wikipedia.org/wiki/Essential_Unified_Process Essential Unified Process (EssUP) ]- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*[http://en.wikipedia.org/wiki/Extreme_Programming Extreme Programming (XP)]- intended to improve software quality and responsiveness to changing customer requirements
*[http://en.wikipedia.org/wiki/Feature_Driven_Development Feature Driven Development (FDD)]- model-driven short-iteration process
*[http://en.wikipedia.org/wiki/Open_Unified_Process Open Unified Process (OpenUP)]- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*[http://en.wikipedia.org/wiki/Scrum_(development)Scrum]- a process skeleton that contains sets of practices and predefined roles.
*[http://en.wikipedia.org/wiki/Velocity_tracking Velocity tracking]– tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements – For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure - The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction – For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost) – As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design:The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: in iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==
*http://www.buzzle.com/articles/waterfall-model-vs-agile.html
*M. A. Awad, A Comparison between Agile and Traditional Software Development Methodologies
*Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
*Rashina H, Philippe K, James N, Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:21:31Z

Nbshah2:

'''Agile vs. other software-development methods'''
==Software development methodologies==

[http://en.wikipedia.org/wiki/Software_development_methodology Software development methodology] is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Different types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
Agile http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=define:+Agile means – moving quickly and lightly. Similarly, the goal of Agile methodology http://en.wikipedia.org/wiki/Agile_software_development is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*Agile Unified Process (AUP) http://en.wikipedia.org/wiki/Agile_Unified_Process - simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*Dynamic Systems Development Method (DSDM) http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method- iterative and incremental approach that emphasizes continuous user involvement
*Essential Unified Process (EssUP) http://en.wikipedia.org/wiki/Essential_Unified_Process- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*Extreme Programming (XP) http://en.wikipedia.org/wiki/Extreme_Programming- intended to improve software quality and responsiveness to changing customer requirements
*Feature Driven Development (FDD) http://en.wikipedia.org/wiki/Feature_Driven_Development- model-driven short-iteration process
*Open Unified Process (OpenUP) http://en.wikipedia.org/wiki/Open_Unified_Process- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*Scrum http://en.wikipedia.org/wiki/Scrum_(development)- a process skeleton that contains sets of practices and predefined roles.
*Velocity tracking http://en.wikipedia.org/wiki/Velocity_tracking – tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:Crccard2.jpg|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements – For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure - The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction – For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost) – As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design:The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: in iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==
*http://www.buzzle.com/articles/waterfall-model-vs-agile.html
*M. A. Awad, A Comparison between Agile and Traditional Software Development Methodologies
*Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
*Rashina H, Philippe K, James N, Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch6 6d NM

2010-11-18T03:16:48Z

Nbshah2:

==Software development methodologies==

Software development methodology http://en.wikipedia.org/wiki/Software_development_methodology is a methodical approach or a framework to the software development process, in order to develop software with high quality and less defects. It helps the development team to plan and structure the process in advance. A wide range of such methodologies exist in the Software engineering field with their own characteristics.

===Different types of Software development methodologies===
There are wide variety of software development approaches used in the industry. Few of them are,
*Waterfall Approach : linear framework type.
*Prototyping Approach : iterative framework type
*Incremental Approach: combination of linear and iterative framework type
*Spiral Approach : combination of linear and iterative framework type
*Rapid Application Development (RAD) Approach: Iterative Framework Type
*Agile Methodologies

==Agile introduction==
Agile http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=define:+Agile means – moving quickly and lightly. Similarly, the goal of Agile methodology http://en.wikipedia.org/wiki/Agile_software_development is to offer lighter weight solution to the rapidly paced software development processes. It refers to the group of software development methodologies that are based on iterative software development methods. In the Iterative approach the requirements and solutions evolve through the collaboration between self-organizing cross-functional teams.
Agile methods break the entire software development into small increments. Each of these iteration involves a team all the essential parts of the software development cycle including planning, requirements analysis, design, coding, and testing. Thus, it reduces the risk involved with the software development and makes it easy to adapt to the new changes. Completion of multiple iterations eventually results into final product. Agile methodology follows principles such as Customer satisfaction, face-to-face communication, simplicity, Self-organizing teams, etc..
Well-known agile methods include
*Agile Unified Process (AUP) http://en.wikipedia.org/wiki/Agile_Unified_Process - simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP
*Dynamic Systems Development Method (DSDM) http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method- iterative and incremental approach that emphasizes continuous user involvement
*Essential Unified Process (EssUP) http://en.wikipedia.org/wiki/Essential_Unified_Process- identifies practices, such as use cases, iterative development, architecture driven development, team practices and process practices, which are borrowed from RUP, CMMI and agile development
*Extreme Programming (XP) http://en.wikipedia.org/wiki/Extreme_Programming- intended to improve software quality and responsiveness to changing customer requirements
*Feature Driven Development (FDD) http://en.wikipedia.org/wiki/Feature_Driven_Development- model-driven short-iteration process
*Open Unified Process (OpenUP) http://en.wikipedia.org/wiki/Open_Unified_Process- a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the RUP / Unified Process
*Scrum http://en.wikipedia.org/wiki/Scrum_(development)- a process skeleton that contains sets of practices and predefined roles.
*Velocity tracking http://en.wikipedia.org/wiki/Velocity_tracking – tracking a measure of productivity sometimes used in agile software development

[[Image:Crccard2.jpg|frame|center|Agile Software development]]

==Agile vs waterfall==
===Waterfall===
Waterfall model is the traditional sequential process of software development. Like in a waterfall, the water progressively falls from the higher attitude to the lower, in a similar way, the software production cycle progresses sequentially. The waterfall model phases of software development are as follows: requirement specification, conception, analysis, design, coding, testing & debugging, installation and finally maintenance.

[[Image:Crccard2.jpg|frame|center|Waterfall model]]

===Comparison with Agile===

*Customer requirements – For the team using Agile method, They are totally unclear and evolves as the work progresses. But for the Waterfall method it is known completely before moving to the next step of the development. They are more stable compared with the requirements of the Agile. The requirement gathering phase consumes considerable amount of time of the entire software development life cycle. No last minute changes are possible in Waterfall whereas they can be easily incorporated using the Agile methodology.
*Team Structure - The team structure in Agile is cross functional, closely knit and self-organizing. The team work on the entire iteration which includes all the phases of software development. Whereas in Waterfall, each team is dedicated for each phase of the software development cycle.
*Customer interaction – For Agile, the customer interaction is only in the earlier stage of the cycle. Whereas in Agile, there needs to be continuous interaction of the customer with the development team
*Contract (cost) – As the requirements are unclear and not stable, It is very difficult to decide on the cost of the developing the software in the case of Agile methodology. However, in the case of Waterfall, the cost can be easily manipulated using the requirements defined in the first stage.

==Agile Vs Spiral==
===Spiral model===
Spiral model combines good features of top down and bottom up approach of software development. It combines the features of waterfall as well as prototype modeling. The model is both incremental and iterative. The spiral method is planned methodically, with tasks and deliverables identified for each step in the spiral. A prototype is first created based on requirements and scaled down to represent the final product. It is then analyzed for improvements and a better and efficient prototype is built. This process is continued till the best prototype is created.

[[Image:Crccard2.jpg|frame|center|Spiral model]]

===Comparison with Agile===

*Requirement: in spiral methodology, the system requirement are described in detail and once the requirements are defined and considered final, work is started. However, in agile methodology requirements are not very clear in initial iterations. It becomes clear after few iterations of product development.
*Design:The basic difference is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
*Customer Involvement: Customer is involved in the requirement specification stage and in reviewing the prototypes. Constant customer involvement is not necessary. However, agile methodology involves heavy interaction with customers. Success depends on timely and adequate feedback from customer.
*Project size: The spiral model is intended for large and complicated projects. Agile model works best with small projects
*Cycles:Spiral model has limited cycles till the best prototype is decided upon while agile model has numerous cycles. Cycles in spiral model are prototype cycles as against getting what customer wants as final product in agile model.
*Risk: Spiral model has known risks while
*Cost: spiral models are usually expensive compared to Agile models
*Testing: Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

==Agile vs Iterative==
===Iterative Software development===
Iterative development starts with an initial planning followed by many iterations of requirement, analysis, design, testing and implementation steps and ends with deployment. After each iteration, analysis is done to make sure that the required functionality is implemented and additional functionalities that need to be implemented are identified. Such iterations make modification and implementation easy. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster.

[[Image:Crccard2.jpg|frame|center|Iterative Software development model]]

===Comparison with Agile===

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

*Time period: Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
*Process and People Orientation: A team doing iterative software development could value processes and tools over people and interactions while agile is people oriented interacting more with the customer.
*Documentation: Iterative model values comprehensive documentation over working software while agile model is characterized by low documentation and more thrust on working software.
*Contract: Iterative models follow a fixed contract with the customer. However, agile models allows customer to pay for first few iterations and then decide on the type of contract to be entered into.
*Customer role: in iterative model, customer’s involvement is focused on contract supervision while in agile model has dedicated, knowledgeable, collaborated, collocated onsite customers
*Team size: Iterative model has large team size while agile model has large team size.
*Developers: In iterative model developers are plan oriented while in agile model developers flexible and can work with changes in plan.

==Agility in context==
Agility in context is a new trend to make agile methodologies more relevant to a wide range of projects. This makes it stand out from other software development methodologies. Instead of applying all the steps by-the-book, the process is customized to accommodate changes. Few examples are as follows
*Ior ineffective customer involvement can result in confused and incomplete requirement document bring project to a standstill. To avoid this, methods such as story owner and customer proxy are used.
*The constraints in fixed bid contract make it difficult to make the project agile. Options like offering a customer to buy few iterations to see how the development is going and then sign the contract or swapping a feature or two makes pricing flexible.
*Communication with clients that cannot come on site and teams that are located in different geographical areas is improved using video conferencing, frequency sync calls and sharing wiki pages.
*Even though some projects are characterized by Slow Rate of Change making them fall into other software methodology development category, they can be good candidates for agile if other agile development methods can be applied to the project

==Limitations of agile methodology ==

*They are difficult when used with the large teams. (Team having members more than 20).
*Customer is considered as part of the development team throughout the whole development of the software. Change in the customer side representative may result into change in the requirements.
*It does not support traditional walkthroughs and code inspections during the life-cycle. Instead it emphasizes on pair programming and informal reviews as their quality control mechanism. This is not enough of the critical software.
*It relies on tacit knowledge embodied by the team, rather than writing the knowledge down as documentation. Thus, there is a risk that this may lead to architectural mistakes that cannot be easily detected by external reviewers due to the lack of documentation.
*It does not work best, when the requirements are predictable.
*Lack of documentation may result into failure in understanding the project in future by an outside expert.
*User interface are developed using the paper prototype based approach rather than model-driven design.

==Limitations of other software development methodologies==
*Lack of customer interaction results into last moment surprises.
*Incorporation of the changes during the software development cycle is very difficult task.
*High amount of prediction is required which result into higher risk involved.
*Documentation consumes lot of time in the software development cycle.
*More pre-planning is required compared to agile methods.
*Stringent team structure may result into conflicts.

==Conclusion==
Agile methods work well for projects characterized by small; co-located teams; interactive customers involved in decisions on requirements; frequently changing requirements (weeks or months); variable price contracts; and few legal or regulatory constraints on development processes where as heavyweight methods can handle complex large software team dispersed over multiple domains, functions, and geographical areas efficiently.
Heavyweight approaches have their need in large, long lived projects that have a special safety, reliability or security requirements. However, the steps in agile models can be modified and customized to suit the demands of a project. This agility in context offers many benefits and is the reason for adoption of agile methodologies widely in these areas too.

==References==
*http://www.buzzle.com/articles/waterfall-model-vs-agile.html
*M. A. Awad, A Comparison between Agile and Traditional Software Development Methodologies
*Boehm B, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes", "ACM", 11(4):14-24, August 1986
*Rashina H, Philippe K, James N, Stuart M, ”Agility in Context”, ACM OOOPSLA 2010

CSC/ECE 517 Fall 2010/ch1 S10 ms

2010-11-18T02:49:27Z

Nbshah2:

*[[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/ch2 S23 NR

2010-10-01T15:07:55Z

Nbshah2: /* Domain specific languages vs. General programming languages */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

[http://en.wikipedia.org/wiki/General-purpose_programming_language General Programming languages] are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

* It gives better end user experience.

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

===The Risks===

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

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

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

* The scope of DSL is not defined.

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

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

==DSL v/s Object Oriented Frameworks==

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

They can be compared on the basis following criterion:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T15:05:38Z

Nbshah2: /* DSL v/s Object Oriented Frameworks */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

* It gives better end user experience.

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

===The Risks===

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

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

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

* The scope of DSL is not defined.

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

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

==DSL v/s Object Oriented Frameworks==

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

They can be compared on the basis following criterion:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T15:04:33Z

Nbshah2: /* The Risks */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

* It gives better end user experience.

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

===The Risks===

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

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

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

* The scope of DSL is not defined.

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

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

==DSL v/s Object Oriented Frameworks==

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

They can be compared on the basis following criterion:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T15:03:58Z

Nbshah2: /* The Opportunities */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

* It gives better end user experience.

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

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T15:02:23Z

Nbshah2: /* The Risks */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:53:48Z

Nbshah2: /* References */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:53:26Z

Nbshah2: /* References */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:53:05Z

Nbshah2: x

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:41:23Z

Nbshah2: /* Open Issues or challenges related to DSLs */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

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

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:39:58Z

Nbshah2: /* Open Issues or challenges related to DSLs */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 2a mw

2010-10-01T14:37:34Z

Nbshah2: /* Ruby and ActiveRecord */

==Introduction==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_S24 previous article for which the link does not exist yet], we learn that [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is where the computer code interacts with other programs as data and performs many of these interactions at compile time rather than runtime. This built-in interaction allows the programmers to take advantage of these capabilities and focus their time on the rest of their program logic instead of the details of some of the lower level coding. In this article, we will take a closer look at one of the styles of metaprogramming referred to as language extensions for [http://en.wikipedia.org/wiki/Object-relational_mapping object-relational mapping] through examples and some comparisons of language extensions and tools.

==Object-Relational Mapping==
Object-Relational Mapping (ORM) is a methodology for managing data between object oriented systems and relational databases. The premise of the concept is to provide a universal method to access data in a database. This is beneficial for all programming languages that can use objects to store and retrieve data from the database. There are many languages that are using ORM as a technique to manage database data. In the rest of the wiki, we will discuss ORM and some of the more common languages in use today.

==Language Extensions==
Language extensions for ORM have often been traditionally classified as design patterns or software tools used to perform basic [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete create, read, update and delete (C.R.U.D.)] operations on relational databases, that is, until recent new approaches such as [http://en.wikipedia.org/wiki/ActiveRecord#Ruby ActiveRecord] have grown in popularity. ActiveRecord is not just a design pattern it is an increase of function to the active record pattern approach by adding [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance] and [http://en.wikipedia.org/wiki/Association_%28object-oriented_programming%29 associations]. Examining ActiveRecord and other language extensions will allow for comparisons of the ease of programming using these language extensions verses the conventional database oriented systems approach.

==Ruby and ActiveRecord==
All too often programmers are faced with the challenge of persisting objects from their program into a datastore. Custom code is created for this purpose that can be complex or difficult for others to understand as well as not seem natural. Applications that are designed to persist data have the need to know how the objects correspond to the information stored in these database tables. [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails], first released in 2005, is able to provide a uniform method to help resolve these complicated issues without sacrificing function or knowledge of these objects by using ActiveRecord (AR). AR is a persistence engine that comes as part of Ruby on Rails. It creates a 'persistable' domain model from business objects and database tables, where logic and data are presented as a unified package [http://en.wikipedia.org/wiki/ActiveRecord#Ruby 3]. AR is admired for its simplistic and elegant approach of removing these levels of complexity. It allows for a 'pluggable' solution to many different popular databases available today to include: MySQL, SQLite, SQL Server, PostgreSQL, and Oracle.

ActiveRecord uses a [http://en.wikipedia.org/wiki/Single_Table_Inheritance Single Table Inheritance] to allow for inheritance capabilities and provides a set of macros for association relationships between classes of objects, such as belongs_to, has_one, has_many, etc. AR is not only a component of the [http://en.wikipedia.org/wiki/Model-view-controller Model view-controller (MVC)] for Ruby on Rails but it is also a standalone ORM package for Ruby itself. Ruby, Ruby on Rails, and ActiveRecord continue to grow in popularity due to not only the curiosity of programmers but their ability to improve function and feature sets while maintaining the initial intent of the language, “trying to make Ruby natural, not simple” -- Yukihiro “matz” Matsumoto [http://www.ruby-lang.org/en/about/ 8]. Other languages have been able to learn from AR and have tried to add this capability for themselves. Let’s take a closer look at some other implementations that attempts to duplicate AR’s elegance.

==Other Examples of Language Extensions==
===ADO.NET Entity Framework===
[http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework ADO.NET Entity Framework], Microsoft's ORM, part of [http://en.wikipedia.org/wiki/.NET_Framework .NET] 4.0 was first developed in 2008. The Entity Framework tries to remove ORM mismatches that often plague conventional database oriented programs by using an Entity data model (EDM) and an Entity-Relationship data model to define the Relationships associated to each Entity. The EDM consists of a schema and a mapping specification. The schema defines the data types from the entities and the mapping provides the connections between the database scheme and the conceptual scheme. The Entity Framework has its own version of a query language called Entity SQL which continues to focus only on the conceptual entities and relationships as opposed to the actual database. It works with many popular databases available today to include: MySQL, SQLite, SQL Server, PostgreSQL, and Oracle.

===Django===
[http://en.wikipedia.org/wiki/Django_%28web_framework%29 Django], is an ORM included in Django open source framework for Python. It follows a MVC [http://en.wikipedia.org/wiki/Architectural_pattern_%28computer_science%29 architectural pattern] and was originally released in 2005 with the primary goal of making complex, database driven websites easier to create and maintain. Instilled in its principles are emphasis on loose coupling, rapid development, [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself don’t repeat yourself], and reusability (a.k.a. less code). The basis of its design is to encapsulate objects just like the ActiveRecord design pattern in models so that all the information needed can be stored in the model and knowledge of the database is not exposed. It works with many popular databases available today to include: MySQL, SQLite, MS SQL Server (use MySQL driver), PostgreSQL, and Oracle.

===Enterprise Objects Framework===
Lastly we will introduce [http://en.wikipedia.org/wiki/Enterprise_Objects_Framework Enterprise Objects Framework (EOF)], Mac OS X/Java, part of Apple [http://en.wikipedia.org/wiki/WebObjects WebObjects]. EOF is the oldest of the bunch, introduced in 1994 for a product call [http://en.wikipedia.org/wiki/NeXTSTEP NeXTSTEP]. It was indented to eliminate the interaction with the [http://en.wikipedia.org/wiki/Relational_database relational database] and the Java or Objective-C objects. EOF was later integrated into WebObjects. An EOFModel contains the mappings from the database to the classes, class attributes, and objects. EOF also incorporates inheritance into its feature set to allow a more object oriented approach using Enterprise Objects to reflect the hierarchy. EOF uses [http://en.wikipedia.org/wiki/Jdbc Java Database Connectivity (JDBC)] and [http://en.wikipedia.org/wiki/JNDI Java Naming and Directory Interface (JNDI)] to talk to databases that support that, such as Oracle, DB2, and MySQL.

==Programming using Language Extensions==
Several language extensions have been introduced in previous sections of the article. Let’s take a closer look at a specific scenario and show how each of them would implement their respective table. We will demonstrate how each of the language extensions are used to create a Customer table. The Customer table is very simple; it will contain two fields (an id and name).

*ActiveRecord
For ActiveRecord in Ruby on Rails, the syntax to create the table is contained within the Customer class that inherits from the ActiveRecord class. No external tools are required to generate the Ruby code, only the Ruby interpreter.

<pre>
class Customer < ActiveRecord::Migration
def self.up
create_table :customer do |c|
c.string :name
c.string :id
end
end

def self.down
drop_table :customer
end
end
</pre>

Now create a new Customer in Ruby, update the attributes, and save the object. The .save method will actually update the database table.

<pre>
n = Customer.new
n.id = “1”
n.name = “Customer 1”
n.save
</pre>

*ADO.NET Entity Framework

ADO.NET requires that you use the [http://msdn.microsoft.com/en-us/library/bb738483.aspx Entity Model Designer] which is part of [http://msdn.microsoft.com/en-us/vstudio/default.aspx Microsoft Visual Studio]. The Designer allows you to create your model which includes any entities and associations.

[[Image:Ado-customer.png]]

The Designer will ultimately generate an XML file that represents the Entity Data Model.
<pre>


<EntityType Name = "Customer">
<Property Name = "Name" Type = "String" />
<Property Name = "id" Type = "String" Nullable = "false" />
</EntityType>
</pre>

In code for the Customer object, the setter on the class would look something like this.
<pre>
set
{
this.CategoryReference.EntityKey = new EntityKey("CustomerEntities.Category", "id", “name”);
}
</pre>

*Django

In Django, a model is defined to represent a customer.
<pre>
from django.db import models
class Customer(models.Model):
name= models.CharField(max_length=200)
</pre>

After creating a model for a customer it will generate a corresponding table.
Note that “id” is included as part of the model, so this might cause some unexpected issues if you planned to use id differently.

<pre>
BEGIN;
CREATE TABLE myapp_customer (
"id" serial NOT NULL PRIMARY KEY,
"name" varchar(200),
);
</pre>

Create a new instance of a Customer and save it.

<pre>
c = Customer(name=’Customer 1’)
c.save()
c.id # Returns the ID of your new object.
</pre>

*Enterprise Objects Framework
The biggest downside with EOF and WebObjects is that it is not free. The Server and development environment is fairly expensive. However, here is a quick look at how you would create an EOF model that represents the classes, attributes and the objects.

Generate the Customer definition using the EOModler UI.

[[Image:Eof-customer.png]]

The code to create a new instance / database entry is fairly intuitive.

<pre>
EOEditingContext ec = new EOEditingContext();

Customer c = new Customer();
c.id = "1";
c.name = "Customer 1";

ec.add(c);
ec.saveChanges();
</pre>

As you saw in some of the examples above, 2 of the 4 language extensions require external tools to generate the hooks in to the language.

==Conclusion==
Depending on what language you plan to use for your application will dictate what extensions and tools you will use. If you are driven by cost, then some of the choices are obvious to remove, otherwise you might be driven by you familiarity with a particular language or existing tool set. Either way you can see how all of the languages have attempted to simplify the process of accessing data in an external datastore. There is no clear victor in these comparisons, I believe the situation will dictate which language to use.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch2_2b next article for which the link does not exist yet], we will look at another style of metaprogramming, CRC Cards, one of the simplest methods of doing object oriented design. These cards are a way to capture the initial relationships between objects for a given system. CRC cards will help determine the evolution of these relationships before any code is written. You can learn very quickly about CRC cards by taking a close look at the software used to create CRC cards, and other artifacts of o-o design.

==References==

#[http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Comparison of web application frameworks]
#[http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software List of object-relational mapping software (Wikipedia.org)]
#[http://en.wikipedia.org/wiki/ActiveRecord#Ruby ActiveRecord Ruby (Wikipedia.org)]
#[http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework ADO.NET Entity Framework (Wikipedia.org)]
#[http://en.wikipedia.org/wiki/Django_%28web_framework%29 Django (Wikipedia.org)]
#[http://en.wikipedia.org/wiki/Enterprise_Objects_Framework Enterprise Objects Framework (Wikipedia.org)]
#[http://ruby-doc.org/docs/ProgrammingRuby/ Programming Ruby - The Pragmatic Programmer's Guide]
#[http://www.ruby-lang.org/en/about/ Ruby – A Programmers Best Friend]
#[http://www.djangoproject.com/ Django Project (Djangoproject.com)]
#[http://msdn.microsoft.com/en-us/library/e80y5yhx%28v=VS.71%29.aspx ADO.NET (Micorsoft.com)]
#[http://developer.apple.com/legacy/mac/library/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/EnterpriseObjects/DevGuide/EOFDevGuide.pdf Enterprise Objects Framework (Apple.com)]

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:31:32Z

Nbshah2: /* DSL v/s Object Oriented Frameworks */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:19:31Z

Nbshah2: /* Risks and Opportunities */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The Risks===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:16:30Z

Nbshah2: /* Risks and Opportunities */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

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

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:08:38Z

Nbshah2: /* Requirements for a DSL */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

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

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

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

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

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

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

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

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:02:55Z

Nbshah2: /* Requirements for a DSL */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

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

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

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

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

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:01:55Z

Nbshah2: /* Requirements for a DSL */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

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

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

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

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

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:01:21Z

Nbshah2: /* Requirements for a DSL */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

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

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

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

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

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T14:00:44Z

Nbshah2: /* Typical characteristics of Domain specific languages */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

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

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

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

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

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T13:59:54Z

Nbshah2: /* Domain Specific Object Oriented Languages */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

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

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

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

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

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T13:58:06Z

Nbshah2: /* References */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

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

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

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

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

==Requirements for a DSL==

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

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

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

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

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

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

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

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

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

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

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

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

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

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

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

2) The additional cost of educating the users to learn DSL.

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

4) The scope of DSL is not defined.

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

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

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

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

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

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

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

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

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

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

==Conclusion==

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

==References==

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

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

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

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

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

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

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

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T13:52:53Z

Nbshah2: /* Domain Specific Object Oriented Languages */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

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

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

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

*[http://en.wikipedia.org/wiki/Scalable_Vector_Graphics Scalable Vector Graphics (SVG)] is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic. [8]

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser\

[8] Scalable Vector Graphics - http://en.wikipedia.org/wiki/Scalable_Vector_Graphics

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T13:49:45Z

Nbshah2: /* Domain Specific Object Oriented Languages */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) Inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) Encapsulation] and [http://en.wikipedia.org/wiki/Abstraction_principle_(programming) Abstraction]. They offer substantial gains in expressiveness and ease of use as compared with General object oriented programming languages in their domain of application. Some of the well known object oriented DSLs are,

*[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] which was developed by Xerox Coorp. for educational use,

*[http://en.wikipedia.org/wiki/Simula Simula] which was developed for simulation of programs. [3]

*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. [8]

*Kiddo - used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser\

[8] Scalable Vector Graphics - http://en.wikipedia.org/wiki/Scalable_Vector_Graphics

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T13:42:11Z

Nbshah2: /* Overview */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language) S] and [http://en.wikipedia.org/wiki/Q_(programming_language) Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

*Smalltalk which was developed by Xerox Coorp. for educational use,

*Simula which was developed for simulation of programs. [3]

*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. [8]

*Kiddo - used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser\

[8] Scalable Vector Graphics - http://en.wikipedia.org/wiki/Scalable_Vector_Graphics

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T13:41:46Z

Nbshah2: /* Overview */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are [http://en.wikipedia.org/wiki/R_(programming_language) R], [http://en.wikipedia.org/wiki/S_(programming_language)S] and [http://en.wikipedia.org/wiki/Q_(programming_language)Q] languages for statistics, [http://en.wikipedia.org/wiki/Mathematica Mathematica] and [http://en.wikipedia.org/wiki/Maxima_(software) Maxima] for symbolic mathematics, spreadsheet formulas and macros, [http://en.wikipedia.org/wiki/SQL SQL] for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

*Smalltalk which was developed by Xerox Coorp. for educational use,

*Simula which was developed for simulation of programs. [3]

*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. [8]

*Kiddo - used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser\

[8] Scalable Vector Graphics - http://en.wikipedia.org/wiki/Scalable_Vector_Graphics

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-10-01T13:35:23Z

Nbshah2: /* Overview */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain [http://en.wikipedia.org/wiki/Domain domain] used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

*Smalltalk which was developed by Xerox Coorp. for educational use,

*Simula which was developed for simulation of programs. [3]

*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. [8]

*Kiddo - used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser\

[8] Scalable Vector Graphics - http://en.wikipedia.org/wiki/Scalable_Vector_Graphics

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T02:19:08Z

Nbshah2: /* References */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

*Smalltalk which was developed by Xerox Coorp. for educational use,

*Simula which was developed for simulation of programs. [3]

*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. [8]

*Kiddo - used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser\

[8] Scalable Vector Graphics - http://en.wikipedia.org/wiki/Scalable_Vector_Graphics

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T02:18:03Z

Nbshah2: /* Domain Specific Object Oriented Languages */

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T02:15:22Z

Nbshah2:

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

*Smalltalk which was developed by Xerox Coorp. for educational use,

*Simula which was developed for simulation of programs. [3]

*Scalable vector graphics

*Kiddo - used for building silverlight and WPF applications. Kiddo is based on ideals of "kid friendly" coding

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

*Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

*Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

*Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

*Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

*Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

*Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

* How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

* How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

* What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T02:11:46Z

Nbshah2: /* Risks and Opportunities */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

• Smalltalk which was developed by Xerox Coorp. for educational use,

• Simula which was developed for simulation of programs. [3]

• Scalable vector graphics

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T02:10:02Z

Nbshah2: /* Domain Specific Object Oriented Languages */

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

• Smalltalk which was developed by Xerox Coorp. for educational use,

• Simula which was developed for simulation of programs. [3]

• Scalable vector graphics

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T02:09:30Z

Nbshah2:

'''Domain Specific Object Oriented Languages'''

==Overview==

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

===Domain specific languages vs. General programming languages===

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

===Domain Specific Object Oriented Languages===

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

• Smalltalk which was developed by Xerox Coorp. for educational use,

• Simula which was developed for simulation of programs. [3]

• Scalable vector graphics

===Typical characteristics of Domain specific languages===

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

==Requirements for a DSL==

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

==Risks and Opportunities==

Adopting for development of domain specific languages has its own pros and cons.[7]
===The Pros===

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

===The cons===

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

==Open Issues or challenges related to DSLs==

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

==Conclusion==

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

==References==

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T01:58:02Z

Nbshah2:

DOMAIN SPECIFIC OBJECT-ORIENTED LANGUAGE

Overview

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

Domain specific languages vs. General programming languages

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

Domain Specific Object Oriented Languages

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

• Smalltalk which was developed by Xerox Coorp. for educational use,

• Simula which was developed for simulation of programs. [3]

• Scalable vector graphics

Typical characteristics of Domain specific languages

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

Requirements for a DSL

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

Risks and Opportunities

Adopting for development of domain specific languages has its own pros and cons.[7]
The benefits being :-

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

The disadvantages of the use of a DSL are:-

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

Open Issues or challenges related to DSLs

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

Conclusion:

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

References:

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T01:57:40Z

Nbshah2:

DOMAIN SPECIFIC OBJECT-ORIENTED LANGUAGE

Overview

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

Domain specific languages vs. General programming languages

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

Domain Specific Object Oriented Languages

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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,

• Smalltalk which was developed by Xerox Coorp. for educational use,
• Simula which was developed for simulation of programs. [3]
• Scalable vector graphics

Typical characteristics of Domain specific languages

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

Requirements for a DSL

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

Risks and Opportunities

Adopting for development of domain specific languages has its own pros and cons.[7]
The benefits being :-

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

The disadvantages of the use of a DSL are:-

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

Open Issues or challenges related to DSLs

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

Conclusion:

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

References:

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T01:53:20Z

Nbshah2:

DOMAIN SPECIFIC OBJECT-ORIENTED LANGUAGE

Overview

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

Domain specific languages vs. General programming languages

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

Domain Specific Object Oriented Languages

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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 Smalltalk which was developed by Xerox Coorp. for educational use, Simula which was developed for simulation of programs. [3]

Typical characteristics of Domain specific languages

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

Requirements for a DSL

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

Risks and Opportunities

Adopting for development of domain specific languages has its own pros and cons.[7]
The benefits being :-

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

The disadvantages of the use of a DSL are:-

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

Open Issues or challenges related to DSLs

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

Conclusion:

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

References:

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T01:52:12Z

Nbshah2:

DOMAIN SPECIFIC OBJECT-ORIENTED LANGUAGE

Overview

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

Domain specific languages vs. General programming languages

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

Domain Specific Object Oriented Languages

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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 Smalltalk which was developed by Xerox Coorp. for educational use, Simula which was developed for simulation of programs. [3]

Typical characteristics of Domain specific languages

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

Requirements for a DSL

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

Risks and Opportunities

Adopting for development of domain specific languages has its own pros and cons.[7]
The benefits being :-

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

The disadvantages of the use of a DSL are:-

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

Open Issues or challenges related to DSLs

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.

• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?

• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

Conclusion:

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

References:

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T01:50:22Z

Nbshah2:

DOMAIN SPECIFIC OBJECT-ORIENTED LANGUAGE

Overview

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

Domain specific languages vs. General programming languages

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

Domain Specific Object Oriented Languages

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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 Smalltalk which was developed by Xerox Coorp. for educational use, Simula which was developed for simulation of programs. [3]

Typical characteristics of Domain specific languages

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

Requirements for a DSL

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

Risks and Opportunities

Adopting for development of domain specific languages has its own pros and cons.[7]
The benefits being :-

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

The disadvantages of the use of a DSL are:-

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

Open Issues or challenges related to DSLs

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered? Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.
• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?
• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

Conclusion:

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

References:

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T01:49:17Z

Nbshah2:

DOMAIN SPECIFIC OBJECT-ORIENTED LANGUAGE

Overview

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

Domain specific languages vs. General programming languages

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.

Domain Specific Object Oriented Languages

Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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 Smalltalk which was developed by Xerox Coorp. for educational use, Simula which was developed for simulation of programs. [3]

Typical characteristics of Domain specific languages

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

Requirements for a DSL

Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.

•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.

•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.

•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.

•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.

•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

Risks and Opportunities

Adopting for development of domain specific languages has its own pros and cons.[7]
The benefits being :-

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

The disadvantages of the use of a DSL are:-

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

Open Issues or challenges related to DSLs

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered?
Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.
• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?
• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

Conclusion:

Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

References:

[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser

CSC/ECE 517 Fall 2010/ch2 S23 NR

2010-09-23T01:47:08Z

Nbshah2:

DOMAIN SPECIFIC OBJECT-ORIENTED LANGUAGE

Overview

Domain specific languages (DSLs) are the programming languages focused to certain domain used to find the solutions using domain specific representation techniques. Domain can be any field such as Mathematics, Relational Databases, etc or it can even be any specific business/business unit such as Insurance, Billing department of any company, salary calculation, etc. Popular examples of Domain specific languages are R, S and Q languages for statistics, Mata for matrix programming, Mathematica and Maxima for symbolic mathematics, spreadsheet formulas and macros, SQL for relational database queries

Domain specific languages vs. General programming languages

General Programming languages are the ones which can be used for developing solution for any field or any business units. Most popular examples being C, C++ and Java. Domain specific languages provide a high edge over general languages in their application domain.
Domain Specific Object Oriented Languages
Domain-specific Object Oriented Languages are usually little languages that are particularly expressive in a certain problem domain and are also task-specific, application-oriented. In addition to that it also encompasses object oriented principles such as Inheritance, Encapsulation and 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 Smalltalk which was developed by Xerox Coorp. for educational use, Simula which was developed for simulation of programs. [3]

Typical characteristics of Domain specific languages

DSLs are usually small, offer only restricted suite of notations and abstractions and are also called as micro/ little languages. Sometimes, however, they are made on top of general purpose language, thus offering domain-specific expressive power in addition to the expressive power of the GPL [7].

DSLs are declarative. Hence, they can be viewed as specification languages, as well as programming languages. Many DSLs are supported by a DSL compiler which generates applications from DSL programs. [7]

Requirements for a DSL
Many of the requirements for DSLs are same as ones for the general-purpose programming languages. However, they differ on the level of importance when compared with the general purpose languages. [6]

The core requirements for a DSL are as follows:

•Conformity: The basic requirement is that the language must address to all the important concepts of the domain for which it is used for.
•Supportability: it is feasible to provide DSL support via tools, for typical model and program management, e.g., creating, deleting, editing, debugging, transforming. It will be of great ease if the DSL support is provided via tools, which are already used by the people of that field. The host tool takes care of the basic functionalities of the domain.
•Integrability: The DSL language should be capable of working with other tools and languages of the same field. This is essential so that the existing applications can easily adapt to new language.
•Longevity: The DSL should be used for sufficient amount of time by the users to justify the cost of creating DSL and its supporting tools.
•Simplicity: It should be easy to be adapted by the new and existing users in the domain. This also makes sure that the user focus more on the application development rather than learning the DSL.
•Quality: The language should produce high quality applications which are better in terms of all the related language constructs like reliability, security, safety, etc.

The above mentioned requirements are the general requirements for DSLs. There can be additional requirement depending upon the domain for which they are created.

Risks and Opportunities

Adopting for development of domain specific languages has its own pros and cons.[7]
The benefits being :-

1) 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.

2) Since DSLs are specific to a domain, programs are concise and self documented to a large extent.

3) DSLs enabling the experts to focus more on a problem domain thus enhancing the quality and productivity, making it more reliable, easy to maintain..

4) They embody specific domain knowledge, and thus enabling the conservation and reuse of this knowledge in a way.

5) It enables programs to be validated and optimized at the domain level.

6) Since it is specific to a language improves its ability to be tested.

7) It gives better end user experience.

8) They are easy and exciting for the problem domain experts.

The disadvantages of the use of a DSL are:-

1) The cost of designing, implementing and maintaining DSL is high.

2) The additional cost of educating the users to learn DSL.

3) The domain experts need to have knowledge about language design principles in order to develop it a DSL.

4) The scope of DSL is not defined.

5) It is difficult to balance between domain-specificity and general-purpose programming constructs.

6) It does not have a strong development tool support as compared to other general purpose programming languages. Eg. NetBeans and 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:-

1) Expressiveness: DSL expresses knowledge that is domain-specific whereas using a general purpose programming language as in a framework provides more flexibility in adapting to specific needs.

2) The Calling Framework: A framework often is an active entity and does not get called but it calls functions provided by the application developer. This can also be easily achieved using a DSL. [2]

3) Overriding Default Behavior: White-box frameworks allow the application developer to override default behavior using inheritance. This can also be achieved by using DSL but it does not seem obvious and intuitive. [2]

4) Language technology: DSL requires tools for supporting rapid prototyping of scanners, parsers, type checkers, interpreters, compilers. On the contrary, there is no such need in object oriented frameworks as they are made on the top of high level languages. [2]

Open Issues or challenges related to DSLs

There are a number of open issues that require further investigation. [7] They are,

• How do requirements are refined when a specific domain is considered?
Each domain has its own requirements and specification on to the use of the DSL, resulting in higher stress for analyzing the domain.
• How can we measure the cost-versus-benefit of using DSLs as opposed to general-purpose languages?
• What about the side-effects of using DSLs, in particular, the implicit use of a number of (loosely coupled) languages throughout development, the use of a federation of tools versus an integrated development environment, etc.

Conclusion:
Domain specific languages(DSL) are focused towards a specific domain solution enabling easy development for domain experts. DSL are more domain specific than general languages. They are productive, reliable, and maintainable but on the other hand needs expertise, developmental tools and overhead cost involved which should be carefully considered before development. Thus, DSL are providing good solution for domain- specific problems but it has few issues to be considered. Recent development in various high level programming languages has addressed most these issues by development of various domain specific packages.

References:
[1] A Domain-specific Metamodel for Reusable Object-Oriented High-Integrity Components - Matteo Bordin and Tullio Vardanega

[2] Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study

[3] Domain-Specific Languages for Software Engineering
-Jan Heering, Marjan Mernik

[4] A model-driven framework for domain specific languages demonstrated on a test automation language - Martin Karlsch,

[5] Concepts for ModelDriven Design and Evolution of DomainSpecific Languages
-Uwe Zdun

[6] Requirements for Domain-Specific Languages
-Dimitrios S. Kolovos, Richard F. Paige, Tim Kelly, and Fiona A.C. Polack

[7] Domain-Specific Languages: An Annotated Bibliography1 Arie van Deursen - Paul Klint - Joost Visser