Fig 2 - uploaded by Ferhat Khendek
Content may be subject to copyright.
Source publication
Abstract Use cases are the notation of choice for functional requirements documentation, whereas task models are used as a starting point for user interface design. In this paper, we motivate the need for an integrated development methodology in order to narrow the conceptual gap that exists between software engineering and user interface design. A...
Contexts in source publication
Context 1
... a concrete example of a use case, Figure 2 presents a detailed user-goal level use case for "Ordering a Product". A use case starts with a "header" section containing various properties of the use case. ...
Context 2
... with secondary actors (which are specified in the use case model) are omitted since they are irrelevant for UI design. An example of this is use case step 7 ("System interacts with the payment authorization system to carry out the payment") of the "Order Product" use case of Figure 2. ...
Context 3
... this section we remind the reader of the key characteristics of use cases and task models. For each notation we provide definitions, and an illustrative example. Finally, both notations are compared and main commonalities and differences are contrasted. Use cases were introduced roughly 15 years ago by Jacobson. He defined a use case as a “specific way of using the system by using some part of the functionality” [8]. More recent popularization of use cases is often attributed by Cockburn [4]. Use case modeling is gradually making its way into mainstream practice which sees it as a key activity in its software development process (e.g. Rational Unified Process) and as a result, there is accumulating evidence of significant benefits to customers and developers [14]. A use case captures the interaction between actors and the system under development. It is organized as a collection of related success and failure scenarios that are all bound to the same goal of the primary actor [11]. Use cases are typically employed as a specification technique for capturing functional requirements. They document the majority of software and system requirements and as such, serve as a contract (of the envisioned system behavior) between stakeholders [4]. In current practice, use cases are promoted as structured textual constructs written in prose language. While the use of narrative languages makes use cases modeling an at- tractive tool to facilitate communication among stakeholders, prose language is well known to be prone to ambiguities and leaves little room for advanced tool support. As a concrete example of a use case, Figure 2 presents a detailed user-goal level use case for “Ordering a Product”. A use case starts with a “header” section containing various properties of the use case. The core part of a use case is its main success scenario , which follows immediately after the header. The main success scenario consists of a sequence of interaction steps between the user and the system. The interaction steps indicate the most common way in which the primary actor can reach his/her goal by using the system. The use case is completed by specifying the use case extensions . These extensions constitute alternative scenarios which may or may not lead to the fulfillment of the use case goal. They represent alternative (and sometimes exceptional) behavior (relative to the main success scenario) and are indispensable to capturing full system behavior. Each extension starts with a condition (relative to one or more steps of the main success scenario), which makes the extension relevant and causes the main scenario to “branch” to the alternative scenario. The condition is followed by a sequence of action steps, which may lead to the fulfillment or the abandonment of the use case goal and/or further extensions. From a requirements point of view, exhaustive modeling of use case extensions is an effective requirement elicitation device. User task modeling is by now a well understood technique supporting user-centered UI design [18]. In most UI development approaches, the task set is the primary input to the UI design stage. User task models describe the tasks that users perform using the application, as well as how the tasks are related to each other. The origin of most task modeling approaches can be traced back to activity theory [10], where a human operator carries out activities to change part of the environment (artifacts) in order to achieve a certain goal [5]. Like use cases, task models describe the user’s interaction with the system. The primary purpose of task models is to systematically capture the way users achieve a goal when interacting with the system [24]. Different presentations of task models exist, ranging from narrative task descriptions, work flow diagrams to formal hierarchical task descriptions. Figure 3 shows an adapted ConcurTaskTreesEnvironment (CTTE) [16] visualization of the user task model. CTTE is a tool for graphical modeling and analyzing ConcurTaskTrees (CTT) models [17]. The figure illustrates the hierarchical break down and the temporal relationships between tasks involved in the “Order Product” functionality (depicted in the use case of Section 3.1). More precisely the depicted task model specifies how the user makes use of the system to achieve his/her goal but also indicates how the system supports the user tasks. An indication of task types is given by the used symbol to represent tasks. The task model is organized as a directed graph. Tasks are hierarchically decomposed into sub-tasks and atomic actions. Leaf tasks are also called actions, since they are the task that actually carried out by the user or the system. The execution order of tasks is determined by temporal operators that are defined between peer tasks. Various temporal operators exist; the most popular are: enabling ( >> ), choice ([]), concurrency ( || ), and disabling ([ > ). A complete list of the CTT operators together with definition of their interpretation can be found in [17]. We note that the binary temporal operator used between the tasks “Display Purchase Summary” and “Display out of Stock” and between the tasks “Display Confirmation” and “Display Payment Error” is not part of CTT. We have introduced the operator as an extension to CTT. It is called the Abort Choice operator and is represented by the symbol ([] A ) and the STOP sign hovering over its right operand. The interpretation of the Abort Choice operator is similar to the build-in Choice operator, in the sense that either the task specified by the first operand or the task specified by the second operand is executed. However, after the execution of the second operator all tasks of the model become disabled. Hence, no more tasks can be executed and the scenario ends. Main motivation for the introduction of this temporal operator was the fact that without it we were not able to conveniently implement the flow specified in the “Order Product” use case as a CTT task model. Particularly problematic are the use case steps which prematurely lead to termination. The only way to simulate such an effect in a CTT task model is to create several main alternative branches in the task tree. One branch represents the case when the “Order Product” is completely performed, whereas the other branches represent cases when the task terminates prematurely. Such a modeling however, creates a significant amount of duplication (since identical starting tasks would be repeated in each brand) and unnecessarily increases the complexity of the visualization of the task tree. In the ...
Context 4
... the depicted task model specifies how the user makes use of the system to achieve his/her goal but also indicates how the system supports the user tasks. An indication of task types is given by the used symbol to represent tasks. The task model is organized as a directed graph. Tasks are hierarchically decomposed into sub-tasks and atomic actions. Leaf tasks are also called actions, since they are the task that actually carried out by the user or the system. The execution order of tasks is determined by temporal operators that are defined between peer tasks. Various temporal operators exist; the most popular are: enabling ( >> ), choice ([]), concurrency ( || ), and disabling ([ > ). A complete list of the CTT operators together with definition of their interpretation can be found in [17]. We note that the binary temporal operator used between the tasks “Display Purchase Summary” and “Display out of Stock” and between the tasks “Display Confirmation” and “Display Payment Error” is not part of CTT. We have introduced the operator as an extension to CTT. It is called the Abort Choice operator and is represented by the symbol ([] A ) and the STOP sign hovering over its right operand. The interpretation of the Abort Choice operator is similar to the build-in Choice operator, in the sense that either the task specified by the first operand or the task specified by the second operand is executed. However, after the execution of the second operator all tasks of the model become disabled. Hence, no more tasks can be executed and the scenario ends. Main motivation for the introduction of this temporal operator was the fact that without it we were not able to conveniently implement the flow specified in the “Order Product” use case as a CTT task model. Particularly problematic are the use case steps which prematurely lead to termination. The only way to simulate such an effect in a CTT task model is to create several main alternative branches in the task tree. One branch represents the case when the “Order Product” is completely performed, whereas the other branches represent cases when the task terminates prematurely. Such a modeling however, creates a significant amount of duplication (since identical starting tasks would be repeated in each brand) and unnecessarily increases the complexity of the visualization of the task tree. In the previous two sections, the main characteristics of use cases and task models were discussed. In this section, we compare both approaches and outline noteworthy differences and commonalities. Both, use cases and task models, belong to the family of scenario-based notations and as such capture sets of usage scenarios of the system. On the one hand, a use case specifies system behavior by means of a main success scenario and any corresponding extensions. On the other hand, a task model specifies system interaction within a single “monolithic” task tree. In theory, both notations can be used to describe the same information. In practice however, use cases are mainly employed to document functional requirements whereas task models are used to describe UI requirements/design details. Taking this perspective, use cases capture requirements at a higher level of abstraction whereas task models are more detailed. Hence, the atomic actions of the task model are often lower level UI details that are irrelevant (actually contraindicated [4]) in the context of a use case. The above mentioned difference is manifest in the use case and task model pro- vided as examples. Compared to the “Order Product” use case the corresponding “Order Product” task model has more UI details as it contains steps that are perti- nent to a graphical UI. For example the task model contains additional tasks which deal with the submission of selected or entered values (e.g. “Submit Search Pa- rameters” or “Submit Payment Information”). These steps are not specified in the corresponding use case, as they are geared to a UI which requires an extra submission step as a confirmation for a data input. In addition, some of the use case steps (which are the smallest possible units of a use case) have been split into even smaller action tasks in the task model. For example, use case step 2 corresponds to one connected user activity, which however needs to be supported by three UI elements capturing the input of the Product Category, Series and Brand. In many cases however, a use case will contain (behavioral) information that is not present in the task model. Task models concentrate on aspects that are relevant for UI design and as such, their usage scenarios are strictly depicted as input-output relations between the user and the system. Interactions with secondary actors (which are specified in the use case model) are omitted since they are irrelevant for UI design. An example of this is use case step 7 (“System interacts with the payment authorization system to carry out the payment”) of the “Order Product” use case of Figure 2. In this section we begin with a review of formalism used for scenario-based notations, and thus, those most likely to serve as a common foundation for use cases and task models. This is followed by a discussion of the requirements that would need to be addressed by a common semantic framework for use cases and task models. Finally, we present our proposed semantic domain, which is based on partial order sets. Within the domain of scenario-based notations the behavioral aspects of a system (capturing the ordering and the progression of events) play a pivotal role. While several different formalisms have been proposed for scenario-based notations, in what follows we briefly discuss three prominent approaches, namely: process algebras, partial order sets and graph structures. A formalism that has been widely used to define interleaving semantics of scenario-based notations is process algebras. In this approach, the behavior of a system is modeled by a set of (possibly concurrently running) processes. The formalism itself is presented as a formal calculus (which defines terms of algebra) with associated “deduction/transformation” rules for reasoning about algebraic specifications. The International Telecommunication Union (ITU) has published a rec- ommendation for the formal semantics of basic Message Sequence Charts (MSCs) based on the Algebra of Communicating Processes (ACP) [2][6]. This work is a continuation of preliminary research first established by Mauw et. Reniers [13]. In more recent work, Rui and Butler also suggest a process algebraic semantics for use case models, with the overall goal of formalizing use case refactoring [22][25]. In their approach, scenarios are represented as basic MSCs–as suggested by [21]. In Rui’s proposal, he assigns meaning to a particular use case scenario (episode) by partially adapting the ITU MSC semantics. In addition, semantics are defined for related scenarios of the same use case as well as for related use cases. The following use case relations are formally defined: includes, extends, generalization, proceeds, similar, and equivalence. Formalisms suitable for the definition of non-interleaving semantics are based on partial orders. For example, Zheng et. al. propose a non-interleaving semantics for timed MSC 2000 [7] based on timed labeled partial order sets (lposets) [26]. Partial order semantics for (regular, un-timed) MSCs have been proposed by Alur [1] and Katoen and Lambert [9]. Alur et. al. propose a semantics for a subset of MSCs which only allow message events as possible MSC events types. In contrast, the semantics of Katoen and Lambert is more complete. They map MSCs to a set of partial order multi-sets (pomsets). A pomset is a so-called isomorphic class of a corresponding lposet. A pomset contains all objects that can be derived by a bijective projection from a base lposet. Approaches based on pomsets are very similar to approaches based on lposets. Mizouni et. al. propose use case graphs as an intermediate notation for use cases [15]. Use case graphs are directed, potentially cyclic graphs whose edges represent use case actions and nodes represent system states. This allows for a natural representation of the order in which actions are to be performed. In order to integrate several use cases into a single specification, Mizouni et. al. describe an algorithm for transforming a set of (related) use case graphs (each representing one use case) into an extended finite state machine (EFSM). The merging of the graphs is done on the basis of common states within the use case specifications. The semantic definition proposed in this paper was originally inspired by the lposet approach proposed by Zheng et. al. In addition, similar to the work of Mizouni et. al., we employ use case graphs as an intermediate notation for use cases. Before we present our approach, we discuss some of the core requirements that need to be addressed by any formalism that is to be used to model both use cases and task models. In Section 3 we reviewed key characteristics of use cases and task models and discussed their current (and specialized) areas of application. In this section, we will re-consider this information in order to compile a set of requirements that would be particular to any common semantic framework for use cases and task models. Both notations are used to specify scenarios that indicate how the system is used. Technically a scenario consists of a, possibly infinite, sequence of events. Therefore, we require that a semantic model for use cases and task models formally captures sets of usage scenarios . It should be possible to mechanically extract valid usage scenarios from formal specifications. Also, given a specification and a scenario, it should be possible to unambiguously decide whether the scenario is valid or not, relative to the given specification. In task modeling (e.g. CTT), one often distinguishes between different task types. Examples are: ...
Similar publications
A graph neural network (GNN) for image understanding based on multiple cues is proposed in this paper. Compared to traditional feature and decision fusion approaches that neglect the fact that features can interact and exchange information, the proposed GNN is able to pass information among features extracted from different models. Two image unders...
Citations
... Sinnig et al. [77] describe a new formalism based on sets of partially ordered sets. They use it to formally define use cases and task models. ...
Our research team is specialized in human-computer systems and their engineering, with focus on interactive software systems for aeronautics (from cockpits to control towers). This context stands out by the need for certification, such as DO-178 or ED-12. Today, formal methods are pushed forward, as one of the best tools to achieve the verification and validation of properties, leading to the certification of these systems. Interactive systems are reactive computer systems that process information from their environment and produce a representation of their internal state. They offer new rich interfaces with sophisticated interactions. Their certification is a challenge, because the validation is often a human based process since traditional formal tools are not always suitable to the verification of graphical properties in particular. In this paper, we explore the scientific work that has been done in formal methods for interactive systems over the last decade, in a systematic study of publications in the International Workshop on Formal Methods for Interactive Systems. We describe an analytical framework that we apply to classify the studied work into classes of properties and used formalisms. We then discuss the emerging findings, mainly the lack of papers addressing the formal specification or validation of perceptibility properties. We conclude with an overview of our future work in this area.
... All of the checks focus on global properties of use-case models. The same authors wrote a number of papers about mapping use-cases into several formalisms -POSETs in [17], finite state machines in [14] and LTS+POSETs in [16]. As opposed to FOAM, properties to be verified are pre-defined (FOAM allows for user-defined properties) and branching scenarios are not considered. ...
Textual use-cases have been traditionally used in the initial stages of the software development process to describe software
functionality from the user's perspective. Their advantage is that they can be easily understood by stakeholders and domain
experts. However, since use-cases typically rely on natural language, they cannot be directly subject to a formal verification.
In this article, we present a method (called Formal Verification of Annotated Use-Case Models, FOAM) for formal verification
of use-cases. This method features simple user-definable annotations, which are inserted into a use-case to make its semantics
more suitable for verification. Subsequently, a model-checking tool is employed to verify temporal invariants associated with
the annotations. This way, FOAM allows harnessing the benefits of model checking while still keeping the use-cases understandable
for non-experts.
... All of the checks focus on global properties of use-case models. The same authors wrote a number of papers about mapping use-cases into several formalisms – POSETs in [10], finite state machines in [11] and LTS+POSETs in [12]. As opposed to FOAM, properties to be verified are pre-defined (FOAM allows for user-defined properties) and branching scenarios are not considered. ...
The advantage of textual use-cases is that they can be easily understood by stakeholders and domain experts. However, since use-cases typically rely on a natural language, they cannot be directly subject to a formal verification. In this paper, we present Formal Verification of Annotated Use-Case Models (FOAM) method which features simple user-definable annotations, inserted into a use-case to make its semantics more suitable for verification. Subsequently a model-checking tool verifies temporal invariants associated with the annotations. This way, FOAM allows for harnessing the benefits of model-checking while still keeping the use-cases understandable for non-experts.
... In general, the purpose of model-based design, for instance (Calvary, 2003;Santoro, 2002;Sinnig, 2007;Traetteberg, 1999;, of User Interfaces (UIs) is to identify high-level models which allow designers to capture specifications of interactive applications from a more abstract level than the implementation level at which the future application will be developed. This allows designers to concentrate on important design aspects without being influenced by the implementation constraints. ...
... The literature demonstrated that there is a rich set of task modeling approaches and practices, for instance Paterno, 1999;Rosson, 2007;Sinnig, 2007;Traetteberg, 1999;van der Veer, 2000). The set of identification criteria that was defined in the previous section is not intended to replace any of these approaches and practices. ...
Task modeling consists of a fundamental activity that initiates usercentered design in user interface development. It is therefore important to reach the best task model possible and that the task modeling activity remains consistent when the task modeler changes. For this purpose, this paper introduces a set of criteria in order to identify tasks during task modeling in an unambiguous way that results into a task model exhibiting desired properties of quality such as completeness, consistency. In addition, starting and stopping criteria provide designers with guidance on when and how to start and finish the task modeling. Full Text at Springer, may require registration or fee
... In addition, similar to the work in [25], we employ labeled graph structures (Use Case LTS) as an intermediate notation for use cases. Preliminary results towards the definition of a common semantic model for use cases and task models were reported in [27]. In this paper we complete and define our framework as a two-step mapping process, provide a formal semantics for all CTT expressions, and formalize the mapping from DSRG-style use cases to partial order sets using the intermediary notation of Use Case LTS. ...
In this paper, we introduce a common semantic framework for developing and formally modeling use cases and task models. Use cases are the notation of choice for functional requirements specification and documentation, whereas task models are used as a starting point for user interface design. Based on their intrinsic characteristics we devise an intermediate semantic domain for use cases and for task models, respectively. We describe how the intermediate semantic domain for each model is formally mapped into a common semantic domain which is based on sets of partial order sets. We argue that a two-step mapping results in a semantic framework that can be more easily validated, reused and extended. As a partial validation of our framework we provide a semantics for ConcurTaskTrees (CTT) one of the most popular task model notations as well as our own DSRG use case formalism. Furthermore we use the common semantic model to formally define a satisfiability relation between task model and use case specifications.
... A prerequisite for a formal comparison (in terms of consistency) of use cases and task models is a common semantics. In [18] Sinnig et al. propose a common formal semantics for use cases and task models based on sets of partial order sets. Structural operational semantics for CTT task models are defined in [19]. ...
... Similar rewritings can be established for the operators disabling and suspend/resume. Further details can be found in [18]. ...
Use cases are the notation of choice for functional requirements documentation, whereas task models are used as a starting
point for user interface design. In this paper, we motivate the need for an integrated development methodology in order to
narrow the conceptual gap between software engineering and user interface design. This methodology rests upon a common semantic
framework for developing and handling use cases and task models. Based on the intrinsic characteristic of both models we define
a common formal semantics and provide a formal definition of consistency between task models and use cases. The semantic mapping
and the application of the proposed consistency definition are supported by an illustrative example.
... Preliminary results towards the definition of a common semantic model for use case and CTT task models were reported in [Sinnig et al. 2006;]. In ] we defined an extensible semantic framework, in which use cases and CTT task specifications are first mapped into intermediate semantic domains, which in turn are mapped to the semantic domain of sets of posets. ...
... A cornerstone of the integrated development methodology is the definition of a common formal semantics for the use case and the task model. The semantic framework defined in this thesis is inspired by the lposet approach proposed in [Zheng 2004] and is a continuation of preliminary work first reported in [Sinnig et al. 2006;]. ...
Publish/subscribe is a communication paradigm for distributed interaction. The paradigm provides decoupling in time, space, and synchronization for interacting entities and several variants of publish/subscribe exists including topic-based, subject-based, and type-based publish/subscribe. A central issue in implementing publish/subscribe-based systems is for entities to agree on a common vocabulary. To support this, we present a conceptualization and a design of a publish/subscribe system that combine and generalize many of these paradigms by using Semantic Web technology. In doing so, we extend previous work on ontology-based publish/subscribe by describing the semantics of publish/subscribe using operations on ontologies and by using common Semantic Web technology. Furthermore, we present an implementation in the context of a middleware we are designing and show that this implementation has adequate performance.
User interface (UI) development methods are poorly integrated with standard software engineering (SE) practices. Despite current efforts of closing the conceptual gap between these two disciplines, there is still a lack of methodologies supporting a collaborative and synchronized development approach. To address this shortcoming, we propose an integrated development methodology for use cases and task models. Use cases have become the standard to model functional requirements, whereas task models are used to specify UI requirements. Based on this understanding we propose using CTT task models to incrementally enrich the UI-related steps in the use case model, thus achieving a clear separation of concerns and avoiding potential inconsistencies between the two artifacts.
A significant portion of our modern economy is dependent on the reliability and usability of enterprise applications (EAs) of which business transactions and concurrency management are central concepts. The correct orchestration of subordinate system transactions forming a business transaction, as well as proper concurrency conflict resolution strategies are crucial factors. In this paper we argue that modeling business transactions and concurrency management are a domain activity and as such, are to be analyzed and documented during the requirements phase. Failing to do so can have a significant negative effect on the usability of an application. Driven by our own experiences in writing use cases for EAs, we demonstrate how business transactions can be modeled within use case specifications. Concrete examples and usage guidelines are offered as well as a demonstration of how our approach helps contribute to the difficult task of requirements elicitation.