course software language engineering - uni koblenz-landaulaemmel/slecourse/slides/intro.pdf ·...

© 2012-14 Ralf Lämmel, Software Language Engineering http://softlang.wikidot.com/course:sle

This is it! This is the course!

(for language engineers)

Course "Software Language Engineering"

University of Koblenz-Landau

Department of Computer Science

Ralf Lämmel

Software Languages Team1

http://softlang.wikidot.com/course:sle


What’s “software language engineering” anyway?

2



Software language engineering is the application of systematic, disciplined, and quantifiable approaches to the development (design, implementation, testing, deployment), use, and maintenance (evolution, recovery, and retirement) of these languages. Of special interest are (1) formal descriptions of languages that are used to design or generate language-based tools and (2) methods and tools for managing such descriptions, including modularization, refactoring, refinement, composition, versioning, co-evolution, recovery, and analysis.

http://planet-sl.org/sle2012/

3


http://planet-sl.org/sle2012/index.php?option=com_content&view=article&id=4&Itemid=278


Software practitioners are rapidly discovering the immense value of Domain-Specific Languages (DSLs) in solving problems within clearly definable problem domains. Developers are applying DSLs to improve productivity and quality in a wide range of areas, such as finance, combat simulation, macro scripting, image generation, and more. But until now, there have been few practical resources that explain how DSLs work and how to construct them for optimal use. Software Language Engineering fills that need. Written by expert DSL consultant Anneke Kleppe, this is the first comprehensive guide to successful DSL design. Kleppe systematically introduces and explains every ingredient of an effective language specification, including its description of concepts, how those concepts are denoted, and what those concepts mean in relation to the problem domain. Kleppe carefully illuminates good design strategy, showing how to maximize the flexibility of the languages you create. She also demonstrates powerful techniques for creating new DSLs that cooperate well with general-purpose languages and leverage their power.

http://www.amazon.de/Software-Language-Engineering-Domain-Specific-Metamodels/...

4

More illustration


http://www.amazon.de/Software-Language-Engineering-Domain-Specific-Metamodels/dp/0321553454/ref=sr_1_1?ie=UTF8&qid=1350958058&sr=8-1


P. Klint and R. Lammel and C. Verhoef · 17

"Grammarware hacking" "Grammarware engineering"

recovery

by tr

ansf

orm

atio

nsgeneration

Parserim

prov

emen

t

Manualcoding

...

Semi−automatic

Semi−automatic

...

...

customisationTest−data

generation

Test−data setParser Parser Parseras input

Grammar

as input

specificationParserParser

specificationspecificationParser

Codebase

Tria

l & e

rror

Incr

emen

tal

generationParser

generationParser

knowledgeGrammar

toolingGrammarware

Fig. 3. Parser development: The left-hand side illustrates common practise. Grammar knowledge, as containedin a language reference, is coded directly as a proprietary parser specification. Options for improvements areshown on the right-hand side. A technology-neutral grammar is recovered from the grammar knowledge, andsubsequent customisation can target different parser technologies. The parsers are not just tested against thecodebase of interest, but they are also stress-tested. Extra grammarware tooling supports this process.

can be targeted as opposed to an early commitment to a specific technology. The cus-tomisation process is likely to require input from the grammarware engineer.

—There are opportunities for quality assurance by means of testing. We can stress-testthe derived parsers using huge generated test-data sets. We can test a reference parserwith positive and negative cases (not shown in the figure). We can perform a coverageanalysis for the given codebase (not shown in the figure) to see how representative it is.

We have exercised elements of this approach in our team for a string of languages, e.g., forCobol [Lammel and Verhoef 2001b], which is widely used in business-critical systems, andfor PLEX [Sellink and Verhoef 2000a], which is a proprietary language used at Ericsson.

3.2 Lack of best practisesOur claim about grammarware hacking can be substantiated with a number of generalobservations that concern the treatment of grammars in software development:

—There is no established approach for adapting grammars in a traceable and reliable man-ner — not to mention the even more difficult problem of adapting grammatical struc-ture that is ingrained in grammar-dependent software. This is a major problem becausegrammatical structure is undoubtedly subject to evolution.

