Adil Akhter | Blog

Semantics with Application by Hanne Riis Nielson & Flemming Nielson

Md.AdilAkhter — Sat, 04 Jun 2011 20:44:51 +0000

View this document on Scribd

Course Notes are available at: http://www.daimi.au.dk/~bra8130/Wiley_book/wiley.html

Basics of Compiler Design by Torben Ægidius Mogensen

Md.AdilAkhter — Fri, 03 Jun 2011 12:50:55 +0000

View this document on Scribd

Model-Driven Software Development

Md.AdilAkhter — Fri, 27 May 2011 17:37:50 +0000

The following lectures on Model-Driven Software Development(MDSD) are given by Dr. Eelco Visser at Tudelft in IN4308 course. To get the basic idea of MDSD and motivation behind it , please go through these lectures .

Lecture 1 : MDSD : Introduction and Overview

Lecture 2 : Domain Analysis & Data Modeling

Lecture 3 & 4 : Web Abstraction

In these lectures, WebDSL , a DSL for Web Application is introduced. Continuing from the previous discussion on Domain Analysis, these lectures address the design issues and motivation behind abstracting the domain of Web Application using this DSL.

Lecture 5 : Web Abstraction to actual Implementation

Implementing Polymorphism by @the_antlr_guy

Md.AdilAkhter — Thu, 26 May 2011 22:19:56 +0000

Implementing Polymorphism by @the_antlr_guy : http://goo.gl/IM9UN

Great Read | Bootstrapping a simple compiler from nothing

Md.AdilAkhter — Thu, 26 May 2011 21:56:38 +0000

Great Read | Bootstrapping a simple compiler from nothing @ http://bit.ly/k3S3kz

Bytecode-to-bytecode adaptive optimization for Smalltalk

Md.AdilAkhter — Thu, 26 May 2011 21:51:06 +0000

Inside Software Language Composition

Md.AdilAkhter — Thu, 26 May 2011 16:19:22 +0000

Language composition is an integral aspect of Software Language Engineering(SLE) to enable modularity in language definition and ensure reusability of the existing language constructs.

“From now on, a main goal in designing a language should be to plan for growth.” - Guy Steele: Growing a Language, OOPSLA’98 invited talk[1].

Ideally, a language should be designed in such a way that evolving it with respect to different language constructs should require the minimum effort. However, that is far from reality in SLE. It is well-known that designing and implementing a high quality language requires considerable amount of effort. Therefore, to incorporate agile development concepts in SLE and to support language evolution and integration in modest maintenance effort, reusability of the existing language constructs is considered as a fundamental functional requirement of SLE.

The complexity of this problem increases with the ubiquitous proliferation of Domain-specific Languages(DSLs), since composition of various DSLs in the context of solving different problems has become a real-world use-case scenario. Thus, wider-acceptability of DSLs further warrant modular composition of language features since the realization of the DSLs can only be discerned if efforts put in their actual implementation can somehow be optimized.

Currently, we are working on designing a meta-language that will support modular definition of the language constructs. Primary objective of this endeavor is to promote “Language-as-a-Library” ideology in SLE. Modularity is another integral aspect of this meta-language that will allow language designer to create different language modules and can be used as in by adding reference. Therefore, we envisage that the outcome of this research would be a framework that will facilitate rapid software language development by reusing the exiting language features as much as possible and thus, it will enable cost-effective (agile) language development.

In addition , with the goal of designing language in a modular and reusable manner, we started with a survey to find out the existing state-of-the-art framework that supports several features discussed above. In the next blog posts, we will discuss about the potential outcome(s) of the research along with, the existing strategies of software language composition(SLC), the technologies promoting the notion of modular and composable language. Stay tuned!

References

1. Jr., G.L.S.: Growing a language. Higher-Order and Symbolic Computation 12(3), 221–236 (1999) .

Domain Specific Languages (DSLs)

