Schematizing UML Use Cases

Transcription

1 Schematizing UML Use Cases Sabah Al-Fedaghi Computer Engineering Department Kuwait University Kuwait Asad Alrashed Computer Engineering Department Kuwait University Kuwait Abstract This paper deals with the problem of achieving consistency between a UML use case model and its corresponding set of textual descriptions. One solution that has been proposed is a format for textual use case descriptions that provides the conceptual background for textual use case descriptions while integrating them into the UML metamodel. The paper suggests that problems related to UML diagrams (multiplicity of representations and consistency among them) stem from lack of an underlying conceptual model of the basic system. This idea is demonstrated by contrasting the proposed format with a new flow-based methodology. The demonstration indicates that the latter provides a viable alternative for basic representation of system requirements. Keywords-component; formatting; UML; use case; conceptual modeling I. INTRODUCTION This paper investigates the issue of representation of information system (IS) requirements that begins with a conceptual depiction of the enterprise that describes it as part of a real-world domain. The representation is generally formulated in a narrative and/or diagrammatic form [] that portrays activities, events, flow controls, functions, applications, stakeholders, and their relationships. It serves as a guide for the succeeding IS stages of development and can be utilized as a preliminary basis for starting the IS development project. The importance of this representation phase has been extensively researched in the field of software engineering. According to Berenbach [2], the ultimate goal in such a venture is to build a business object model with sufficient detail to be able to extract a complete set of requirements. UML use case narratives are widely used in developing user requirements [3, 4]. They have high adoption rates of up to 72% [5], especially for capturing interaction-based functional requirements in software development, but use case narratives need to be complemented with diagrams to improve participant understanding [6]. The application of use cases was introduced by Jacobson [7, 8] as a useful method for capturing needs and requirements of user and software systems [9, 0] and for describing interactions between a system and its environment [, 2]. According to Constantine and Lockwood [3], Use cases have proved to be versatile conceptual tools for many facets of design and development For requirements engineering, use cases provide a concise medium for modeling user requirements; in the hands of user interface designers, use cases can become a powerful task model for understanding user needs and guiding user interface design; for software engineers, use cases guide the design of communicating objects to satisfy functional requirements. Their shortcomings are also known [4, 5]. According to Constantine and Lockwood [3], Owing in part to imprecise definition and in part to the confusion and conflation of the various possible uses and purpose of use cases, many use cases, including published ones, intermingle analysis and design, business rules and design objectives, internals and interface descriptions, with gratuitous asides thrown in to cover all bases. So deep is the confusion that even the most unconstrained mish-mash can be put forward as a use case. Use cases can be implemented both in textual (narrative) and diagrammatic forms. According to Hoffmann et al. [6], Textual descriptions, which are most widely used, are not addressed [in UML]. As a consequence, when applying a UML-based development approach, use cases are first identified and structured by means of UML use case diagrams and then described in detail through textual descriptions. Thus, the so-called use case model is actually a composite model consisting of two parts. One part is a UML model, capturing the use cases and their relationships; the other part is a set of textual descriptions of the behavior represented by these use cases. These two parts depict different views on the overall use case model and should of course not contradict each other. A problem has arisen in achieving consistency between a UML use case model and its corresponding set of textual descriptions, the written explanations of the use case relationships contained in the UML model [6].

