: Programmieren Können ist eine Kernkompetenz für Informatiker*innen. Um gut Program-mieren zu können, ist sehr viel Programmieren Üben notwendig. Es gibt etliche Online-Plattformen, auf denen Programmieraufgaben zum Üben zur Verfügung gestellt werden. Ein Problem für Lernende auf diesen Plattformen ist häufig, die zum eigenen Lernfortschritt passenden Aufgaben zu finden. Wir stellen eine neue Plattform mit einem klaren Fokus auf das Programmieren Üben vor und beschreiben ihre flexible Architektur.

Programming is solving problems with computer assistance. Learning the craft of programming is a challenging task for most computer science students. It requires a high amount of training to get into the mindset of a good software engineer, and many students lack this training. A promising way to compensate this lack is the provision of an easily accessible learning platform where students can find several programming assignments that are fun to solve, ideally on the platform itself. In this paper, we present the architecture of an online programming practice platform that provides a fully featured online IDE, running in any modern browser and offering fast feedback on provided solutions. It is deployed in a scalable state-of-the-art cloud-infrastructure based on a microservice architecture to ensure a stable and extensible software system.

Programmieren ist das Handwerkszeug der Softwa‐ retechnik (Ludewig, 2010), die Programmierlehre bildet somit das Rückgrat jedes Informatikstudiums. Trotz dieses Stellenwertes wird dem Thema Pro‐ grammieren traditionell auf Konferenzen zum Thema Software Engineering wenig Aufmerksam‐ keit geschenkt. Auf den SEUH‐Tagungen der letzten 10 Jahre hat sich dies etwas verbessert, indem zu‐ nehmend auch Programmierthemen diskutiert wur‐ den (Heuer et al., 2011; Langhoff et al., 2015; Schmedding et al., 2015). Dennoch haftet der grund‐ ständigen Programmierlehre häufig der Ruch des hemdsärmeligen, wenig wissenschaftlichen und teilweise sogar trivialen Anteils des Informatik‐Stu‐ diums an. Um dem bewusst entgegen zu wirken, wird in diesem Beitrag nicht mehr der Begriff Pro‐ grammierausbildung benutzt, wie in früheren Arti‐ keln (Schmolitzky, Züllighoven, 2007; Schmolitzky, 2013), sondern der passendere Begriff Programmier‐ lehre. Das Thema Programmierlehre befindet sich stär‐ ker im Fluss, als dies von vielen vermutet wird. Pro‐ grammieren ist eine Kunst, entsprechend ist auch die Programmierlehre eine Kunst, die wir bei wei‐ tem noch nicht so gut beherrschen, wie es der Wich‐ tigkeit der Disziplin angemessen wäre. Nach wie vor wissen wir zu wenig darüber, wie eine angemes‐ sene Programmierlehre aussehen sollte. Der Autor hat als ersten Schritt einer Klärung nach der SEUH 2013 die Teilnehmer der Tagung zur Teilnahme an einer Erhebung aufgefordert, in der der aktuelle Stand der Programmierlehre an deutschsprachigen Hochschulen ermittelt werden sollte. Die Randbedingungen und Ergebnisse dieser Umfrage werden im nächsten Abschnitt präsentiert. Abschnitt 3 stellt anhand konkreter Zahlen ei‐ gene Erfahrungswerte in der Programmierlehre des Autors zur Diskussion und Abschnitt 4 diskutiert weitere Aspekte, die dem Autor in Bezug auf Pro‐ grammierlehre wichtig erscheinen.

This paper describes a software-engineering problem, proposes a solution and shows how that solution influences language design. In many object-oriented programming languages, when implementing equality the programmer has to make sure that it obeys a set of rules, called equality contract. Not only is it difficult to adhere to these seemingly simple rules, but the equality contract itself is a source of potential errors. Even if equality complies with the contract, it can lead to faulty, unintended, indeterministic program behavior. This paper proposes a modified contract that avoids these problems. Additionally, the modified contract describes equality unambiguously, and it implies that equality for values and identity for objects can be regarded as the very same concept. Based on the modified contract the language design can be enhanced in a way that supports value equality and object identity more clearly and more safely.

