1 Introduction and Related Work

Software reuse [9, 10] is a powerful concept and realistic technique in the design and construction of modern software systems. Often in a mutually promotive relationship with modular programming [20], software reuse advocates a systematic embrace for the ideal of fully exploiting existing well tested code towards building new software under reduced development time, increased productivity and reliability.

The support for software reuse from modern programming languages, component-oriented and framework-based technologies, middleware, as well as from the state-of-the-art of modern software construction practices, has steadily improved over the years. All these advantages, among other factors such as psychology of programming and human factor improvement, are good preparations leading software reuse to a certain degree of success [19]. On the flip side however, problems such as idiosyncrasies and heterogeneities between different software applications and application domains have been constraining the growing impact and effectiveness of software reuse.

1.1 The Power of Abstraction and the Abstraction of Situation

Through the development and maturation of software engineering, as well as of programming languages, we have fully witnessed the power of abstraction [11, 13, 14]. By introducing abstractions, e.g., data abstractions, iteration abstractions, procedural abstractions etc., and in particular, by relating modularity to abstraction [12], the composing, understanding, as well as the debugging and maintenance of a gigantic computer program can be carried out in separate manageable pieces. Consequently, the need for literally going through all the coding details has thus been mitigated.

We propose to utilize an abstraction called situation, which is distilled from our previous work on Situ framework [5, 15–18]. The concept of situation can be traced back to its root in mathematical logic [2, 3], and thereafter applied to AI [21] and theoretical computer science [4]. Situation as a concept also marched into the realm of human computer interaction, contributing to the success of situation awareness technologies [8].

Extending from the situation abstraction, we come up with an infrastructure and a functional, domain specific programming language called \(Situ^f\) implemented to secure the situation abstraction into concrete and practical software engineering circumstances.

2 Functional Style Situation

From Situ framework [5], the behavioral context of a situation represented by A as in \((d,A,E)_{t}\), refers to the interaction of a software system through its interface, usually a GUI, with its human user. The concept of situation intimately portrays integrated use case scenarios, including the features of the software system.

Functional programming paradigm [1] is about computing with values, where the control flow of the entire program is deeply akin to the evaluation of a mathematical function, with little, or no side effect [1]. It is more of a what rather than how process. Due to its high expressive power and elegant computational effect, in recent years functional programming paradigm keeps gaining momentum, and has already been absorbed and built into some high impact computing technologies or well known infrastructures. Google’s MapReduce [6] for the processing of big data is such an example.

In this work, we argue that functional situations present a powerful abstraction to model software features. The motivation behind this paper is this: if we can program functional situations, where runtime environment Footnote 1 links situations with software features, then software reusability can be translated to situation reusability.

$$\begin{aligned} map\ (\ (submit\_review.download ) ,\ [paper_1,\ paper_2,\ \ldots \ paper_n ]\ ) \end{aligned}$$
(1)

(1) above is an example functional expression:

  • It features a functional expression, where higher order function map is used;

  • For map, the composite function \(submit\_review.download\) is one of its inputs;

  • The composite function \(submit\_review.download\) intrinsically reflects a temporal order: download goes first, \(submit\_review\) second;

  • (1) specifies a paper review situation, corresponding to a software feature like in MyReview softwareFootnote 2, shown in Fig. 1.

Fig. 1.
figure 1

Paper review situation vs. paper reivew software feature under MyReview software

Full size image

The most important software features shown in Fig. 1 are marked by red arrows along with the names of the two functions in functional expression (1), i.e., “dowload” and “\(submit\_review\)”. Further, a moment’s reflection reveals that the functional expression (1) captures the bareback essentials of the software features demonstrated in Fig. 1.

Indeed, functional expression (1) models the software features that allow the user, in this case a paper reviewer, to download papers and to submit reviews. It is a situation whose semantics is resulted by evaluating the functional expression (1).

It is a key observation from the preceding example that a situation may naturally take its form, or syntax, from extending a functional expression like (1). In addition, a functional expression like (1) can semantically capture the essentials of the targeted software features. Situations thus proposed is a solid abstraction that carries both its syntax and semantics.

We further state that situation is an easy to use yet powerful abstraction for domain engineers. Using Fig. 1 again as an example: without the situation abstraction, Fig. 1 simply points to a bunch of software features for MyReview system; with the situation abstraction, Fig. 1 is simply one situation, namely paper review situation, for example. Its meaning is expressed via functional expression (1). The abstraction of situation is applied here in a natural and intuitive manner. On the following pages, we present a domain specific, functional programming language, named \(Situ^f\) to further promote the abstraction of situations.

3 The Design of a Functional Domain Specific Language

To introduce \(Situ^f\), we follow the reverse order: we will first present a program written in it, i.e., Program 1 given in Fig. 2. Program 1 is a \(Situ^f\) program for the paper review situation just discussed.

Fig. 2.
figure 2

A \(Situ^f\) program for paper review situation