2 This is a non-trivial problem, because ensuring consistency between a UML model and the textual use case descriptions requires a certain degree of formality in the textual descriptions. On the other hand the benefit of use case modeling is mainly rooted in its semi-formal nature. [6] Accordingly, Hoffmann et al. [6] introduce a format for textual use case descriptions that provides the conceptual background for a complete metamodel for textual use case descriptions, the so-called narrative metamodel and its integration into the UML metamodel [6]. This paper deals with this problem from a different perspective: the notion that problems related to UML diagrams (multiplicity of representations and consistency among them) stem from lack of an underlying conceptual model of the basic system. To demonstrate an instance of this claim, the paper focuses on a representative example of use cases as described above by contrasting Hoffmann et al. s [6] approach with the methodology proposed in this paper in order to compare the two representations side by side. The reader can then validate the claim of this paper that the new method is viable as a tool for modeling requirements at the conceptual level, that is, a representation of requirements that is independent of implementation. The next section provides a brief overview of Hoffmann et al. s [6] approach to textual use case descriptions that is sufficient for the aim of comparison. For the sake of a self-contained paper, section 3 briefly describes the conceptual model, called the Flowthing Model (FM), on which the new representation of the sample case is built. FM has been utilized in many applications [7-9]. Section 4 applies FM to the example given in section 2. II. TEXTUAL USE CASE DESCRIPTIONS Hoffmann et al. [6] adopt the so-called flows of events approach [20] that includes a sequence of events (default case) depicting the execution of a use case. Possible variants of the behavior can then be specified, with extension points representing possible behavioral variations described in terms of alternative flows. Extension points are used to establish extension relationships between use cases in their textual descriptions. Hoffmann et al. [6] introduce an example UML use case model for opening the doors of a car either by means of a remote control (default way) or with a key as shown in Fig.. Fig. 2 shows the corresponding floworiented textual use case description. Driver include Car Unlock Door with Remote Control Unlock Door Open Door Remote Control Unoperational Unlock Door with Key extend Figure. A UML use case diagram defining the Open Door use case UC Open Door Main Flow:. Is invoked by Actor (Driver). The driver approaches the car 2. Include UC Unlock with Remote Control to unlock the car s doors 3. The driver checks if the doors are unlocked 4. {Remote Control unoperational} 5. The driver pulls the handle and opens the door Exception Flow (Switch off Alarm):. At any time in UC Open Door (Main Flow) if alarm raised. The driver switches off the alarm UC Unlock Door with Remote Control Main Flow (redefines UC Unlock Door Main Flow):. Is invoked by Actor (Driver) (inherited from UC Unlock Door Main Flow) 2. Is included by UC Open Door (Main Flow). The driver unlocks the car with the remote control (redefines UC Unlock Door: The driver unlocks the car) UC Unlock Door (abstract use case) Main Flow:. Is invoked by Actor (Driver). The driver unlocks the car UC Unlock Door with Key Main Flow (redefines UC Unlock Door Main Flow). Is invoked by Actor (Driver) (inherited from UC Unlock Door Main Flow) 2. Extends UC Open Door at {Remote Control unoperational} if Remote Control is unoperational. {No central locking system} 2. The driver unlocks the car with the key {End Main Flow} Alternative Flow (Unlock only one Door with Key):. At {No central locking system} if car has no central locking system. The driver selects a door to unlock 2. The driver unlocks the selected door with the key Resume Unlock with Key Main Flow at {End Main Flow} Figure 2: The Open Door textual use case description

3 Accordingly, The metaclass NarrativeContainer defines a correspondence to the UML container classes [class diagram] Package and Component, thus creating a hierarchy a coarse-structural synchronization between a UML model and a narrative model is established. [6] Distinct events that describe the behavior of the use case are also identified, e.g., 2. Include UC Unlock with Remote Control ExternalInclusion 3. The driver checks if the doors are unlocked Action 4. {Remote Control unoperational} ExternalExtensionAnchor The main claim in this paper is that the approach of patching together pieces of UML diagram and use case narrative is an attempt to compensate for a sense of inadequate representation of higher-level views of the system. Solving these problems related to development of representations of requirements ought to be based on a new paradigm based on a different conceptualization of the notion of flow. Here, this narrative metamodel and its integration into the UML metamodel is not described in greater detail because the aim of this paper is to show the following:. The origin of the consistency problem that has motivated this complicated description of such a method is the multiplicity of representations needed in UML. 2. It is possible to step back and develop an alternative path to requirements representation that produces a single, integrated diagrammatic depiction called the FM model, upon which details of function, structure, and behavior can be built. 3. The FM model furnishes only a foundation that can be supplemented by tools. It is possible to utilize UML notions to enhance this new model; however, this refinement is not discussed in this paper. III. FLOWTHING MODEL The Flowthing Model (FM) was inspired by the many types of flows that exist in diverse fields, such as, for example, supply chain flow, money flow, and data flow in communication models. This model is a diagrammatic schema that uses flow things (referred to as flowthings) to represent a range of items that can be, for example, data, information, or signals. FM represents processes using flow systems (referred to as flowsystems) that include six stages, as follows: - Arrive: a flowthing reaches a new flowsystem (e.g., a buffer in a router) - Accepted: a flowthing is permitted to enter the system (e.g., correct address for a delivery); if arriving flowthings are also always accepted, Arrive and Accept can be combined as a Received stage. - ed (changed): the flowthing passes through some kind of transformation that changes its form but not its identity (e.g., compressed, colored) - Released: a flowthing is marked as ready to be transferred (e.g., airline passengers waiting to board) - d: a new flowthing originates (is created) in the system (e.g., a data-mining program generates the conclusion Application is rejected as input data) - red: the flowthing is transported somewhere outside the flowsystem (e.g., packets reaching ports in a router, but still not in the arrival buffer). These stages are mutually exclusive, i.e., a flowthing in the stage cannot be in the d stage or the Released stage at the same time. An additional stage of Storage can also be added to any FM model to represent the storage of flowthings; however, storage is not a generic stage, because there can be stored processed flowthings, stored created flowthings, and so on. Hereafter, a thing means a flowthing. Figure 3 shows the structure of a flowsystem. A flowthing is a thing that has the capability of being created, released, transferred, arrived, accepted, or processed while flowing within and between systems. A flowsystem depicts the internal flows of a system with the six stages and transactions among them. FM uses the following basic notions: Flowthing: A thing that has the capability of being created, released, transferred, arrived, accepted, and processed while flowing within and between domains called spheres. Flowthings can be concepts, actions, or information. Information communication involves creating, releasing, transferring, receiving, and processing of information. Release Accept Arrive Receive Figure 3 Flowsystem, assuming that no released flowthing is returned. The dark dots denote things at different stages of the flowsystem. The figure can be considered like net marking (instantaneous location of all tokens in the net; Petri net terminology).

