Course "Programming techniques and technologies" SS 2015


  • Lecturer: Prof. Ralf Lämmel <ed.znelbok-inu|lemmeal#ed.znelbok-inu|lemmeal>
  • Lab assistant: Marcel Heinz <ed.znelbok-inu|znieh#ed.znelbok-inu|znieh>
  • Project assistants:
    • André Kramer <ed.znelbok-inu|remarka#ed.znelbok-inu|remarka>
    • Maximilian Meffert <ed.znelbok-inu|treffemxam#ed.znelbok-inu|treffemxam>
    • Michael Monschau <ed.znelbok-inu|uahcsnomm#ed.znelbok-inu|uahcsnomm>
  • 101wiki assistant: Kevin Klein <ed.znelbok-inu|nielkk#ed.znelbok-inu|nielkk>


The course covers the following topics. Note that there is no strict 1:1 mapping from lectures to topics.

  1. Design patterns: There are recurring problems in designing software systems that come with established patterns of solution. For instance, we discuss the folklore Expression Problem and how the Visitor Pattern solves part of the problem. Elsewhere we discuss how MVC and the Observer Pattern help in designing modular, interactive, possibly web-based applications. The treatment of design patterns crosscuts the course.
  2. Data programmability: Much of the data in today's software systems resides in or is exchanged through XML, JSON, relational databases, and NoSQL databases. One major path for accessing such data programmatically is through APIs that materialize or parse such data and provide methods of querying and transformation. We discuss a few such APIs and the underlying principles and the relevant data paradigms.
  3. Technological spaces: Software development is carried out in different, not completely disconnected technological spaces. For instance, a major part of an information system may reside in the space of objectware, whereas its data management layer may reside in the space of SQLware and its end-user client may reside in the space of HTML5ware. We discuss a few aspects of 'technological space travel', e.g., object/relational mapping or XML data binding.
  4. Technology modeling: There are so many technologies and languages; there is so little time. Abstraction is needed to deal with the ever-increasing number of technologies in a scalable manner so that one can acquire competencies for new technologies rapidly and compare technologies in a systematic manner. We discuss a designated modeling approach, in fact, a modeling language MegaL for technologies to this end, which we apply to a number of technologies encountered elsewhere in the course, e.g., technologies for parsing and XML-data binding.
  5. Multi-paradigm Programming: Several popular languages are multi-paradigm languages; they cover imperative, object-oriented, functional, and concurrent programming concepts; they incorporate ideas from scripting and compilation; they have a non-classic type system. For instance, we discuss Scala which is a language somewhat close to Java at first sight while providing powerful concepts of functional, modular and concurrent programming. We also discuss AspectJ as an aspect-oriented programming language providing thus advanced modular programming concepts.
  6. Concurrency: Software systems often involve concurrency such that multiple processes execute in parallel and some synchronization or communication between these processes needs to be carefully organized for the correct behavior of the complete system. We discuss some forms of concurrent programming, e.g., threads with synchronization as in Java and message-based concurrency à la akka in Scala.
  7. Distribution and services: Software systems often involve distribution such that functionality and data resides on multiple machines possibly in different locations. For instance, a web application or a mobile app are likely to be decomposed into client and server and may access additional services. We discuss several methods or patterns of distribution and services, e.g., RMI, asynchronous requests, REST, SOA, and Web Services. We also discuss distribution related to data parallelism as with MapReduce (e.g., with Hadoop).
  8. Language processing: Software development often involves domain-specific languages, software analysis, software transformation, and generation. All these aspects require at least basic competencies of language processing such as modeling abstract syntax, parsing concrete syntax, and template-based code generation. We pick concrete technologies such as EMF, ANTLR, and StringTemplate to cover these aspects. In this context, we also discuss reflection, preprocessing, and bytecode engineering.
  9. Web application development: Several aspects thereof are covered already by topics listed above, e.g., issues of distribution (REST and asynchronous requests), data programmability, or template processing. We discuss the comprehensive architecture of web applications while picking specific frameworks or platforms such as HTML5 and Django. We cover the major aspects of web applications; this includes user interfaces (e.g., CSS) and authentication (e.g., OAuth).
  10. App development: Several aspects thereof are covered already by topics listed above. We discuss particularities of mobile apps such as API-based access to device capabilities (SMS, Email, sensors, gallery, etc.), permissions, cloud-based versus session-based versus device-based data. The course does not convey comprehensive programming skills for any specific app platform, but the underlying principles are characterized and demonstrated. For instance, we use TouchDevelop for some experiments without spending much time on the relatively complex platforms Android SDK or Xcode.


Slides and other material is published before or shortly after each lecture slot.

See here for a continuously evolving slide collection.

23.04.2015: The Expression Problem (.pdf)
30.04.2015: Data programmability (.pdf)
07.05.2015: Services (.pdf)
21.05.2015: O/R/X et al. mapping (.pdf)
11.06.2015: Technology modeling (.pdf)
18.06.2015: Technology modeling cont'd
25.06.2015: Concurrency (.pdf)
02.07.2015: Language processing (.pdf)
09.07.2015: Web-application frameworks (.pdf)
16.07.2015: Metaprogramming (.pdf)
23.07.2015: Final


