o↵ering a composite GUI as a leaf value in the UI rose tree.
6.9
Conclusions
In this chapter we have introduced an overloaded, general purpose, language of the layout of things. Instead of inventing yet another layout language, we have generalized the Graphics.Scalable image layout language. For some application domains, this suffices to specify the layout of its inhabitants. We have shown this for scalable vector graphics (Graphics.Scalable) and a terminal style GUI toolkit (ncurses). For application domains in which the inhabitants can only be found indirectly, or even do not exist, we have introduced a code annotation with which the application developer can pattern match the structure of UI that is generated, and define an appropriate layout. We have shown this for handling layout of arbitrarily complicated UI components (iTasks).
Separation of concerns is achieved in this way in iTasks. The task engineer can concentrate on defining the appropriate task structure, knowing that a default task layout is always available. She can replace ‘equals by equals’, as illustrated in Section 6.6.4, knowing that it is always possible to define a custom task layout via the code annotation. Tuning the layout of a task involves defining a pattern matching code to find the task UIs and creating a custom task UI layout. If the task structure is changed, then it is likely that the task tree pattern must be changed as well, so there is a price to pay. However, in this way fragile task references do not exist (see Section 6.8) and the task layout definition does not have to be changed if the collection of task UIs is the same.
In the current proposal we have not dealt with the possibility to introduce ‘harmless’ UI content such as frames to visually delimit parts of the user interface, or expressive labels to guide the application user, and so on. We conjecture that this can be dealt with via domain specific constructor functions in combination with the constructor functions for the host.
The long term vision is that in the specification of software the way to specify things and their layout are completely orthogonal issues. We think that this chapter is a first step towards this goal.
Chapter 7
Task-Oriented Software Development
When developing software, it is considered good practice to maintain a separation of concerns, e.g., separate control flow from business logic and presentation. Do- ing so is not always straight-forward, however. How separation of concerns can be achieved depends on the language and libraries used, as well as the type of application that needs to be built.
We are particularly interested in how to build Command & Control (C2) pro- totype applications for the Royal Netherlands Navy. C2 systems are multi-user systems that coordinate information and work between a multitude of people and machines. In the naval domain, the work that needs to be done can be complex and time-critical. The tools used to write such software must be sophisticated enough to support this complex domain. Such tools are more likely to do so if they support a separation of concerns.
Our programming paradigm of choice is Task-Oriented Programming (TOP), which is implemented by the iTasks framework in the purely functional program- ming language Clean. With TOP, one defines programs in terms of the tasks people and machines need to perform. Given this high-level program description, a TOP framework generates a working multi-user web-based application with which humans and machine can perform the tasks described in the system.
In this chapter we investigate whether a prototype C2 system for fire-fighting and damage control on board of a navy vessel can successfully be implemented in a structured way using TOP, while maintaining separation of concerns. Previous work by Carlson et al. [20] already shows how functional programming can be suc- cessfully applied to program single-user C2 applications. Additionally, the Incidone application [69] shows how TOP can be used to implement an incident response application using TOP. Neither work specifically promote separation of concerns, nor do they attempt to structure the way in which the applications are written.
With this work we identify the relationships between traditional functional pro- gramming and TOP. We also identify four distinct concerns that can be developed orthogonally when applying TOP. We combine these insights into a structured soft- ware development approach called Task-Oriented Software Development (TOSD). In a sense, TOSD can be seen as the art of developing TOP applications.
Our approach to developing TOSD has been mostly experimental. While devel- oping the C2 prototype, we paid careful attention to which components we used, how they fit together, and whether they could evolve orthogonally. If certain as- pects of the application could not be developed orthogonally, we modified iTasks to correct this. In addition to a working prototype C2 application, of which the source code is available, this resulted in a substantial amount of experience with structurally developing TOP applications.
tions for complex socio technical domains, and that the software is able to evolve, due to a separation of concerns. Additionally, this work also shows that software engineering practices have a place in functional programming as well.
7.1
Introduction
When developing complex software systems, developers strive for separation of concerns [32], allowing them to work on part of the system in isolation as much as possible. Separating individual concerns reduces the complexity of the devel- opment e↵ort. How easy it is to maintain a separation of concerns depends on the complexity of the application one wants to develop, and the APIs and abstraction methods o↵ered by the programming languages, libraries, and tools being used.
We are interested in developing software for the rather complex application domain of Command and Control (C2) systems [14]. C2 systems are tools that enable gathering information from distributedly operating people, sensors, and other information sources. Their task is to inform and coordinate all participating parties in an optimal way such that they can accomplish their shared goals. For example, the Dutch Coast Guard uses C2 systems to coordinate Search and Rescue e↵orts on the North Sea. Here, Dutch and Belgian coast guards and navies may need to work together on the water, joined by medical personnel on shore. Another example is the Royal Netherlands Navy, which deploys C2 systems to support their missions anywhere on earth.
Since the application domain itself is complex, the software that supports the work people in the domain need to do is necessarily complex as well. To successfully develop C2 software, it is important that the various aspects of the applications can be developed and maintained mostly orthogonally, so that the development e↵ort does not become too complex for the application programmers. The tools used to develop the C2 systems will need to meet two requirements: they must allow the most important concepts from the domain to be implemented naturally in the chosen language, libraries and frameworks, and they must enable a separation of concerns, enabling orthogonal development of various application aspects.
To fulfil the first requirement, we choose to apply the Task-Oriented Program- ming [86] (TOP) paradigm. In TOP, tasks are the central notion with which one constructs programs. This concept corresponds naturally with the tasks people and machines need to perform in a distributed C2 setting. Everybody who uses the system, i.e. every user, needs to be constantly informed with up-to-date infor- mation about what is going on (situational awareness), such that, at each time, everybody can decide what is best to do next. Commonly, the actions of one user has consequences for what other users can see and do. Additionally, each user may be physically located in a di↵erent location, may be performing various tasks, using multiple systems, sensors, and platforms. At the same time users need to communicate and synchronize with each other, o↵ering every user a suitable user-interface, and so on.
The TOP implementation we use is called iTasks, which is a shallowly em- bedded domain-specific language (eDSL) [57] in the lazy [56], purely functional
7.2. TASK-ORIENTED PROGRAMMING AND SOFTWARE