4 The control of the movement of flowthings is assumed to be embedded in the stages; e.g., in, if a flowthing satisfies some condition, then it flows to Release. In principle, no difficulties should exist in conceptualizing such control of the edges, in the manner of Petri nets. Spheres and subspheres: These are the environments of the flowthing. A sphere can have multiple flowsystems in its construction, if needed. A sphere can be an entity (e.g., a hospital and the departments within it; a person or class of persons, e.g., nurses; a computer with one or more components, and so forth), a location (laboratory, waiting room), communication media (channel, wire), A flowsystem is a subsphere that embodies the flow; it itself has no subsphere. Triggering: Triggering is an activation (denoted in FM diagrams by a dashed arrow) of one flow by another. It is dependent on flows and parts of flows. A flow is said to be triggered if it is created or activated by another flow (e.g., a flow of electricity triggers a flow of heat) or if it is activated when a condition in the flow is satisfied (e.g., processing of records x and y triggers the creation of record z in the flowsystem of records). Triggering can also be used to start events, e.g., turning on a flowsystem by a remote signal. A flowsystem may not need to include all the stages; for example, an archiving system might use only the stages Arrive, Accept, and Release. Multiple systems captured by FM can interact with each other by triggering events related to one another in their spheres and stages. Example: According to Microsoft Developer Network [2], Work with your customer and other stakeholders to create scenarios, and enter them as requirement work items, with the Requirement Type field set to Scenario. A scenario or use case is a narrative that describes a sequence of events, shows how a particular goal is achieved, and usually involves interaction between people or organizations and computers. [2] The following scenario is then given.. A customer visits the Web site and creates an order for a meal. 2. The Web site redirects the customer to a payment site to make payment. 3. The order is added to the restaurant's work list. 4. The restaurant prepares and delivers the meal. The FM representation of this scenario is shown in Fig. 4. Numbers in circles indicate positions in the diagram. First, the restaurant retrieves the menu (circle ) that flows to the customer (2). The customer processes (e.g., searches) the menu (3), triggering (4) the creation (generation) of his/her order (5). The order flows to the restaurant (6), where it is processed (7) and triggers the creation of a bill (8) that flows to the customer (9). The customer receives and processes the bill (0), and that triggers () the creation of payment (2) that flows to the restaurant (3). The restaurant processes the payment (4), which triggers the creation of a meal (5) that flows to the cuatomer. IV. FM-BASED DESCRIPTION The great effort and investment in developing UML as a standard notation ought not be the last word, precluding a new paradigm that might affect or fuse with the UML scheme. Accordingly, it seems that further progress on the road of UML approach to development of system requirements means exposing weaknesses in the philosophy of multiplicity of representations. Use cases lead to confusion and conflation of the various possible uses and purpose of use cases [3]. The problem of reconciling diagrammatic and narrative representation, as exemplified by Hoffmann et al. s [6] efforts, is a manifestation of these difficulties. This paper is an attempt to rethink the problem of consistency between these forms of representation. Was the best choice to come up with diagrams and narratives, then squabbling over how to unify them? Accordingly, the solution advocated in this paper is to develop system requirements on the basis of a conceptual foundation of a single, integrated diagrammatic representation upon which details of function, structure, and behavior can be built Customer 2 Restaurant Receive Release Release 6 9 Receive 7 8 Receive Release Release 3 Receive 4 Receive Release 5 Figure 4. FM representation of the scenario given in the example Menu Order Bill Payment Meal