Full size image

Program 1 defines context-oriented paperReview situation, following the original \( Situ \) framework, where all situations are based on behavioral and environmental contexts.

  1. 1.

    The notion of @ creates an IO channel in a \( Situ^f \) program called paperReview to bind data and action to their real world counterparts: a paper can be downloaded from Review.php, whose server-side url is specified; Review can be submitted and later on collected also through the same page. Each time a paper is downloaded or a review is submitted through Review.php, the contextual information will be captured by @ and sent back to program paperReview. @ is an I/O based language feature. Once declared, data and action can be used to construct a situation.

  2. 2.

    ( ) is another I/O based feature \( Situ^f \) offers. It is a data constructor: at runtime paper() returns a list of papers resulted by a series of paper downloading actions performed on Review.php of the deployed MyReview system. Figure 3 helps illustrate this point.

  3. 3.

    Closely related with SituIO and its @ operator is the <program_url>Footnote 3 defined in the attribute grammar of \( Situ^f \) at Table 1. This symbol specifies where \( Situ^f \) runtime is able to find the external counterpart that supplies contextual information to declared data, actions and situations defined in Program 1 (Fig. 2.) Situation services provides the implementation.

Fig. 3.
figure 3

Runtime expansion of “paper()”

Full size image

3.1 Syntactical Features

The details of the attribute grammar for \( Situ^f \) are given in Table 1. The data and action declarations in Program 1 (Fig. 2) set up the data, as well as the action to construct a situation. @ operator connects data structures like paper and Review to their real world data source. For Program 1 (Fig. 2) the source of data for paper and review is the server-side Review.php. This simply means that each time the user downloads a paper through Review.php, the context data related to that paper such as author list, email contact and abstract etc. ...will be collected over the Graphical User Interface and sent back to Program 1 runtime. More concretely, through paper(), context information of all assigned papers are captured incrementally one after another and are given as input to review action. When the user finishes reviewing that paper and generates a Review Footnote 4, the Review will be captured in terms of its context ensemble: an aggregation of review comments, review score, suggestions to the Program Committee, etc. The communication is carried out while all intermediate results are recorded through XML intermediate representation.

\( Situ^f \) provides four built-in functional patterns as situation constructors to propagate contexts, or in attribute grammar’s terms: attributes, to the entire parse tree. These four built-in patterns are map, filter, reduce and apply. The map pattern is used in Program 1 (Fig. 2) in statement “map submit_review.download paper()” to describe a situation where a reviewer needs to download and then review every paper assigned to her/him. The map pattern, commonly found in functional programming paradigm, applies its first input, i.e. the temporally combined action of downloading and then reviewing (“submit_review.download”) to its second input, which is a list of papers. Readers familiar with functional programming know that map is a higher-order function that applies the first argument it accepts, which is a function or a composed function, to its second argument, usually a sequence of data such as the paper list aforementioned. \( Situ^f \) introduces map pattern so that its first argument can be re-used for all members in its second argument. Overall, applying map pattern over a list is to transform the list to another by working on each and every member of the list according to its first argument; in Specification (1), a list of reviewed papers that are attached with review comments and scores etc. are the end result for the main success scenario for Specification (1).

Table 1. Attribute grammar for \( Situ^f \)
Full size table

3.2 Situf-based Environment

The situation model that \(Situ^f\) is built upon is context-oriented, where context data are derived from actions exerted by a user over a software system. However a software system itself does not provide extra functionality to support context data collection tasks. The design of \( Situ^f \) keeps that in mind and proposes a special include directive to “include” situation services that provide context collection capabilities. Situation services are programs with implementation to collect context information for different \( Situ^f \) programs.

Fig. 4.
figure 4

\(Situ^f\)-based environment: the overview

Full size image

With concrete examples, this section elaborates on the technical details of context specification, situation services, their relationship with XML, their affiliation to a \( Situ^f \) program and finally the active roles they play towards a \( Situ^f \)-based environment.

According to the grammar of \( Situ^f \) language, the major constituents of a situation are data and actions. In a \( Situ^f \) program, the situation constructors, i.e., map, reduce, filter and apply, are used to assemble data and actions declared into a meaningful situation. This means that the context information in a \( Situ^f \) program is classified into two categories: data context and action context. Action context is built on top of data context, as the input and output of each action come from data. We will concentrate on explaining data context, through which action context should seem easy.

In \( Situ^f \) environment, context information, either for data or for action, is represented and transmitted using XML format. We use XML Schema to configure “context” templates to synchronize the communication between a \( Situ^f \) program and the external context collection capabilities, i.e., situation services, under a \( Situ^f \)-based environment.

To provide concrete explanations and illustrations for key issues involved, let us revisit the paper review example given in Program 1 (Fig. 2.) The attribute grammar of \( Situ^f \) given in Table 1 requires that each declared data, represented by grammar symbol <dataName>, have an attribute called env, meaning environment. This is a composite attribute. Its runtime implication depends on the context specification the \( Situ^f \) program imports. In fact each paper declared in Program 1 (Fig. 2) contains the following attributes: abstract, author_name, author_affiliation, email_contact, paperID, submitTime, and target_trackName.

