Small and medium sized businesses within mechanical manufacturing cannot benefit from Industry 4.0 automation as small production batches are unable to pay for up-front robotic configuration and programming costs.In this paper, we report on early results from a project aiming at developing a software architecture supporting fast, easy, and flexible reconfiguration of a robotic manufacturing process, using an agile and prototyping approach.

DevOps is a new way of developing software that is challenging from a teaching perspective. In this paper, we outline these challenges and propose teaching methods that focus on skill acquisition and technical practices that focus on performant virtualization to overcome them. We describe central elements from our course Cloud Computing and Architecture that has been designed and executed upon these methods and practices and report our experiences and lessons learned.

During the last four years, Mjølner Informatics has developed mobile banking apps for 11 Danish banks on the two major platforms iOS and Android, in total 22 apps. We make two contributions with this industrial practice paper. In the first place, we describe the development of these apps with emphasis on issues regarding variability handling and maximizing reuse. Secondly, we discuss a number of lessons learned from this process. This includes consideration of how ready we are to possible future challenges regarding variability and observation of significant differences between the two platforms.

Telemedicine, the provision of health care at a distance, is arguably an effective way of increasing access to, reducing cost of, and improving quality of care. However, the deployment of telemedicine is faced with standards that are hard to use, application-specific data models, and application stove-pipes that inhibit the adoption of telemedical solutions. To which extent can a software ecosystem approach to telemedicine alleviate this? In this article, we define the concept of software ecosystem architecture as the structure(s) of a software ecosystem comprising elements, relations among them, and properties of both. Our objective is to show how this concept can be used (i) in the analysis of existing software ecosystems and (ii) in the design of new software ecosystems. We performed a mixed-method study that consisted of a case study and an experiment. For (i), we performed a descriptive, revelatory case study of the Danish telemedicine ecosystem and for (ii), we experimentally designed, implemented, and evaluated the architecture of 4S. We contribute in three areas. First, we define the software ecosystem architecture concept that captures organization, business, and software aspects of software ecosystems. Secondly, we apply this concept in our case study and demonstrate that it is a viable concept for software ecosystem analysis. Finally, based on our experiments, we discuss the practice of software engineering for software ecosystems drawn from experience in creating and evolving the 4S telemedicine ecosystem. The concept of software ecosystem architecture can be used analytically and constructively in respectively the analysis and design of software ecosystems.

Traditional lecture-based courses are widely criticized for being less effective in teaching. The question is of course what should replace the lectures and various active learning techniques have been suggested and studied. In this paper, we report on our experiences of redesigning a software engineering course in software architecture to employ a range of active learning techniques. The course was constrained by the study administration's traditional assignment of a three hour lecturing slot and as such we had to make techniques that fitted this imposed constraint. Our contribution is active seminars as a replacement of traditional lectures, an activity template for the contents of active seminars, an account on how storytelling supported the seminars, as well as reports on our and the students' experiences.

Agile development methods favor speed and feature producing iterations. Software architecture, on the other hand, is ripe with techniques that are slow and not oriented directly towards implementation of costumers' needs. Thus, there is a major challenge in retaining architectural information in a fast-faced agile project. We propose to embed as much architectural information as possible in the central artefact of the agile universe, the code. We argue that thereby valuable architectural information is retained for (automatic) documentation, validation, and further analysis, based on a relatively small investment of effort. We outline some preliminary examples of architectural annotations in Java and Python and their applicability in practice.

When designing for a group of professionals, it is important to know their work practice. This is well-known and practised, e.g., in agile software development in which customers are involved in development work, but less so when the professionals are software engineers or in particular software architects. In the SA@Work project, we have extensively studied software architect work at four Danish companies using both qualitative and quantitative approaches. In this paper, we report on concerns (analysis, design, evaluation, realization, management, and interaction) that software architects have in their work. Our lessons learnt are software architecture work (in the setting that we studied) is as much about non-technical as technical work, that architecture is often found "in the small" and that architects vary widely in type. Furthermore, we point to lessons for future research and development of software architecture techniques.

Advanced programming and software engineering techniques are challenging to learn due to their inherent complexity. However, to the average student they are even more challenging because they have never experienced the context in which the techniques are appropriate. For instance, why learn design patterns to increase maintainability when student exercises are never maintained? In this paper, we outline the contextual problems that software engineering teaching has to deal with and present a story telling approach for course design as a remedy. We outline the stories that over the last five years have structured lecturing and mandatory exercises for our advanced programming/software engineering course, and present benefits, liabilities, and experiences with the approach comparing it to the normal, topic structured, course design.

Designing and maintaining a software architecture that strikes the right balance between conflicting quality attributes is a daunting task facing every software architect. In the SA@Work project we have conducted ethnographical field studies of practicing software architects in four Danish software companies to study architectural work in general and architectural techniques in particular. In this paper, we describe observed techniques related to architectural quality as input to the architectural body of knowledge. Second, these techniques are classified according to the quality view classification framework of Garvin. Our analysis shows that techniques for assessing and ensuring quality in software architecture predominately view quality as an intrinsic quality of the architecture itself and less view it as related to business and users. This hints at a need to extend the architectpsilas toolbox and may explain observed mismatches between architectural work and agile processes.