Md.AdilAkhter — Thu, 26 May 2011 15:42:32 +0000

Domain-specific languages (DSLs) are basically programming languages. But they are specifically targeted/tailored towards particular problem domains. Hence, it implies that DSLs are narrow in applicably unlike General-purpose programming languages(GPLs)[1]; thus, DSL precisely abstracts the domain and its semantics. At the same time, being specific to a particular problem domains make it hard to reuse and adapt to a new problem domains or in the same evolving domain with new set of requirements.

Figure 1: DSLs are bridging the semantic gaps.

“Only way to manage complexity is to bring order to chaos”

Complex software systems consist of several concerns such as, performance, reliability , fault-tolerance, persistency. Hence, domain specialization is required to capture these concerns precisely and to perform various analyses specific to the domain. DSLs , thus reduce the complexity of complex systems by providing high level linguistic abstraction through succinct syntax and by isolating concerns from one another which additionally results in highly cohesive sub-systems. Following figure illustrate the fact that DSLs covers various concerns of complex software systems vertically rather than horizontally.

Figure 2 : Vertical domain specialization of DSLs in a complex system.

Although in recent years DSL-centric paradigm gets wider-applicability in various application domains due to the increase of domain specialization, the fundamental ideas[2] of DSLs existed long before.

As we were discussing in this blog, the inherent implementation strategies of DSLs warrant re-thinking the software process involved in DSLs development. To a large extent, success of a DSL depends on the cost-effectiveness of the end product. We believe that it can only be achieved through modularizing definition of DSLs and by promoting reusability of the existing language constructs. Different aspects even when beginning a DSL development thus require careful considerations.

Key Properties of a DSL

Coverage

Expressivity

Completeness

Portability

Support for evolution

Quality of the generated artifacts.

Types of DSLs

Primarily, DSLs can be categorized into following categories–

Implicit DSLs or Explicit DSLs

Textual DSLs or Visual DSLs

Basic Components of a DSL

Alike GPLs, a DSL is constructed with the following primary components.

Syntax definition formalism for defining syntax.

A parser to parse the syntax of DSL and construct Abstract Syntax Tree(AST) or underlying model. ( however, visual DSLs does not require parsers as AST can be constructed from the end-users’ specification).

Model Transformer. It performs several model-to-model transformation such as, dusugaring , normalizing , decorating. As such, it annotate more context to AST.

Afterwards, Semantic Analyzer performs static consistency checking.

Code Generators. Final artifacts are generated through model transformation and string interpolation. In several DSLs, during code generations or in earlier phases, a meta-model is created. Afterwards, artifacts are generated by utilizing this meta-model. This way of creating a meta-model and generating artifacts from it promotes robust and maintainable code generator along with quality outcomes. Complex systems may require additional tuning, which can be facilitated via Code Customization ( we will discuss about it in later blog posts) .

Figure 3 : Various phases of step-by-step transformations and finally, code generation using a DSL [3].

Aside above mentioned components, support of rich development environment is increasingly becoming important to get expected productivity from a DSLs. Several language workbenches[3] thus are providing rich support via various editor services such as code folding , syntax highlighting , reference resolving, syntax completion.

References

[1] Spinellis, D. (2001). “Notable design patterns for domain-specific languages.” J. Syst. Softw. 56(1): 91-99.
[2] Landin, P. J. (1966). “The next 700 programming languages.” Commun. ACM 9(3): 157-166.
[3]L. Kats, E. Visser.The Spoofax Language Workbench . Rules for Declarative Speci?cation of Languages and IDEs.

Summary : “Towards Context Sensitive Domain Specific Languages” by Laird & Barrett

Md.AdilAkhter — Sun, 16 Jan 2011 16:04:06 +0000

