A Graph Representation for Use Case Specifications ONDREJ RYSAVY, FRANTISEK BURES Faculty of Information Technology Brno University of Technology, Bozetechova 2 Brno, Czech Republic Abstract— Use cases represent widespread industrial approach to formulation and refinement of requirements specification on a system. Although in the last decade several formal representations of use cases were defined there is still gap between their practical use and those theories. This paper provides a formulation of semantics for use cases that is based on the theory of hierarchical graphs arguing that the definition despite its simplicity is powerful enough to represent all common aspects related with use case concepts. Use case specification is divided into three levels. At the bottom level each use case is considered as a flat graph of events. The middle level shapes use cases into episodes enabling to identify and reuse common fragments. The top level depicts interaction between actors and the modeled system through use case entities. Involving hierarchical graphs enables specifying all three levels in the consistent way and provides necessary abstraction on higher levels while all details is maintained in the bottom level. Keywords:Use cases, Requirements specification, Hierarchical graphs, Formal specification, Formal methods 1. Introduction The use case concept was recognized as the fundamental tool for capturing the requirements of a system[11] in many popular object-oriented methodologies, such as Objectory[9], SOMA[6], OML[5], UML[13], and OCTOPUS[10]. In spite of the wide consensus on usefulness of use cases in the initial phase of the development, there is not agreement on their standard representation. Use cases can be described informally in natural language, semi-formal in structured natural lan- guage, in pseudo code, or with formal models such as activity or sequence diagrams. The most critical point related to the semantics of use cases is investigated in several works which attempt to use formal languages, such as Z language[2], [7], abstract state machines[8], ODAL language [12], or refinement calculus [1], for improving use cases to formal specification technique. Most of the authors consider use case as a representation of the interaction of the system with external entities, called actors enabling to describe the functionality of the system without revealing its internal structure. In this interpretation use cases model two aspects. The static view considers a system in means of the relations between use cases and actors, and the dynamic view captures behavior as an interaction between actors and the system. In this paper use cases are considered as a system having tree level architecture [14]. The purpose of the top level is to deal with modeling what actors can use system and what use cases they are using to do so. Conversely, the bottom level reflects dynamic aspects related to interaction between actors and a system. The middle level provides not only a glue putting both level together, but it also structures use cases into fragments called episodes standing for higher-level behavioral units. In this level all common relations usually defined between use case, such as uses, extends, and invokes relations, can be applied to episodes. This separation of views enables to cope with different kind of information (static structure, services, behavior) but to keep the specification consistent. The paper is organized as follows. The next section includes an overview on hierarchical graphs as a preparation for section section 4 in which basic specification of use case concepts is presented and briefly demonstrated. The paper ends with some concluding remarks. 2. Hierarchical graphs Hierarchical graphs [3],[4] extend capabilities of ordinary graphs enabling representation of structural information such as grouping and encapsulation, which cannot be easily mod- eled in the ordinary flat graphs. In this section an overview of the hierarchical graphs is given in order to establish definitions for the rest of the paper. Let Σ be a fixed set, called the node alphabet.A directed graph with labeled nodes is a tuple G =(N,E,s,t,l), where N is a set of nodes, E is a set of edges, s : E → N and t : E → N are two functions mapping an edge to its source node and its target node respectively, and l : N → Σ is the node labeling function. A loop in the graph is an edge e with s(e)= n and t(e)= n for some n. An unlabeled directed graph is a tuple G =(N,E,s,t) where node-labeling function was dropped. An unlabeled directed graph is called simple graph if it contains no loops and multiple edges. Such graph can be defined simply as G =(N,E), where N is a set of nodes as defined above and E ⊆ N × N is a set of edges. A path in G from u ∈ N to v ∈ N is a sequence of edges e 1 ,...,e k for some k ≥ 1 such that, for all i =1,...k − 1, t(e i )= s(e i+1 ),s(e 1 )= u, and t(e k )= v.A cycle in G is a path from a node n ∈ N to itself. A directed acyclic graph is a graph G =(N,E,I ) that contains no cycles. Given a directed graph G =(N,E,I ), if there exists a node n ∈ N such that, for all m ∈ N , there exists a path from n to m in G, then we say that n is a root of G and we call G a rooted directed graph. A simple graph B =(N,E) is called bipartite graph, if set N can be partitioned into two sets of nodes X, Y , such that,