Example programs play an important role in learning to program. They work as templates, guidelines, and inspiration for learners when developing their own programs. It is therefore important to provide learners with high quality examples. In this paper, we discuss properties of example programs that might affect the teaching and learning of object-oriented programming. Furthermore, we present an evaluation instrument for example programs and report on initial experiences of its application to a selection of examples from popular introductory programming textbooks.

Software architecture practice is highly complex. Software architects interact with business as well as technical aspects of systems, often embedded in large and changing organizations. We first make an argument that an appropriate research agenda for understanding, describing, and changing architectural practice in this context is based on an action research agenda in which researchers use ethnographic techniques to understand practice and engages directly with and in practice when proposing and designing new practices. Secondly, we present an overview of an ongoing project which applies action research techniques to understand and potentially change architectural practice in four Danish software companies.

There are an increasing number of books published on the important topics of "object-oriented programming" and "object-oriented design" for use in education. However, object-orientation can be viewed from a number of different perspectives---each perspective having its benefits and liabilities. A perspective has a strong influence on the kind of designs students can and will produce, the kind of domains that are easy or difficult to analyze, and the kind of frame of reference in which design techniques are understood and applied. In this paper we argue that most books make an implicit choice of perspective with the unfortunate effect that our students leave our courses with limited design abilities. We present a coarse-grained classification, discuss implications of perspective in a teaching context, and illustrate consequences using a small case study. Our main point is that teachers should be aware of the different perspectives, and that all perspectives are important for students to achieve high quality designs.

In the short time span available in a software architecture course, it is difficult to find a software system that is both interesting from an architectural perspective and so small that it does not overwhelm the students.We present TS-05 which is a bare 150 line Java "toy-system" that never-the-less exhibits architectural complexity and challenges that emphasize the usefulness of architectural concepts, primarily views, quality attributes and connectors.

We use a case study in architectural prototyping as input for presenting a first, tentative, framework describing key concepts and their relationships in architectural prototyping processes.

Design patterns have made a strong impact on how object-oriented software is designed, implemented, and communicated in industrial projects. Teaching patterns is therefore of great importance. Patterns, however, have a natural catalogue-like nature, that easily misleads us into to lecturing them one at a time. This leaves an impression of patterns as isolated solutions to independent problems. We present our experience with trying to counteract this problem by using a well-engineered framework, JHotDraw, as a case study in how patterns work together to define a flexible and compositional software system of high quality.

With the growing research into mobile and ubiquitous computing, there is a need for addressing how such infrastructures can support collaboration between nomadic users. We present the activity based computing paradigm and outline a proposal for handling collaboration in an activity-based architecture. We argue that activity-based computing establishes a natural and sound conceptual and architectural basis for session management in real-time, synchronous collaboration.

A major part of software architecture design is learning how specific architectural designs balance the concerns of stakeholders. We explore the notion of "architectural prototypes", correspondingly architectural prototyping, as a means of using executable prototypes to investigate stakeholders' concerns with respect to a system under development. An architectural prototype is primarily a learning and communication vehicle used to explore and experiment with alternative architectural styles, features, and patterns in order to balance different architectural qualities. The use of architectural prototypes in the development process is discussed, and we argue that such prototypes can play a role throughout the entire process. The use of architectural prototypes is illustrated by three distinct cases of creating software systems. We argue that architectural prototyping can provide key insights that may otherwise be difficult to obtain before a system is built. Furthermore, they define skeleton systems that serve as communication means and knowledge transfer among stakeholders.

In this paper we argue that treating "testing" as an isolated topic is a wrong approach in computer science and software engineering teaching. Instead testing should pervade practical topics and exercises in the computer science curriculum to teach students the importance of producing software of high quality. We point out that we, as teachers, are partly to blame that many software products are of low quality. We describe a set of teaching guidelines that conveys our main pedagogical point to the students: that systematic testing is important, rewarding, and fun, and that testing should be an integrated part of any software development process.

In this paper we argue that introducing object-oriented frameworks as subject already in the CS1 curriculum is important if we are to train the programmers of tomorrow to become just as much software reusers as software producers. We present a simple, graphical, framework that we have successfully used to introduce the principles of object-oriented frameworks to students at the introductory programming level. Our framework, while simple, introduces central abstractions such as inversion of control, event-driven programming, and variability points/hot-spots. This has provided a good starting point for introducing graphical user interface frameworks such as Java Swing and AWT as the students are not overwhelmed by all the details of such frameworks right away but given a conceptual road-map and practical experience that allow them to cope with the complexity.

This experience paper presents observations, lessons learned, and recommendations based on a case study of reuse. The case study is concerned with the development, maturation, and reuse of a business domain independent software component (horizontal reuse) in a project-driven organisation that has little previous experience with systematic software reuse. The main lessons learned are that: even though domain analysis can alleviate reuse mismatch problems one should not underestimate the technical problems that may arise when reusing; a side-effect of reuse is that software engineering knowledge is transferred within an organisation; design patterns can be as risky as they can be beneficial; and there is more to architectural mismatch than "merely" packaging mismatch.