programming [13] language Clean [87]. Clean is a strongly and statically type language that uses a DamasHindleyMilner [54, 71, 28] based type system with full type inference. Functional programming is shown to be very well suited [59] for modular programming, due to features such as higher-order functions. Using iTasks, one can quickly construct multi-user, distributed, web-based applications. As we shall see later, iTasks o↵ers a separation of concerns, fulfilling the second requirement. We identify various concerns using a development approach called Task-Oriented Software Development (TOSD), which we introduce in this paper. In other words, we capture the art of constructing TOP programs into a structured format. By mindfully applying TOSD, separation of concerns follows.
We demonstrate how the C2 domain is naturally mapped to TOP and how applying TOSD enables a separation of concerns by presenting a prototype C2 system, which we have implemented in iTasks. This prototype serves as an illus- tration how multi-user, distributed, web-based applications can be defined incre- mentally in iTasks, while maintaining separation of concerns. The C2 prototype application we have made has two major features. Firstly, to facilitate quick ex- perimentation with alternative ship lay-outs, it allows the user, e.g. a designer at a shipyard, to model the lay-out of a ship and location of its main systems in a graphical editor. Secondly, the application can be used to simulate fire-fighting and damage-control (FFDC) scenarios, both fully simulated and using human-in- the-loop testing. These scenarios provide insights in how the lay-out of a ship and the location of its systems influence the way calamities can be resolved.
The rest of this paper is structured as follows. First, Section 7.2 explains what TOP is, how it extends Traditional Functional Programming (TFP), and how applications are developed using TOSD. Next, Section 7.3 shows how TOSD is applied to develop our prototype C2 application. It shows the architecture of a TOP application and it highlights the high level of abstraction and the separation of concerns iTasks o↵ers. Section 7.4 discusses related work. Finally, Section 7.5 discusses our results so far and concludes with some future work.
7.2
Task-Oriented Programming and Software De-
velopment
TOP is implemented as an eDSL in the purely functional programming language Clean. In Clean, the core concepts with which one programs are (pure) functions and algebraic data types [19]. A pure function is a function that does not have any observable side-e↵ects and which, given the same inputs, always produces the same result. In a purely functional programming language, functions are composed by applying them to values or other functions. Functions are first-class citizens and can be used as argument to another function, or be given as a result of a function. TOP programs are specified in terms of tasks. Therefore TOP and C2 systems share the same conceptual level: which tasks need to be performed to achieve a goal, and by whom. Here and in the rest of the paper we use iTasks as TOP im- plementation of choice. We do so, because iTasks takes away a lot of manual work commonly involved in the development of web-applications, such as the handling
of user events, callback functions, and client/server communication. An iTasks developer is not concerned with the plethora of technical detail when developing an iTasks program. In iTasks, interactive user interfaces are generated automat- ically from the types being used. For this automatic user interface generation, iTasks uses a technique called data type generic programming [62, 8], or generic programming for short.
A major technical role of a C2 system is to coordinate I/O actions between its users. As such, one might not immediately consider a pure functional language as ideal candidate for defining C2 systems. However, iTasks appears to be well suited to implement a C2 (prototype) system, partly because of the fact that many technical details are hidden and large parts of an iTasks program is generated, and partly because of the high-level concepts TOP o↵ers, which will be discussed below. TOP with iTasks does not replace Traditional Functional Programming (TFP). We use Clean’s powerful language facilities to enhance TFP with TOP concepts. These concepts have a significant impact on the way and ease with which multi- user web-based applications can be developed. The table below relates the main concepts of TFP to the additional concepts o↵ered by TOP. The concept in the right column augments the concept in the left column. Each of the concepts in the right column will be discussed shortly.
TFP TOP
Algebraic Data Types Shared Data Sources (SDSs)
Pure Functions Tasks
Function Applications Task Combinators
I/O (Monads) Task Editors
The approach for developing TOP applications is described by a process we call Task-Oriented Software Development (TOSD). In TOSD we distinguish the following phases: (1) Domain Modelling using TFP, (2) Shared Data Modelling, (3) Task Modelling, and (4) User-Interface Customization. TOSD does not impose or assume a particular software engineering discipline, such as waterfall, agile, or iterative software development. It can therefore be used in any of these software development approaches. TOSD phases can be implemented in any order, although the rest of this paper will maintain the order presented above.
The TOSD phases can be graphically represented as shown in Figure 7.1. The foundation of TOP with TOSD is TFP. Without TFP, no TOP application can be built. Tasks and Shared Data build on the models and relations defined in TFP. Finally, when all other parts of the application are implemented, can we apply optional UI customization.
The rest of this section describes the individual TOSD steps in more detail.
7.2.1
Domain Modelling Using TFP
Developing a TOP program typically starts o↵ the same way as any functional program. Algebraic data types capture the entities from the application domain, while pure functions over these types capture the relations between these entities.
7.2. TASK-ORIENTED PROGRAMMING AND SOFTWARE DEVELOPMENT Tasks TFP Shared Data UI
Figure 7.1: TOP concerns
However, for defining side-e↵ects, I/O, interaction, user interfaces, communica- tion, synchronization, and so on, TOP concepts are used instead of familiar TFP techniques.
The absence of side-e↵ects in the resulting domain model ensures that this part of the code is easily testable and maintainable. Conventional functional program- ming best-practices, such as Test-Driven Development and Type-Driven Develop- ment, may be applied here at the programmer’s discretion.
7.2.2
Shared Data Modelling
In a C2 system, all participants need to be informed about the latest state of a↵airs. iTasks o↵ers Shared Data Sources [35] (SDSs, or shares) that share arbi- trary information between the di↵erent distributively working parties. Shares use a publish-subscribe approach: whenever shared information is changed by some- one, those parties who need to be informed are automatically updated. Shares are commonly defined globally, though they can be defined in any scope. Typically, once domain modelling has taken place, one decides which data should be made available as an SDS. Common Algebraic Data Types can be used to define the type of an SDS.
As will be explained below, tasks can inspect each others progress while their work takes place and can react based on their respective task values. However, tasks do not only depend on the status of other tasks, they are very likely to also depend on shared global data, such as the current time, the current value of sensors on some other system, information stored in data bases, files on file systems, and so on. SDSs are compositional in two directions: some SDS combinators aggregate SDSs, while others allow for projections of information. Not all changes might be relevant for a task, so the share projections can be used to specify which notifications are relevant and which are not.
7.2.3
Task Modelling
A task is a description of work someone or some device has to do. A TOP ap- plication is a task, which can in turn be composed of sub-tasks. The description of a task is declarative and focuses on what has to be done, hiding how it is all technically realized in the often complicated distributed architectural setting with many systems and many users.
iTasks Tasks
More formally, an iTasks task is a reactive, monadic function of type Task a. iTasks tasks can have arguments like any other function, and may be higher order: they can have functions and tasks as argument or result.
Task functions di↵er from ordinary functions because they are reactive, which means that a task may yield a value of type a that changes over time. A task value can be in one of three states: there can be no value, or it can have a value of type a which is either stable or unstable. When there is no value, the task does not have sensible information about its progress at that time. When a value is unstable, the task has sensible information about its progress, but the value may still change. Finally, when a value is stable, the work is either done, or a deadline has passed, and the task value no longer changes.
Task values can change over time due to the fact that some work is done by someone somewhere. Change can be caused by interactions performed by the end user to whom the task is assigned, new values produced by other tasks, or changes in some SDS which is relevant for the task being executed.
Task Combinators
Tasks can be described in terms of sub-tasks, and finally in basic tasks. Basic tasks are tasks which can e.g. interact with the user (called editors), access a database, read out a sensor, or execute a task on some remote computer. Tasks can be combined with task combinators. Most frequently used task combinators are defined in terms of two basic combinators: the sequential step combinator and the parallel combinator. They obtain their expressive power because one can observe and inspect the current values of the involved sub-tasks. One can then decide what the e↵ect for the combined task will be. From these basic combinators, arbitrarily complex derived combinators can be constructed.
One can assign tasks to anyone with a particular role, to a specific user, or to some specific computer system. Commonly there are many tasks someone has to do, but one can decide to work on any of them, in any order.
After the tasks have been modelled, one obtains an executable iTasks applica- tion which can coordinate the tasks thus described.
Task Model Verification
During development, it is important that domain experts frequently verify that the correct software is being built. One way of doing that is by letting domain experts
7.3. IMPLEMENTING A C2 SYSTEM USING TOSD