Introductory programming education following the Objects First approach introduces the concepts of object-oriented programming early on. Objects with state (fields) and behavior (methods) that offer services to their clients (via their public interface) and hide the way these services are implemented (in their implementation) are the building blocks of any larger object system. These basic properties of objects are so crucial for understanding object-oriented programming (and later on object-oriented design) that diverse approaches to teaching them should be offered. In this paper we introduce Guess My Object (GMO) as a new approach to getting in contact with objects early that can complement existing teaching approaches. In essence, GMO is a way of using BlueJ for an interactive round-based game, each consisting of two stages, behavior exploration and behavior implementation.

Eine solide Programmierausbildung bildet die Grundlage jeder softwaretechnischen Ausbildung. Art und Umfang der Programmierausbildung konnen jedoch sehr unterschiedlich sein, je nach Schwerpunkt des jeweiligen Studiengangs. In diesem Artikel werden auf verschiedenen Ebenen Alternativen diskutiert, die fur die Gestaltung der einfuhrenden Programmierausbildung bestehen, und mit den Anforderungen abgeglichen, die sich bei einer Schwerpunktsetzung auf die Softwaretechnik ergeben.

Access modifiers allow Java developers to define package and class interfaces tailored for different groups of clients. According to the principles of information hiding and encapsulation, the accessibility of types, methods, and fields should be as restrictive as possible. However, in programming practice, the potential of the given possibilities seems not always be fully exploited. Access Analysis is a plug-in for the Eclipse IDE that measures the usage of access modifiers for types and methods in Java. It calculates two metrics, Inappropriate Generosity with Accessibility of Types (IGAT) and Inappropriate Generosity with Accessibility of Methods (IGAM), which represent the degree of deviation between actual and necessary access modifiers. As an approximation for the necessary access modifier, we introduce the notion of minimal access modifiers. The minimal access modifier is the most restrictive access modifier that allows all existing references to a type or method in the entire source code of a system. Access Analysis determines minimal access modifiers by static source code analysis using the build-in Java DOM/AST API of Eclipse.

Every element of a software architecture, e.g. a subsystem, package, or class, should have a well-defined interface that exposes or hides its sub elements according to the principles of information hiding and encapsulation. Similar to other object-oriented programming languages, Java supports defining interfaces on several levels. The accessibility of types, methods, and fields can be restricted by using access modifiers. With these modifiers, developers are able to define interfaces of packages and classes tailored for different groups of clients. However, in programming practice, types and members seem to be often declared with too generous access modifiers, i.e. they are accessible by more clients than necessary. This can lead to unwanted dependencies and software quality degradation. We developed an approach to measuring the usage of access modifiers for types and methods in Java by defining two new software metrics: Inappropriate Generosity with Accessibility of Types (IGAT) and Inappropriate Generosity with Accessibility of Methods (IGAM). Furthermore, we created a tool called Access Analysis that calculates and displays these metrics. Using Access Analysis, we conducted a survey on twelve open source Java projects. The results support our assumption that access modifiers are often chosen more generously than necessary. On average, around one third of all type and method access modifiers fall into this category. Especially top-level types are almost always declared as public, so that package interfaces typically expose more types than necessary. Only 2% of all investigated top-level types are encapsulated inside their package.

Konsumieren und Produzieren sind zwei Seiten derselben Medaille. Wir untersuchen seit einigen Jahren die Metapher vom Konsumieren und Produzieren (kurz: K&P-Metapher) im Umfeld der Lehre objektorientierter Programmierung. In diesem Artikel stellen wir eine Erweiterung der fur die Lehre der objektorientierten Programmierung entwickelten Entwicklungsumgebung BlueJ vor. Diese Erweiterung fuhrt die bereits in BlueJ implizit vorhandene Unterstutzung der K&P-Metapher konsequent fort, indem sie auch im BlueJ-Klassendiagramm dynamisch die Unterscheidung zwischen dem Konsumieren und dem Produzieren einer Klasse ermoglicht.

Wie viele objektorientierte Programmiersprachen bietet Java die Moglichkeit, uber Modifikatoren die Zugreifbarkeit von Typen, Methoden und Feldern in mehreren Stufen einzuschranken. So konnen fur unterschiedliche Gruppen von Klienten differenzierte Schnittstellen definiert werden. Es zeigt sich jedoch, dass in der Praxis die gebotenen Moglichkeiten nicht voll ausgeschopft werden. Wir beschreiben zwei neue Metriken, mit denen sich der angemessene Umgang mit Zugriffsmodifikatoren in Java messen lasst, sowie ein Werkzeug, das diese Metriken berechnet und beim Einschranken von Schnittstellen hilfreich sein kann. Wir haben unseren Ansatz in zwei kommerziellen Projekten und zwolf Open-Source-Projekten erprobt. Dabei wurde deutlich, dass Zugriffsmodifikatoren oft groszugiger gewahlt werden als notwendig.