5 The concept is analogous to the design of engineering systems such as an electrical system which starts with a functional specification (perhaps based on customer s specification document) that includes some high-level technical details. Block diagrams similar to functional flow block diagrams [22] are made to indicate information and power flow from one component to another. Functional analysis is the systematic process of identifying, describing, and relating the functions a system must perform in order to be successful. It does not address how these functions will be performed. [22; italics added] Schematic diagrams of electrical interconnections between the components are then made. The problem in software engineering, as seen from this perspective, is finding tools for building schematic diagrams in this field. This paper proposes to use FM for this purpose: building a schematic diagram showing the interconnections between the different spheres and subspheres and the different streams of flow. The resultant FM representation itself furnishes only a foundation that can be supplemented by tools from other models such as logical operators (e.g., AND), synchronization notions (Petri nets join), constraints specifications, sequential and parallelism control, and use case narratives. To demonstrate the feasibility of this project, Hoffmann et al. s [6] Open Door use case can be recast in an FM representation with four spheres: Driver, Remote Control, Car, and Key. These spheres represent four physical things, but this is not necessary in general as will be seen in the subspheres. The Car s sphere has Remote Control (system), Doors, and Alarm subspheres. The Alarm subsphere has two sub-subspheres: Signal and. Signal is obviously a flowthing; additionally a state is also a flowthing that can be created and processed. That is, a state is a thing that has two of the six possible stages of a flowsystem. A state of a door such as open can be created anytime; it can also be processed to be half open, wide open, and so on. However, a state cannot be transferred, only through other flowthings. For example, a piece of a dynamo can transfer its state of being down to another piece, only through its movement (action), as illustrated in Fig. 5. Piece is triggered (e.g., pushed) and that generates (creates) its movement downward. The movement is transferred to piece 2, indirectly changing its state. Fig. 6 shows the FM representation that corresponds to the Open Door use case. In the figure, the Driver triggers (circle ) the remote control to create (2) a signal that flows (3) to the corresponding system in the car, where it is processed (4). Up Release Action (falling down) 2 2 Up 2 Receive Action (falling down) Down Down Figure 5. Illustration of states as flowthings. Dynamo piece cannot transfer its state directly, but only through transferring its action 2 2 Driver 0 On Off 5 Release 3 Alarm Signal off Remote control Remote control Signal open Signal Release Receive Signal Receive 8 Action (pulled) Release Receive Action (bull) Car Action (Select door) 20 2 Close Not selected 4 9 Alarm Move Open Selected 6 5 Open Door 9 Action (on key) 6 7 Key (action) Release Receive 8 Figure 6. FM representation of the the Open Door use cases