Date Topic
27.04./28.04. Kickoff (Git, Visitor Pattern, Observer Pattern, project brainstorming)
11.05./12.05. Scrum = discussion/brainstorming on selected proposals (no slides required)
18.05./19.05. Distributed programming / Authentication
01.06./02.06. O/X/R/J Mapping, 101companies demos
08.06./09.06. Server component presentations
15.06./16.06. Technology Model briefing and Q&A
22.06./23.06. Technology Model Scrum
29.06./30.06. Messaging based Concurrency
06.07./07.07. Pretty printing and templates
13.07./14.07. MVC,Composite and exam preparation I.)
20.07./21.07. Exam preparation II.)

"Regular labs" discuss the project progress and repeat the lectures' content.
All material is uploaded at public folder.


Rather than using multiple assignments, the idea is that small teams of 1-3 students carry out a project with multiple milestones to build systems that exercise the topics of the course and meet some other requirements. Overall, each such system would be an interactive web-based system (possibly a mobile app) that also relies on a designated server and makes use of of some existing service for weather forecast data or what have you.


Teams are assembled by the students themselves.

Teams can be of size 1-3.

Teams of size 2 get a brownie point.


Each team creates a private git repo with To this end, a team member should create a gitlab group and one project in that group. Each team adds all teaching staff to the repo with read and write permission: ed.znelbok-inu|lemmeal#ed.znelbok-inu|lemmeal, ed.znelbok-inu|znieh#ed.znelbok-inu|znieh, ed.znelbok-inu|uahcsnomm#ed.znelbok-inu|uahcsnomm, ed.znelbok-inu|treffemxam#ed.znelbok-inu|treffemxam, ed.znelbok-inu|remarka#ed.znelbok-inu|remarka. By adding the teaching staff like this, they will be automatically notified of the repo.

The repo must hold all source code and other artifacts for all milestones.

The "implicit" team name is the composition of gitlab group name + gitlab project name.

Project proposal

The project proposal is submitted as or README.txt to the repo.

The proposal must contain data as follows:

  • Title of project (e.g., "The glorious chatting network")
  • Short description of system's objective (50-100 words)
  • Programming languages used
  • Technologies (frameworks, libraries, etc.) used
  • Identify the role of each language and technology used
  • Explain how each requirement (see below) will be addressed
  • Availability (yes/no) for lab slot Mondays 14:15-15:45
  • Availability (yes/no) for lab slot Tuesdays 10:15-11:45

It is Ok that some of the requirements may not yet be clear to everyone at the beginning of the project.

It is Ok to select other languages and technologies later, if approved by teaching staff.


Summary: Build an interactive web-based system (possibly a mobile app) that also relies on a designated server and makes use of of some existing service for weather forecast data or what have you.

Requirements related to topics of the course

  • Design patterns: Clearly, you will use design patterns; pick at least one that goes beyond the more obvious ones from this list: MVC, Observer, Composite, Visitor.
  • Data programmability: Integrate some existing web-based service that has, for example, a REST-based access protocol and where data exchange leverages JSON or XML.
  • Technological spaces: At least in one component of your project, maps JSON or XML into domain-specific objects, preferably by reusing some existing mapping technology.
  • Technological modeling: At some later point in time, each team shall pick some technology which to model. The technology should be used in the project by the team. The selection of technologies across teams will be supervised.
  • Multi-paradigm programming: Put to use multiple paradigms. You will need to describe exactly what you did and why this was a good choice.
  • Concurrency: your project admits multiple clients to access the server concurrently. The system needs to be complex enough that synchronization issues could arise and you need to solve them. For instance, activities by one client could affect the view of another client.
  • Distribution and services: The system is necessarily distributed in that there is a server and a web-based client (or a mobile client, if you prefer that). As noted under “Data programmability”, the system also uses an extra service.
  • Language processing: The system should provide a search function that can be controlled both through a classical user interface with text and selection boxes as well as through a micro DSL for which you implement a tiny parser. In addition, your web-based client is likely to use template processing.
  • Web application / app development: As noted earlier, your project implements a web-based app or possibly even a system with a native mobile devices client.

Other requirements

  • An existing Web application framework must be used; no “free style”.
  • No "design exorcism": Don't use patterns for patterns' sake.
  • No "technology exorcism": Don't use overloaded technology combos.
  • Simplicity over complexity: Strive for neat and light systems meeting the requirements.
  • Team members must be active in the respective repositories.


Deadlines are 3am, Koblenz Timezone (so that things can be discussed in the Monday meetings).

  • 04.05.2015: Milestone 1: submission project proposals
  • 11.05.2015: Milestone 2: scrum
  • 08.06.2015: Milestone 3: server component
  • 22.06.2015: Milestone 4: technology model
  • 13.07.2015: Milestone 5: client component

Feedback by the project assistants are provided no later than 1 week after said deadline.


Exam dates

  • Final: 23 July 2015 (last lecture slot : 12:15 - 13:45 in D028)
  • Resit: during next semester

Exam admission rules

  • Admission for 2014, 2013, 2012, 2011, 2010 is inherited to 2015.
  • Students need to successfully complete the project.
    • Teams must meet all deadlines and adhere to all constraints.
    • Teams must be able to present their results for the milestones, when asked to do so.
    • Presentations and project milestones and final project must be positively evaluated.
    • Each team member's contribution must be clearly visible.
  • Students need to register for the exam via KLIPS.