Welcome to the Software Architecture (dSoftArk) course

The course will be taught by Henrik Bærbak Christensen.


The dSoftArk course covers techniques in software engineering and architecture that are in daily use in industry to produce flexible and reliable software.

The course has a primary and secondary focus:

Key techniques are: Test-driven development, compositional design, test doubles, design patterns, frameworks, and systematic black-box testing techniques.

Also dSoftArk's mandatory project requires you to utilize modern tools that are widely used in industrial practice, defaulting to Ant, IntelliJ, and Git.

dSoftArk in particular extends knowledge and skills you have acquired in dIntProg and dProg2.


dSoftArk is rooted in a software engineering tradition rather than a (mathematical) computer science tradition. Thus - no QEDs - sorry to you folks who like knowledge that is provably true :(. In contrast, the techniques in dSoftArk are justified by empirical means: they have shown that they work in industrial practice so many times that we tend to believe they are valid.


There are 2+2 lectures every week. The two lectures Thursday and first lecture Monday are presenting new material (curriculum) while the last lecture Monday is dedicated to going over aspects of the mandatory project (reflections/no new stuff introduced).


There are 3 hours laboratory workshops every week for the classes. They are called "TØ" by the scheduling people, but in dSoftArk they are by no means 'theoretical'. In the lab the teaching assistent will discuss issues and assignments from the mandatory project, as well as act as consultant on your work.

Study Cafe / The Java Cave

TAs or I will hang around in the Ada Cellar and helping you out in the study cafe. The time we are there are:

Mandag 16-17, tirsdag 9-10, onsdag 14-15, torsdag 16-17 og fredag 14-15

Mandatory Project

Isolated exercises are (to a large extend) replaced by a single, large, project that you are going to develop in groups in an agile and test-driven development process. Each week there will be an assigment, a sprint, that adds features (and academic reflections) to the project.

The group will hand in the result using your Blackboard login, and will be reviewed and accepted/rejected by the teaching assistent.

Mandatory Project Award Structure

The mandatory project will be HotCiv which is a boiled down Civilization game. However, the focus is not on getting all the proper functionality in place---the focus is on getting the proper architecture in place to handle a lot of variable game behaviour.

Thus you will be awarded for proper flexible and reliable designs that however may skip some functional requirements.

And you will NOT be awarded for a fully functional game with an inflexible and unreliable architecture

Mandatory project process

Your process is important. The best configuration is a three person group that do same-time, same-location work in three roles:

Take turns of about one half hour - then change roles so you all get experience in all roles!!!

In a two person group, one person must take on the last two roles.

Mandatory project deadline

Generally, as each week's work span several exercises to be handed in separately, I strongly advice handing in as soon as you have "clean code that works", so you can get feedback quickly.

For the ultimate deadlines for each week and for each class, see the delivery plan.

Morale: Start well ahead of the dealine in order to get feedback early.

Mandatory project guidelines

The mandatory program consists of a set of exercises per week, all about the central project of the course. A solution proposal for the mandatory exercise(s) must be defined in groups of two to three persons.

The mandatory exercise will be a topic for discussion at the laboratory with the TA and has to be handed in for approval.

The delivery deadline can be viewed in the Blackboard system for each class. I will spend all or part of the last Monday lecture on aspects of the hand-ins.

The hand-in must conform to a number of rules:

  1. Many hand-ins will have a video screen cast as a central delivery. Make sure the video is of sufficiently high quality (audio/video) and encoded in a well supported format (you TA may be on a Windows, Linux, Mac box!)
  2. If you are required to hand-in a report, please use the template that is provided.
  3. Source code must be compressed as a ZIP and contain all your production and test code as well as Ant build script and all support files (libraries etc.) The root of the zip file must contain a single directory. This directory must be the root of the project and contain the Ant build.xml file. Specifically, the TA will unzip your file, change to the directory and invoke 'ant test' (or whatever target is defined by the exercise) - and it should run! If you define new targets in the script these must be clearly described in either the report or by the Ant "help" target. Remember that targets are case-sensitive: "TestAll != testall".
  4. All deliveries must be uploaded using the Blackboard system unless the server is down in which case you may send it to the TA using email. If we encounter problems about the screen cast (which is a rather large file and should not be sent by mail), please consult the web forum to see if there are any other recommendations.