This detailed context information is generally beyond the concern or knowledge of a domain expert, but it is very important to answer the attribute grammar requests. \( Situ^f \)’s support of separation of concerns [7] bridges this gap. More concretely, \( Situ^f \) offers an import clause feature. As seen in Program 1 (Fig. 2), the “Context_Spec_MyReview” following the “import” directive is an instance of <situation_spec>, which is encoded as an XML Schema given in Fig. 5.

Fig. 5.
figure 5

An XML schema-based context template for the paper data type

Full size image

In fact, XML Schema enables user-defined data types, comprising simple data types, which cannot use elements or attributes, and complex data types, which can use elements and attributes [22]. Complex data types can also be defined from already existing data types. The XML Schema given in Fig. 5 essentially provides a template to help bind paper, a data variable declared in Program 2, and its closely related context. Note that Fig. 5 provides detailed attributes pertaining to the specific situations associated with the MyReview system. The associating power is further enhanced by the use of namespace MyReview in Fig. 5. That said, a paper under a different circumstance, such as the “EasyChair” software system, could involve completely different attributes, the use of which requires the importing of a different XML schema. Besides, the use of namespace in an XML Schema helps to disambiguate identical naming and to differentiate between separate situation domains, e.g., MyReview vs. EasyChairFootnote 5.

Upon the import of a context specification where relevant information for a paper is provided, the \( Situ^f \) compiler automatically executes the following action (Note: the initial env attribute of paper only includes its id information. To see that, from production (4) given by the attribute grammar in Table 1: \(<dataName>_{env} = {<identifier>.id}\), when paper is declared, it replaces <dataName>.):

figure a

In Fig. 5, “paper” is defined as a new type, where abstract, author_name, author_affiliation, email_contact, paperID, submitTime, targeted_trackName and conference_name are its built-in fields. Each field, corresponding to the respective context of a “paper”, is of a precisely defined data type, such as string, integer, etc...The diverse data types available in XML Schema make XML Schema powerful enough to specify highly diverse data different \( Situ^f \) programs may face.

Figure 6 is a direct instantiation of the XML Schema based context template given in Fig. 5. Given that Fig. 6 strictly follows the format prescribed by Fig. 5, the latter is hence named Context Template.

Fig. 6.
figure 6

A sample runtime collected context value stored in XML

Full size image

Figure 6 presents a concrete runtime example of a data value traveling through SituIO. This XML element is a value for the data variable “paper” declared in Program 1 (Fig. 2). It is generated under the governing of “Context_Spec_MyReview” file, which contains the XML Schema given in Fig. 5. The XML context information shown in Fig. 6 for “paper” also presents itself as a sample value for env attribute of <dataName>, a grammar symbol instantiated by “paper,” from \( Situ^f \)’s attribute grammar in Table 1. Figure 6 shows a concrete instance of context values.

3.3 The Inclusion of Situation Services

Situation services extend the capability of a \( Situ^f \) program that includes them. Situation services are either made by a third party provider and hosted on the cloud, or they can be hosted on the local machine. The default situation service for \( Situ^f \) is called “common_service_GUI”. The default service offers the capability that, once deployed at the targeted url site, it can capture and record a software user’s action information, which is then sent back through SituIO to where the \( Situ^f \) runtime is deployed. What is captured by the default service is real time behavioral and environmental contextual information, which is configured by the central \( Situ^f \) program that generally contains program url addresses.

The design and runtime support environment for \(Situ^f\) as introduced facilitate the domain experts, who have domain specific knowledge of existing software features, to compose new ones. Consider again the software features of MyReview shown in Fig. 1. The paper reviewers can use it to download the assigned papers for a conference and submit their reviews. The corresponding situation program in \(Situ^f\) named “paperReview”, is found in Program 1 (Fig. 2.)

Now that there is a need to add a new feature named reviewReminder to the MyReview system, which aims to send a reminder email, after certain date, to the reviewers who have not finished their review assignments. The overall requirement for the reviewReminder feature is to go through all paper reviews and to count the number of words in the review comments, by which empty reviews bear zero word count. Below a certain count value, the relative reviews will be considered incomplete. Correspondingly, a reminder message is emailed to the related reviewers.

A good question to ask is how to take full advantage of, or, re-use, the existing system features to compose reviewReminder. To this end, being able to expressively and immediately compose the essential linkage, between existing features and reviewReminder, gives the software designer a leg up towards a high quality software construction. Using \(Situ^f\) language and with relative ease, the domain experts can propose a short solution, i.e., a \(Situ^f\) program, shown in Fig. 7.

Fig. 7.
figure 7

A \(Situ^f\) program for review reminder

Full size image