6 Note how general this type of description is, where details of operations (e.g., process) and constraints of flow are not mentioned at this phase. The modeling here is similar to drawing of a city map where blocks and streets with different flows are registered without worrying at this stage about the higher-level details, e.g., this street should have a speed limit of 30 mph, no heavy vehicles may travel in this direction, etc. ing in (4) triggers the door to be in the state of Open (5). The (physical) movement of the door requires the joint situation of: - The door in the state of Open (6), and - The driver creating an action (7) that is transferred to the door (8), and causes movement (a kind of process) of the door (9). Continuing, and following Hoffmann et al. s [6] account, there is the situation where - the alarm can be raised at any time (0), which - triggers the driver () to trigger the remote control (2), - to create a signal (3), - that flows to the alarm to be processed (4), and - turns off the alarm (5). Notice how complete and integrated is this continuity of scenes as part of the total diagrammatic map of the scenario of opening the door, in contrast to:. At any time in UC Open Door (Main Flow) if alarm raised. The driver switches off the alarm Continuing with figure 6, the driver can use the key (6 - action). An action is a flowthing since any action can be created, released, transferred, received, and processed. Creating such an action is performed (transferred 7) on the key as a type of process (on the key) (8) to trigger (9) putting the door in the Open state (5). Thus, the state is Open in two cases: triggered by the remote control (4), or by manual action on the key (8). Consequently, the door moves to being open by a pull from the driver (7 9) accompanied by the door s being in the open (unlocked) state (either 4 and 6 or 8 and 6). Also, when the driver uses a key, he/she has to select (20 - action, e.g., intentionally approaching) a door, which triggers (2) the selected door as the target to be in the Open state by the key. The Figure shows only two doors. Fig. 6 can be applied to many applications. Assume that the driver is a robot; it is very easy to outline its control mechanism to open the door by involving four instructions (Fig. 7). Thus, the use cases in this situation are: A. Send Open signal of remote control B. Pull the door IF NOT OPENING C. Select a door D. Turn the key (It is not difficult to add a flowsystem to retrieve the key) B. Pull the door Driver A. Open signal of remote control B. Pull the door Release Action (bull) Action C. Select a door (Select door) Action (on key) Release V. CONCLUSION The demonstrations of this paper point to the feasibility of using FM as an integrating diagrammatic model with a limited number of notions: spheres, flowsystems, flow, and triggering, as the underlying foundation. As mentioned previously, the FM representation itself furnishes only a foundation that can be supplemented by tools from other models. REFERENCES D. Turn on the key Figure 6. Mapping Robot instructions to FM representation [] J. Larkin and H. Simon, Why a diagram is (sometimes) worth ten thousand words, Cogn. Sci., vol., pp , 987. [2] B. Berenbach, The evaluation of large, complex UML analysis and design models, Proc. 26th Int. Conf. Softw. Eng., 2004, pp [3] B. Dobing and J. Parsons, What Practitioners Are Saying about the Unified Modeling Language, Inf. Resour. Manage. Assoc. Conf., Vancouver, BC, May 9 23, [4] B. Dobing and J. Parsons, How UML is used, Commun. ACM, vol. 49(5), pp. 09 3, [5] M. Lang and B. Fitzgerald, New branches, old roots: a study of methods and techniques in Web/hypermedia systems design, Inf. Syst. Manage., vol. 23(3), pp , [6] A. Gemino and D. Parker, Use case diagrams in support of use case modeling: deriving understanding from the picture, J. Database Manage., vol. 20(), [7] I. Jacobson, Object-oriented development in an industrial environment, in OOPSLA 87: Conference proceedings on objectoriented programming systems, languages and applications, New York, NY, USA, ACM Press, 987, pp [8] I. Jacobson, Use cases - Yesterday, today, and tomorrow, Softw. Syst. Modeling, vol. 3(3), pp , [9] M. Ratcliffe and D. Budgen, The application of use case definitions in system design specification, Inf. Softw. Tech., vol. 43(6), pp , 200. [0] S. S. Somé, Supporting use case based requirements engineering, Inf. Softw. Tech., vol. 48(), pp , [] C. McPhee and A. Eberlein, Requirements engineering for time-tomarket projects. Proc. 9th IEEE Int. Conf. Eng. Computer-based Syst., Washington, DC, IEEE Computer Society, 2002, p. 7. [2] C. J. Neill and P. A. Laplante, Requirements engineering: the state of the practice, IEEE Softw., vol 20(6), pp , [3] L. L. Constantine and L.A.D. Lockwood, Structure and style in use cases for user interface design, in Object Modeling and User Interface Design, M.V. Harmelen, Ed. Boston: Addison-Wesley, 200.

7 [4] M. Glinz, Problems and Deficiencies of UML as a Requirements Specification Language, IWSSD 00: Proc. 0th Int. Workshop Softw. Specification and Design, pages 22, Washington, DC, IEEE Computer Society, [5] C. Williams, M. Kaplan, T. Klinger, and A. Paradkar. Toward engineered, useful use cases, J. Object Tech., Special Issue: Use Case Modeling at UML- 2004, vol. 4, pp , [6] V. Hoffmann, H. Lichter, A. Nyßen, and A. Walter, Towards the integration of UML- and textual use case modeling, J. Object Tech., vol. 8(3), May-June [7] S. Al-Fedaghi, A method for modeling and facilitating understanding of user requirements in software development, J. Next Gen. Inf. Tech., vol. 4(3), pp , 203. [8] S. Al-Fedaghi, Communication-oriented business model based on flows, Int. J. Bus. Inf. Syst., accepted, 203. [9] S. Al-Fedaghi, "Diagrammatic Modeling", International Journal of Information ing and Management, 4(2), pp , 203. [20] K. Bittner and I. Spence, Use Case Modeling. Addison-Wesley, [2] Microsoft Developer Network, Developing Requirements, Visual Studio [22] NASA, Functional Analysis Module Space Systems Engineering, version.0. ce=web&cd=25&cad=rja&sqi=2&ved=0cigbebywga&url=http% 3A%2F%2Fkscsma.ksc.nasa.gov%2FReliability%2FDocuments%2F Functional_Analysis_Module_V0.pdf&ei=KLLaUYHiKMqLhQfR miggda&usg=afqjcnhqjw6ccsoebl22x6eovm5autw3g&si g2=efezupkszghrqfo9uicea