In der objektorientierten Modellierung von Anwendungssystemen werden Werte und Objekte häufig als unterschiedliche Abstraktionen aufgefasst. Durch die im softwaretechnischen Umfeld dominierenden objektorientierten Programmiersprachen fällt die Abbildung von Objekten eines Anwendungsbereichs auf Objektklassen dieser Sprachen inhärent leicht, während wertartige Abstraktionen umständlich repräsentiert werden müssen. Eine Programmiersprache, die neben Objekttypen auch Werttypen durch explizite Mechanismen unterstützt, könnte Abstraktionen, die konzeptionell als Werte einzustufen sind, klarer, knapper und sicherer abbilden. In diesem Artikel geben wir eine Definition von Werttypen und diskutieren, welchen Anforderungen eine Sprache genügen sollte, die dieses Konzept von Werttypen geeignet unterstützt.

Feedback is an important value in agile methodologies. It is also essential for any context where people are learning. Typically the focus is on giving learners feedback on their learning progress, either from an educator’s point of view or between the learners via peer feedback. This paper focuses on gaining feedback from learners. We discuss methods and good practices for encouraging learners to switch their perspective from a recipient of facts to a critical observer of material produced by peer students and educators. This is essential both for educators (as a way to learn more about their own teaching) and for students (to be able to express opinions and give constructive feedback).

Thesis projects are a challenging task for students as well as their supervisors. In most cases, students have not managed such large projects before. Many supervisors are good researchers, but have not received training in pedagogy and project management. This means that students as well as supervisors often lack best practices in managing thesis projects. This paper fills this gap by providing a set of best practices for the supervisor that may help to better structure and focus the collaboration between student and supervisor so that the thesis runs smoothly, thus enabling students to succeed.

Class-based object-oriented languages traditionally fuse the notions of type and implementation in the class construct. Software engineering methods, on the other hand, clearly separate type specifications from their possible implementations. In connection with inheritance the fusion of types and implementations results in either subtyping problems or restricted code reuse and forces type abstraction to be modelled with inheritance. Java has taken a step in the direction of supporting type abstraction by providing 'interface types' and an explicit 'implements' relation. In this paper we propose a more radical model for programming languages: classes never define types and interfaces, called type definitions, are the only entities valid for typing. We identify problems and restrictions in existing languages and discuss the realisation of the model in a new Java-based language. We introduce the concept of late implementation binding via implementation pragmas. We identify a number of problems in Theta, a language with similar aims.

Objektorientierte Programmiersprachen (OOPS) sind traditionell stark bei der Definition benutzerdefinierter Objekttypen. Fur benutzerdefinierte Werttypen hingegen bieten sie wenig Unterstutzung. Fachlich motivierte, vom Entwickler zu definierende Werttypen (Fachwerte) spielen jedoch eine wichtige Rolle in Softwareprojekten [Zul04], siehe auch die explizite Darstellung des Value-Object-Patterns bei Fowler [Fow02].

Kaum ein Thema ist so umstritten wie der richtige Weg bei der grundstandigen Programmierausbildung. Dieser Beitrag beschreibt einen neuen Ansatz zur Einfuhrung in die Softwareentwicklung, der in den letzten Jahren im Arbeitsbereich Softwaretechnik an der Universitat Hamburg entwickelt wurde. Er orientiert sich an einem Objects First-Ansatz, macht aber gleichzeitig einen Einstieg in klassische Themen wie Algorithmen und Datenstrukturen fruher als allgemein ublich und geht einen ungewohnlichen Weg bei der Vermittlung von Interfaces und Vererbungskonzepten.

This paper presents pedagogical patterns for the general context of teaching software concepts in classroom settings. These patterns are targeted at people who teach other people, whether in industry or at universities. The patterns are presented in Alexandrian Form, in conformance with the patterns of the Pedagogical Patterns Project. Four pedagogical patterns have been identified: SHOW IT RUNNING, SHOW PROGRAMMING, MAKE IT THEIR PROBLEM and MAKE THEM MAKE IT THEIR PROBLEM.