The high cost of developing and integrating Domain-Specific Languages (DSLs) in an existing system narrows down its applicability in other domains. In this frequently changing world, the abstraction of a domain also undergoes change, which makes the maintainability of an existing DSL costly as it is change-susceptible. To overcome the problem attached to the integration, maintainability and adaptability of DSLs, the authors promote a dynamic interpretation model that allows the adaptation of the program’s execution without any syntactic change to the DSL with respect to the varying context by decoupling the semantics of the DSL from its implementation.

To support this dynamic interpretation model, the authors propose adopting a component based model where the generic interpreter coordinates with the different runtime components to interpret the language specification. The dynamic reconfiguration of these components with respect to the varying context allows for context-sensitive semantics of the same language specification. Thus, the model can be discerned as a function that takes three inputs in form of – a language definition, components and context information and outputs a dynamic configuration that reflects the specified context. By using polymorphic counterpart, a generic interpreter can reinterpret a language types of non-functional behavior can also be accommodated in the components’ implementation, thus conforming to a particular context to support these non-functional aspects. Therefore, it is evident that this model enables dynamic customization of the language semantics based on the context and various changing requirements which, in turn, makes the DSLs highly adaptable.

In the coda, the authors argue that this model of dynamic reconfiguring the interpreter results in more flexible adaptability than the existing static model to reflect the changes in the context. Although the development cycle of a new DSL still remains the same as its static counterpart, this dynamic model has a positive impact on the maintainability of DSL. As a result of this model, the author envisage that by redefining the language for a different context, an existing DSL can be reused to spawn off a new DSL, which in turn can significantly reduce the development costs of DSLs. Henceforth, it can solve the initial problem of narrow applicability of DSLs due to high cost through reusability.

Tagged: DSLs, Language-Design

Coordination Strategies: Beyond Scrum | Part 3

Md.AdilAkhter — Mon, 02 Aug 2010 20:46:00 +0000

In the previous post, we discuss different strategies that are imperative in successful implementation of Scrum process model in the GSD context. In this post, we take this discussion further by introducing few strategies that are originated from other disciplines than software development; however, can have positive impact on the LFDS.

Queuing Theory: Increase Parallelism by Eliminating Queues

Queuing Theory [1] provides an insight on the release cycle in the large-scale product development. In today’s competitive market, in order to survive, it has become essential to minimize the release cycle of the new features. Hence, careful consideration of Work-in-Progress (WIP) queues with long-batch of task should be taken into account in large-scale Scrum, as they increase the average cycle times and eventually, reduce value delivery. C. Larman and B. Vodde propose the following approaches to manage WIP queues in large-scale Scrum context[1].

─ Eliminate the queues by changing the system – removing the bottlenecks and the other factors that create the queues.

─ Introducing the feature teams that implement customer features from end-to-end and reducing the dependencies, can vanish these queues, as the feature teams begin a highly parallel development cycles.

─ Reduce variability e.g. ambiguity in user stories[2], estimated vs. actual effort variance and so on. Variability is considered as one of the three sources of waste in lean thinking[3].

Incorporate Lean Thinking in the LFDS

Lean thinking is a proven system that works for the large-scale development. Toyota and other companies show such evidences. The main two principles of lean are following: a) continuous improvement or kaizen and b) respect for people[3]. The lean principle always strives for self and organizational improvement and promotes an atmosphere of continuous learning and embracing changes, which is complementary to the Scrum principle as well. Reducing waste from every phase of the development cycle is one of the primary mottos of lean principle. Hence, adopting and embracing these principles in the software development sub-culture of the organization is bound to have a positive impact on the efficiency of the LFDS.

References

[1] C. Larman and B. Vodde, Scaling Lean \& Agile Development: Thinking and Organizational Tools for Large-Scale Scrum: Addison-Wesley Professional, 2008.

[2] M. Cohn, Succeeding with Agile: Software Development Using Scrum: Addison-Wesley Professional, 2009.

[3] P. Middleton, “Lean Software Development: Two Case Studies,” Software Quality Control, vol. 9, pp. 241-252, 2001.