Refining Use Cases Through Temporal Relations

Lecture Notes in Computer Science, 2010

Despite the widespread adoption of UML as a standard for modeling software systems, it does not provide adequate support for specifying User Interface (UI) requirements. It has become a common practice to separately use UML use cases for specifying functional requirements and task models for modeling UI requirements. The lack of integration of these two related models is likely to introduce redundancies and inconsistencies into the software development process. In this paper, we propose an integrated model, consisting of use case and task models, for capturing functional and UI requirements. Both artifacts are used in a complementary manner and are formally related through so-called Anchors. Anchors are use case steps that require further elaboration with UI-specific interactions. These interactions are explicitly captured in associated task models. The formal semantics of the integrated model is given with finite state automata.

e-Informatica Software Engineering Journal

Background: The comprehensive representation of functional requirements is a crucial activity in the analysis phase of the software development life cycle. Representation of a complete set of functional requirements helps in tracing business goals effectively throughout the development life cycle. Use case modelling is one of the most widely-used methods to represent and document functional requirements of the system. Practitioners exploit use case modelling to represent interactive functional requirements of the system while overlooking some of the non-interactive functional requirements. The non-interactive functional requirements are the ones which are performed by the system without an initiation by the user, for instance, notifying something to the user or creating an internal backup. Aim: This paper addresses the representation of non-interactive requirements along with interactive ones (use cases) in one model. This paper calls such requirements 'operation cases' and proposes a new set of graphical and textual notations to represent them. Method: The proposed notations have been applied on a case study and have also been empirically evaluated to demonstrate the effectiveness of the new notations in capturing non-interactive functional requirements. Results and Conclusion: The results of the evaluation indicate that the representation of operation cases helps in documenting a complete set of functional requirements, which ultimately results in a comprehensive translation of requirements into design.

2000

The Unified Modeling Language (UML) is a semi-formal graphical language that has been accepted as standard to model object-oriented software systems. This language defines various kinds of diagrams that are used to describe different aspects or views of a system. In particular, Use Cases diagrams are used to capture the requirements of the systems and to guide their development process. The different Use Cases defined throughout a development process are not independent but it is possible to set relations between them. The main relations considered by UML are the following: Generalization, Include and Extend. These relations as well as the remaining UML constructs are semi-formally defined, giving place to ambiguous interpretations and inconsistencies. This paper presents a formalization that gives precision to the definition of the main relations between Use Cases. This formalization will allow us to check consistency when incrementing the Use Cases model during the software development process and when relating Use Cases model with others models.

A use case is a description of a sequence of actions constituting a complete task or transaction in an application. Use cases were first proposed by Jacobson (1987) and have since been incorporated as one of the key modeling constructs in the UML(Booch, Jacobson, & Rumbaugh, 1999) and the Unified Software Development Process(Jacobson, Booch, & Rumbaugh, 1999). This chapter traces the development of use cases, and identifies a number of problems with both their application and theoretical underpinnings. From an application perspective, the use-case concept is marked by a high degree of variety in the level of abstraction versus implementation detail advocated by various authors. In addition, use cases are promoted as a primary mechanism for identifying objects in an application, even though they focus on processes rather than objects. Moreover, there is an apparent inconsistency between the so-called naturalness of object models and the commonly held view that use cases should be the...

2005

Functional requirements for information systems can be modeled through use cases. Furthermore, use case models have been successfully used in broader contexts than software engineering, as systems engineering. Even if small systems may be modeled as a set of use cases, when large systems requirements are modeled with a plain use case model several difficulties arise. Traditionally, the behavior of use cases has been modeled through textual specifications. In this paper we present an alternate approach based on interaction modeling. The behavior modeling has two variants (one for UML 1.x and one for UML 2.0). We also integrate our behavior modeling with standard use case relationships.

Usability, 2002

The purpose of this paper is to explore use case maps as a medium for integrating task analysis and usability requirement into the traditional software requirement engineering process. The paper responds to major gaps in user interface specification in HCI, in software development methods for interactive software, and in the communication between usability specialists and software developers. We illustrate, via a concrete example, the usage of use case maps as an approach for specifying user interface and usability requirements. The Use Case Maps (UCMs) is a scenario-based notation for describing, in an abstract way, how the organizational structure of a complex system and the emergent behavior of the system are intertwined. It provides a first-class design model for the "how it works" aspect of both object-oriented and real time systems. Use case maps give a road-map-like view of the causeeffect paths traced through a system by scenarios or use cases .

2001

Although widely employed in both object-oriented software engineering and user interface design, use cases are not well-defined. Relatively little attention has been paid to the various styles for writing the narratives that define use cases and their consequences for user interface design and software usability. Common narrative styles are presented with examples and discussions of their relative advantages and disadvantages. Essential use cases, a variant employed within usage -centered design, are contrasted with conventional use cases and scenarios. For the most efficient support o f user interface design and particularly for large, complex projects, a highly-structured form of use case has evolved. New narrative elements and relationships among use cases are introduced. These include means for expressing partial or flexible ordering of interaction, relationships with business rules, as well as a clarification of the often misunderstood concept of extension that recognizes two distinct forms: synchronous and asynchronous extensions.

Journal OF Object …

Use Cases have achieved wide use as a specification tool for observable behavior of systems. However, there is still much controversy, inconsistent use, and free-flowing interpretations of use case models, in fact, not even experts widely recognized in the community agree on the meaning of concepts. Consequently, use case models are dangerously ambiguous, and there is an unnecessary divergence of practice. The purpose of the workshop was to identify and characterize some sources of ambiguity. It gathered specialists from academia and industry involved in modeling use cases to exchange ideas and proposals, with an eye to both clear definition and practical application. Some presented topics were discussed in-depth (the UML metamodel for use cases, use case instances, use cases in MDD/MDA, use case model vs. conceptual model, and tools for use cases specification), while others were left as open issues for future research. We hope our suggestions will be useful to improve the understanding of use cases, and stimulate further research to reach a stronger coupling between the use case model and other static, behavioral and architectural models. J OURNAL OF OBJECT TECHNOLOGY Chile. His research and practice interests include software architecture modeling, derivation and reuse, COTS, and middleware. He can be reached at [email protected].

In this paper, we present a metamodel for textual use case descriptions, structurally conforming to the UML, to specify the behavior of use cases in a flow-oriented manner. While being primarily targeted at supporting requirements engineers in creating consistent use case models, the metamodel defines a textual representation of use case behavior that is easily understandable for readers, who are unaware of the underlying metamodel. Hence, the known benefits of natural language use case descriptions are preserved. Being formalized, consistency between UML-based use case representations and their textual descriptions can be automatically ensured. With NaUTiluS we present an extensible, Eclipse-based toolkit, which offers integrated UML use case modeling support, as well as editing capabilities for their textual descriptions.

Recently, the use of scenarios for requirements acquisition has gained a lot of attention in the research community. Yet, the transition from scenarios to formal specifications, the target of the requirements engineering process, remains ill-defined. Over the past decade, the rapid prototyping of user interfaces has become quite a common technique in industry; however, prototyping remains weak in linking the application domain with the user interface, and automated prototyping is mostly limited to database-oriented applications. Most importantly, the prototyping and the scenario approaches lack integration in the overall requirements engineering process. In this paper 1 , we suggest a requirement engineering process that generates a user interface prototype from scenarios and yields a formal specification of the application. Scenarios are acquired in the form of collaboration diagrams as defined by the Unified Modeling Language (UML), and are enriched with user interface (UI) inform...