P. Klint, R. Lämmel, C. Verhoef: Toward an engineering

discipline for GRAMMARWARE.

TOSEM 2005.

Software language engineering from the point of view of Grammarware

5



What’s a “software language” anyway?

6



http://planet-sl.org/sle2012/

The term "software language" refers to artificial languages used in software development including general-purpose programming languages, domain-specific languages, modeling and meta-modeling languages, data models, and ontologies. Examples include general purpose modeling languages such as UML, but also domain-specific modeling languages for business process modeling, such as BPMN, or embedded systems, such as Simulink or Modelica, and specialized XML-based and OWL-based languages and vocabularies. The term "software language" also comprises APIs and collections of design patterns that define a language implicitly.

7


http://planet-sl.org/sle2012/index.php?option=com_content&view=article&id=4&Itemid=278


Java?

This is a software language in that it is used in software development for the implementation of software systems.

8



UML in MDA?

This is a software language in that it is used in software development for models of software systems to be gradually transformed into actual code of software systems.

9



UML?

This is a software language in that it is used in software development as modeling software systems to help understanding between system owner and developer.

10



UML on the whiteboard?

Is this a software language?

11



HTML and CSS?

These are software languages because they support the development of web-based software systems as they cover some aspect of the systems’ user interfaces.

12



Mediawiki markup?

This is, “probably”, a software language because it is used to author content for a web-enabled knowledge representation et al. system.

13



English?

This is not a software language because it is, in fact, a natural language that has existed and continues to exist independently of computer science.

14



Controlled_natural_language

Such a language may be a software language, e.g.:

http://www.omg.org/spec/SBVR/1.0/ A barred driver must not be a driver of a rental.

It is prohibited that a barred driver be a driver of a rental.

It is obligatory that no barred driver is a driver of a rental.

