Abstract
A use case model is often represented by a UML use case diagram and loosely structured textual descriptions. The use case model expressed in such a form contains ambiguous and imprecise parts. This prevents integrating it into model-driven approaches, where use case models are often taken as the source of transformations. In this paper, we introduce a domain-specific language named the Use case Specification Language (USL) to precisely specify use cases. We define the abstract syntax of USL using a metamodel together with OCL wellformedness rules and then provide a graphical concrete syntax for the usability goal. We also define a precise semantics for USL by mapping USL models to Labelled Transition Systems (LTSs). It opens a possibility to transform USL models to software artifacts such as test cases and design models. We focus on a transformation from a USL model to a template-based use case description in order to illustrate our method. A language evaluation of USL is also performed in this paper.
Highlights
Use case is a software artifact that is commonly used for capturing and structuring the functional requirements
Constraint (domain source (1,3)) represents constraints that are formed by use case variables: (1) the precondition of use case associated with InitialNode; (2) the postcondition of use case associated with FinalNodes; (3) guard conditions of a transition; and (4) the pre- and postcondition of an Action
The execution of a Use case Specification Language (USL) model is modelled by an Labelled Transition Systems (LTSs), whose transitions are caused by the execution of use case actions, and whose states are defined by variable assignments during the execution
Summary
Use case is a software artifact that is commonly used for capturing and structuring the functional requirements. An important challenge here is how to achieve a balance between two seemingly conflicting goals: to specify use case sufficiently precise for model transformation purposes, while achieving the ease-of-use required by non-technical stakeholders. To this end, a considerable number of works, including [3, 4, 5, 6, 7] and those discussed in [8], have attempted to introduce rigor into use case description. The paper is closed with the conclusions and future work
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