[http://www.w3.org/2004/12/rules-ws/paper/67/]

15


http://en.wikipedia.org/wiki/Controlled_natural_language

http://www.omg.org/spec/SBVR/1.0/


Motivation (Who needs SLE?)

16



SLE -- what for?Compiler Construction (“classic”)

Domain-specific languages (“hype”)

Model-driven engineering (?)

Program generation

Software reverse engineering

Software re-engineering

Technical space travel

...17



SLE -- what for?Compiler Construction (“classic”) Domain-specific languages (“hype”)


Program generation




...18



Compiler construction

Resource: https://engineering.purdue.edu/~milind/ece573/2011spring/ (Milind Kulkarni)

19


https://engineering.purdue.edu/~milind/ece573/2011spring/


“Wishful” reading

20




Domain-specific languages (“hype”) Model-driven engineering (?)

Program generation




...21



A DSL is a focussed, processable language for describing a specific concern when building a system in a specific domain. The abstractions and notations used are natural/suitable for the stakeholders who specify that particular concern.

[https://github.com/slecourse/slecourse/wiki/dslDesign]

22


https://github.com/slecourse/slecourse/wiki/dslDesign


A DSL for state machines

How to support such visual syntax? How to textually represent state machines?

How to interpret textual/visual representation?23



A DSL for state machines

We need code generation.

initial state Locked { Ticket/Collect ➝ Unlocked; Pass/Alarm ➝ Locked;

} state Unlocked {

Ticket/Eject ➝ Unlocked; Pass ➝ Locked;

}

24



The LINQ DSL for data queries

How to embed the DSL into the host language?

[http://www.dotnetperls.com/linq]

25


http://www.dotnetperls.com/linq


C

LEGO Robot

Control

Components

State Machines

Sensor Access

General Purpose

Domain

Specific

[https://github.com/slecourse/slecourse/wiki/dslDesign]26




L

a b

c

d

e

f

g h

i

j

k

m

n

o

with many first class concepts!

Big Language

L

! "

# $

%

Small Language

and poweful concepts with a few, orthogonal

[https://github.com/slecourse/slecourse/wiki/dslDesign]27




“Wishful” reading

28





Model-driven engineering (?) Program generation




...29



[http://en.wikipedia.org/wiki/Model-driven_engineering] 23 Oct 2012

30


http://en.wikipedia.org/wiki/Model-driven_engineering


MDE exampleGeneration)Result)

<<COM+>>'HolidayRes'

IHolidayRes' <<interface>>'IHolidayRes'

+findOffers'(criteria:'Criteria)':'Offer[]'+book'(offer':'Offer)':'Confirmation'

public class HolidayRes : ServicedComponent { public HolidayRes() {} public Offer[] findOffers (Criteria criteria) {} public Confirmation book (Offer offer) {} }

(c)$S.$Zschaler,$I.$Poernomo$ 34$

[https://github.com/slecourse/slecourse/wiki/mdeTourDeForce] Steffen Zschaler and Iman Poernomo, King's College London, 2012

31


https://github.com/slecourse/slecourse/wiki/mdeTourDeForce





Program generation Software reverse engineering



...32



Program generation for ANTLR-based parsers

company :! 'company' STRING '{' department* '}' EOF;! !department :! 'department' STRING '{' ! ('manager' employee)! ('employee' employee)* ! department*! '}';!!employee :! STRING '{'! 'address' STRING! 'salary' FLOAT! '}';

[101implementation:antlrAcceptor]

33


http://101companies.org/index.php/101implementation:antlrAcceptor


Program generation is an essential element of language implementation,

but it also used in other contexts.

34



Program generation for remote-method invocation

Host mymac.foo.edu Host myserver.bar.edu

Object Client Remote

Object

Remote Object Stub:

serves as Remote

Reference

odd(3) 01101 odd(3)

true10010true

Same interface as remote object

Serialized method name, parameters and

return value

Remote Object

Skeleton

The purple functionality requires program generation (or reflection).

35






Program generation

Software reverse engineering Software re-engineering


...36



“Reverse engineering is the process of analyzing a subject system to create representations of the system at a higher level of abstraction.”

Chikofsky, E. J.; Cross, J. H. (January 1990). "Reverse engineering and design recovery: A taxonomy". IEEE Software 7: 13–17. doi:10.1109/52.43044.

37


http://win.ua.ac.be/~lore/Research/Chikofsky1990-Taxonomy.pdf

http://en.wikipedia.org/wiki/Digital_object_identifier

http://dx.doi.org/10.1109%2F52.43044


Package view of a GMF project for a library (Joined work with Davide Di Ruscio and Alfonso Pierantonio)

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

� ��

� ��

��

��

��

��

��

��

�� !�� " ��

��

��#��

��

�� #�� $��

�� !%�� $�&��

�� !� ��

�� !�� "� ��

�� %��" ��

��

�� " ��

��

��

��

��

Gray means generated and used by custom code. Light gray means generated code not used by custom code.

Red means generated code that was amended. Green means custom code referring to generated code.

Yellow means custom code not referring to generated code.

38



��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

� ��

� ��

��

��

��

��

��

��

�� !�� " ��

��

��#��

��

�� #�� $��

�� !%�� $�&��

�� !� ��

�� !�� "� ��

�� %��" ��

��

�� " ��

��

��

��

��

Some additional languages: - the scheme for extracted data - the visual language for graphs

39



Dependencies in a GMF project for a library (Joined work with Davide Di Ruscio and Alfonso Pierantonio)

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�� !��

�� !��

�� !��"#$��

�� %��

% �� %��

��%��

�� %��

��& �� "� �� %��

��%��

��& �� %��

��%��

�� !%��

% ��%��

% ��%��

��%��

��#�� #��

40



��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�� !��

�� !��

�� !��"#$��

�� %��

% �� %��

��%��

�� %��

��& �� "� �� %��

��%��

��& �� %��

��%��

�� !%��

% ��%��

% ��%��

��%��

��#�� #��

41






Program generation


Software re-engineering Technical space travel

...42



[http://en.wikipedia.org/wiki/Reengineering_(software)] 23 Oct 2012

Software re-engineeringThe reengineering of software was described by Chikofsky and Cross in their 1990 paper [RL: as mentioned before], as "The examination and alteration of a system to reconstitute it in a new form". Less formally, reengineering is the modification of a software system that takes place after it has been reverse engineered, generally to add new functionality, or to correct errors.

43


http://en.wikipedia.org/wiki/Reengineering_(software)

http://en.wikipedia.org/wiki/Software


Example: refactoring

Method extraction in Java

void printOwning(double amount) {printBanner ();//print detailsSystem.out.println("name:" + _name);System.out.println("amount" + amount);

}

⇓???

44



.

.

.⇓

void printDetails(double amount) {System.out.println("name:" + _name);System.out.println("amount" + amount);

}void printOwning(double amount) {printBanner ();printDetails(amount);

}

45



Variations on generic extractionParadigm Focus AbstractionOO programming statements methodOO programming features classFunctional programming expression functionFunctional programming type expression datatypeFunctional programming functions type classLogic programming literal predicateSyntax definition EBNF phrase nonterminalPreprocessing code fragment macroDocument processing content particle element typeCobol programming sentences paragraphCobol programming sentences subprogramCobol programming data description entries copy bookCobol programming data description entries group field

Other kinds of extraction

46



Transformations (refactorings) other than extraction

Inlining (inverse of extraction) Introduction / elimination Fold / unfold (similar extract / inline) Pull up / push down Add parameter Reorder ...

47



Extraction of a Haskell datatypeInput program with focus

data Prog = Prog ProgName [Dec ] [Stat ]

data Dec = VDec Id Type | ...data Stat = Assign Id Expr | If Expr Stat Stat | ...

Output program after extraction and integration

data Prog = Prog ProgName Blockdata Block = Block [Dec ] [Stat ]data Dec = ...data Stat = ... | BlockStat Block...

48



A generic view on extractionIllustration of generic extraction

List of abstractions

. . . . . .

2. Replacement

1. Introduction

fragmentFocused

49



Generic steps of extraction

1. Lookup focused fragment. 2. Determine free names in focused fragment. 3. Enforce language-dependent check on focus. 4. Construct abstraction. 5. Find host for new abstraction. 6. Introduce abstraction. 7. Construct application. 8. Replace focus by application.

50



Language issues in refactoring (re-engineering)

Transformation requires certain language services.

Transformation principles are to be mapped to languages.

Sets of transformation operators may be viewed as DSL.

...

51



Example: coupled transformationThere is an abundance of scenarios in software development which involve software transformations that affect multiple artifacts essentially in a coupled manner. That is, if one of the artifacts of the scenario is changed, then one or more of the remaining artifacts have to be co-changed. Here are some scenarios that involve such changes and co-changes: • XML data binding • Object-relational mapping • Updateable views in databases • Data integration and data exchange • Multi-view specification and consistency • Instance mapping in reply to schema evolution • Program transformation in reply to schema evolution • Model transformation in reply to metamodel evolution

In the scope of coupled software transformations, arbitrary software artifacts can be considered: programs, specifications, data models, data, metamodels, object graphs, transformations (!), and others. Further, arbitrary relationships between the artifacts can be considered: conformance (e.g., between a model and a metamodel), consistency (e.g., between two models at the same level or different levels of abstraction), bidrectional transformations (BX; e.g., between primary database table and an updatable view), and others. Coupled software transformations define how changes of given artifacts are completed into co-changes of the remaining artifacts so that the intended relationships between all the artifacts are maintained.

[http://www.di.univaq.it/CSXW2011]

52


http://www.di.univaq.it/CSXW2011/page.php?page_id=15

http://www.di.univaq.it/CSXW2011


Coupled transformation of XMLware28 · Toward an engineering discipline for GRAMMARWARE

Transformation

XML dataXML dataTransformation

Input Output

doc. processor doc. processor

TransformationXML schema XML schema

Fig. 5. Multi-level transformations in the XML setting: The primary transformation is defined at the XMLschema level, while the transformations at the document-processing level (e.g., XSLT) and the XML-stream levelare supposed to be implied.

Some similar work has been reported on XML grammars [Lammel and Lohmann 2001;IBM Research 2002]. More generally, we view pairs of transformations on schema anddata as an important instance of the notion of “coupled transformation” [Lammel 2004a].

The derivation of a program transformation from a schema transformation is weakly un-derstood both in the XML context and the database context. However, object-oriented pro-gram refactoring [Griswold and Notkin 1993; Opdyke 1992] instantiates this sort of cou-pling, where class structures can be refactored and all dependent method implementationsare “automatically” updated. Clearly, evolutionary transformations can go beyond mererefactoring. In [Kort and Lammel 2003a], we consider coupled transformations for typesand functions in a functional program, while we even go beyond refactoring. Some formsof model transformations [Sendall and Kozaczynski 2003] (in the sense of the emergingfield of model-driven development) might be applicable in the grammarware context.

Evolution comprises refactoring, enhancement, as well as clean-up. In the broader sense,evolution also comprises re-targeting grammarware from one technology to another. Ba-sic grammar transformations for refactoring, enhancement, and clean-up were developedin [Lammel 2001a]. Evolutionary transformations of software have generally not yet re-ceived much attention, except for the refactoring mode of evolution. The situation is notdifferent for grammarware, but some initial ideas are summarised in [Lammel 1999b;2004b], where rule-based programs are transformed in a number of ways, including somegrammar-biased modifications, some of them going beyond refactoring.

6.5 Principle: reverse-engineer legacy grammarwareWe can not assume that suitable base-line grammars are readily available for all legacygrammarware. However, it is fair to assume that there is some encoded grammar knowl-edge available, from which base-line grammars can be recovered by means of reverse en-gineering. The grammar knowledge can reside in data, e.g., one can infer an XML schema

P. Klint, R

. Lämm

el, C. Verhoef: Tow

ard an

engineering discipline for GR

AM

MA

RWA

RE.

TOSEM

2005.

53






Program generation



Technical space travel ...

54




Relations

Objects

XML

55



O/X mapping (XML data binding)

<element name=“point"> <complexType> <sequence> <element name="x" type=“xs:int"/> <element name="y" type="xs:int"/> </sequence> </complexType> </element>

Maps to public class Point { public int x; public int y; }

Maps to

56



XML data binding with JAXB

Resource: http://www.oracle.com/technetwork/articles/javase/index-140168.html (SUN, Oracle)

57


http://www.oracle.com/technetwork/articles/javase/index-140168.html


Generator functionality for XML data binding

X-to-O mapping

tool

XML types

OO types

58



O/R mapping with EntityFramework

Resource: http://en.wikipedia.org/wiki/File:ANEF.PNG

59


http://en.wikipedia.org/wiki/File:ANEF.PNG


P. Klint and R. Lammel and C. Verhoef · 7

A fragment of a BNF grammar that defines the concrete syntax of a simple language.

[axiom] program ::= declarations statements

[decs] declarations ::= declaration “;” declarations

[nodec] declarations ::= ϵ

[dec] declaration ::= id “:” type

[concat] statements ::= statement “;” statements

[skip] statements ::= ϵ

[assign] statement ::= id “:=” expression

[var] expression ::= id

· · ·

A fragment of a DTD for the XML representation of the organisational structure in a company.<!DOCTYPE company [

<!ELEMENT company (dept*) ><!ELEMENT dept (name, manager, unit*) >

<!ATTLIST dept dept_num ID #REQUIRED ><!ELEMENT unit (employee | dept) ><!ELEMENT employee (person, salary) >

<!ATTLIST employee busunit IDREF #IMPLIED ><!ELEMENT person (name, address) > ... ]>

Some algebraic data types in Haskell notation for event traces of the execution of C programs.

data ExecProg = ExecProg [Either ExecStmt EvalExpr ]data ExecStmt = ExecStmt [Either ExecStmt EvalExpr ]data EvalExpr = EvalCall FuncCall

| EvalAssign Assign

| EvalOthers [EvalExpr ]data FuncCall = Call [EvalExpr ] [ExecStmt]data Assign = Assign [EvalExpr ] Desti

data Desti = · · ·

Fig. 1. Grammar samples: The syntax definition at the top is perhaps the most obvious example of a grammar.The XML DTD in the middle defines the abstract representation of a company’s organisational structure. It makesuse of specific XML features such as attributes and references. The signature at the bottom defines the structureof event traces for the execution of C programs. Here, we are specifically interested in tracing assignments andfunction calls.

2. AN INVENTORY OF GRAMMARWAREWe use the term grammar as an alias for structural descriptions in software systems, i.e.:

Grammar = structural description in software systems= description of structures used in software systems

Some representative examples of grammars are shown in Fig. 1. Whenever a softwarecomponent involves grammatical structure, then we attest a grammar dependency. (Wewill also say that the component commits to grammatical structure.) In this section, wewill first demarcate our use of the term “grammar”, i.e., “structural description”, and wewill then compile an inventory of grammar formalisms, grammar notations, grammar usecases, grammar-based formalisms and notations, and forms of grammar dependencies.

P. Klint, R. Lämmel, C. Verhoef: Toward an engineering

discipline for GRAMMARWARE.

TOSEM 2005.

Other kinds of technical space travel

60



Dragan Djuric, Dragan Gaševic, and Vladan Devedžic:

The Tao of Modeling Spaces, JOT 2006.

Modeling-centric view on technological spaces

61



Dragan Djuric, Dragan Gaševic, and Vladan Devedžic: The Tao of Modeling Spaces, JOT 2006.

Various spaces

62



Space travelDragan Djuric, Dragan Gaševic, and Vladan Devedžic:

The Tao of Modeling Spaces, JOT 2006.

63



Educational objectives (What to learn here?)

64



SLE skills

How to parse textual syntax? (How to parse visual syntax?) How to abstract from concrete syntax? How to check context conditions? How to perform semantic analysis? How to generate code? How to leverage intermediate languages?

65



More SLE skills

How to design languages? How to implement languages? How to embed languages? How to transform source code? How to generate source code? How to design transformation suites? How to map between abstraction levels?

66



Yet more SLE skills

How to design languageware? How to test it? How to assess it? How to evolve it?

Let’s see how much ground we can cover. This is just one course. Also, SLE is an emerging subject.

67



Skills -- overall?

Make the transition from a software engineer, overall, to a software language engineer, to do the right thing, whenever languages are involved. (They are involved all the time.)

68



30 · Toward an engineering discipline for GRAMMARWARE

Evolution

Evolution

Evolution Implementation

Implementation

Implementation

ImplementationEvolution

Recovery

Customisation

Testing

Testing

Testing

Testing

Evolution

Parser

Base−line

Rendered manual

schemaImport/export

specification

Visitor framework

Frontend

XML serialiser

Semi−structureddocument

class hierarchy

grammar

Customised

Fig. 6. The grammarware life cycle: Base-line grammars do not commit to a technology or a use case. The stackin the middle lists some grammar use cases, which are derived by customisation. Both base-line grammars andgrammar use cases can be subject to different sorts of evolution, while evolution of base-line grammars shouldbe preferred over evolution of grammar use cases, whenever possible. Grammar use cases can be implementedby meta-grammarware or by grammar-based programming techniques. The grammar life cycle is enabled bygrammar recovery, which recovers base-line grammars from implementations or others, if necessary.

6.7 The grammarware life cycleThe discussed principles can be integrated in a grammarware life cycle; see Fig. 6. Byhaving a proper grammarware life-cycle we can invigorate the normal software life-cycle.Most notably, the distinction of base-line grammars vs. grammar use cases allows us toapply evolutionary transformations to the former such that the adaptations of the latterare mostly implied. That is, grammar use cases are supposed to co-evolve with base-linegrammars. There are clearly evolution scenarios that are inherently technology- and use-case-specific, in which case evolutionary transformations must be carried out on grammaruse cases.

To align the grammarware life cycle with the normal software life cycle, we will brieflygo through Fig. 6. We will focus on forward engineering— knowing that we will neglectsome trips through the figure. There are the following phases:

—Provision of base-line grammars.—Customisation to derive grammar use cases.—Implementation to obtain actual grammar-dependent software.—(Potentially grammar-based) testing of the grammar-dependent software.

Here is one scenario for forward engineering from Fig. 6: going from a base-line grammarto an object-oriented visitor framework through a customised class hierarchy. The deriva-tion of the use case requires a class dictionary. (Hence, either the base-line grammar must

Grammarware lifecycle (as opposed to the software lifecycle)

P. Klint, R

. Lämm

el, C. Verhoef: Tow

ard an


AM

MA

RWA

RE.

TOSEM

2005.

69



22 · Toward an engineering discipline for GRAMMARWARE

Grammars incompiler front−ends

grammar dependencies

Perceived view "Lines of code" Proposed view "Impact ratio"

Grammars ina broad sense

Ingrained

All software assets

Fig. 4. In need of a paradigm shift: On the left-hand side, we only care about obvious grammar forms, namely theratio of “all software” to “grammars in compiler front-ends”. On the right-hand side, we admit two importantfacts: (i) there are many grammars other than those in compiler front-ends; (ii) ingrained grammar dependencieshave a deep impact on most software.

5. PROMISES OF GRAMMARWARE ENGINEERINGAt this point, the reader might face the following question:

Somehowwe managed to deal with all these kinds of grammarware for decades.So what? That is, what are the potential benefits for IT?

The overall promise of grammarware engineering is that it leads to improved quality ofgrammarware and to increased productivity of grammarware development. These promisesshould provide a good incentive since grammars permeate software systems and softwaredevelopment. Of course, it is difficult to justify such general claims at this time. To providesome concrete data, we will report on two showcases (or even success stories). Afterwards,we will identify more detailed promises on the basis of these showcases, but we will alsorefer to further scattered experiences with engineering aspects of grammarware.

5.1 Showcase: grammar recoveryThis showcase is discussed in detail in [Lammel and Verhoef 2001b; Lammel 2005]. Usingelements of the emerging engineering discipline for grammarware, we were able to rapidlyrecover a relatively correct and complete syntax definition of VS Cobol II. The startingpoint for this recovery project was IBM’s industrial standard for VS Cobol II [IBM Cor-poration 1993]. The syntax diagrams had to be extracted from the semi-formal document,and about 400 transformations were applied to the raw syntax in order to add missing con-structs, to fix errors, and to ultimately obtain a grammar that could be used for parsing.

P. Klint, R

. Lämm

el, C. Verhoef: Tow

ard an


AM

MA

RWA

RE.

TOSEM

2005.

70



Some SLE resources

71



SLEish books

72



SLEish events

78



http://wcre.wikidot.com/2013


http://wcre.wikidot.com/2013


SLEish papers

Read more here: http://github.com/slecourse/slecourse/blob/master/bibliography/bibliography.pdf?raw=true

84


http://github.com/slecourse/slecourse/blob/master/bibliography/bibliography.pdf?raw=true


Programming with Models? Modeling with Code. The Role of Models in Software Development An Extensive Catalog of Operators for the Coupled Evolution of Metamodels and Models

Guest Editors' Introduction to the Special Section on Software Language Engineering The API Field of Dreams - Too Much Stuff! It's Time to Reduce and Simplify APIs! Domain specific language implementation via compile-time meta-programming

The Impedance Imperative Tuples + Objects + Infosets = Too Much Stuff! Extending grammars and metamodels for reuse: the Reuseware approach

Controllable Combinatorial Coverage in Grammar-Based Testing Semantics First! - Rethinking the Language Design Process

SugarJ: library-based syntactic language extensibility Toward an engineering discipline for grammarware

Using production grammars in software testing Automated Co-evolution of GMF Editor Models Embedding Languages without Breaking Tools Engineering a DSL for Software Traceability

A Case Study in Grammar Engineering Safe Composition of Transformations

Why Software Language Engineering?85

Extracted from a SLE bibliography



SLEish technologies

86



ATL

Rascal

EMF

GMF

JastAd

d

TXL

Stratego/XT

SugarJXtextRecoder

ASM

JDK

Technologies with focus on language implementation or language services

87



This SLE course: content / structure

88



Lecture (Historical data)

89



Lab (Historical data)

90



Assignments (Historical data)

91



Exam rules (Historical data)

92



Hidden agenda

Most of you enjoy and finish the exam.

Some of you fall in love with SLE.

Few of you co-submit to SLE 20??.

All of us have fun.


This is it! This is the course!

(for language engineers)

93




Thanks! Questions? Comments?

94


course software language engineering - uni koblenz-landaulaemmel/slecourse/slides/intro.pdf ·...

Documents