A Stuy of the Relationship between Usability an Test Cases Preceence Base on a Formal Moel for Activity Diagrams Pero José Lara Bercial Computer Systems Department Universia Europea e Mari Villaviciosa e Oón, Spain Juan José Escribano Otero Computer System Department Universia Europea e Mari Villaviciosa e Oón, Spain Luis Fernánez Sanz Computer System Department Universia Europea e Mari Villaviciosa e Oón, Spain José Ramón Hilera González Computer Science Department Universia e Alcalá Alcalá e Henares, Mari, Spain Abstract - This paper is focuse on the application of the well-known technique of use cases an especially on the activity iagrams use to represent them to enhance the IS requirements management. Base on previous work of the authors on test generation from use cases an recent stuies about operation time measurement, this new form of aressing requirements management coul offer significant benefits when compare with traitional practices: a) closer integration between functional requirements an usability constraints, b) easier an more profitable way to reuse the effort on the analysis phase an c) better relationship between analysts an users to erive a goo quality specification. This paper shows how formal moel for an extene activity iagram can be use for ouble purpose: A risk analysis on one han an a usability analysis on the other one. Keywors: Use Cases, Activity Diagram, Usability, MTM, Test Cases, Risk Analysis, UML. 1.0 Introuction People involve in software evelopment proects are usually worrie about problems in software quality an its impact on IS (Information Systems) evelopment an relationships Users suffer ba quality stanars of the final release. Bugs, low performance or useless interfaces are goo examples. Developers nee high quality specifications to avoi misunerstaning of requirements, incomplete information, etc. that have a really negative influence on software proects. They woul sooner remove any errors in software requirements to avoi the classical problems of having a poor reference of what the user nees. The relative cost of fixing a efect increases exponentially across the phases of a proect an a high proportion of all problems in software proects have their origin in a poor requisite specification [1]. Clients, i.e. those who pay for the software, suffer the elays on releases ue a ba quality evelopment process. Although the last one is rather concerne to a goo proect planning, the two first facts are irectly relate to the way in which users, analysts, esigners, evelopers an testers communicate among them, specially uring the software requirements specification process. Obviously many approaches have been evise to iminish the impact of these problems an to prevent errors an miscommunications uring the initial phases of a proect. Nowaays, it is generally accepte that goo practices inclue the use of well-known notation guies such as UML [2] an the application of moern software processes like Unifie Process [3]. This an other best practices have enable evelopers to abate traitional problems with a better functional requirements efinition. Use cases are an essential part of UML notation to explain the external behavior of an information system. We can efine a use case as A escription of set of sequences of actions, incluing variants, that a system performs that yiel an observable result of value to an actor [4]. Use cases provie evelopers a way to establish a common unerstaning with en users an omain experts. In aition, use cases help to valiate your architecture an to verify a system as it evolves uring evelopment [2]. Use cases are even more useful when combine with activity iagrams (ADs).
An AD is a special case of a state iagram: a moel showing the set of ifferent states of an obect uring its life an the conitions to change from one state to another. In ADs most of states are action states (that ientify what to o in them) an most of transitions are activate when action relate to the previous state finishes. Given a use case escription (applying a stanar representation template [5]), we present below an example of how a use case can be represente as an AD. Use Case: Deleting User Data Goal: Remove all the information about one user in the ata base. Main event flow: Actor System 1. Inits user rop process 2. Asks for 3. Introuces 4. Shows user ata an asks for confirmation 5. Confirms user rop 6. Drop user an Show confirmation. Alternative workflows: If the introuce ID oes not match, a message is shown at step 4 an workflow return to step 3. Any time, if the actor ecies to cancel the action then no changes shoul be one an control return to the main menu. Preconitions: The user to be elete is store in the system Postconitions No information about the elete user may remain in the ata base Interface See figure 1 Deleting User User Data First name Family Name ID Phone Type Billing Nº of actions Warning messages involve in the valiation of requirements ocumentation. In this paper, a formal moel for representing a special kin of AD is shown. These iagrams inclue, for each transition, information about two important issues: risk of error an weight in terms of operation time. Risk, as a function of probability of occurrence, cost of faults an fault proneness of the elements involve in the relate operations to a eterminate transition. Weight, as the time spent by an expert user in orer to complete every action neee to execute the transition. 1.1. Formal Moel of Stanar Activity Diagrams In orer to generalize the use of ADs, we ecie to moel this kin of UML iagram as a igraph. A igraph can be efine as a short for irecte graph, an it is a iagram compose of points calle vertices (noes) an arrows calle arcs going from a vertex to a vertex. Usually an UML AD has the following three stanar elements: - Actions, which coul be of various types: occurrences of primitive functions, such as arithmetic functions, invocations of behavior, such as activities, communication actions, such as sening of signals, manipulations of obects, such as reaing or writing attributes or associations. - Decisions, which split the flow in two ifferent options ientifie by a guar. - Parallel executions, which can be ivie in forks an oins as points of beginning of parallel executions or synchronization. User interface Request user eletion Request user ID Figure 1. User interface From this stanar escription we can generate an AD like the one shown in Figure 2 each scenario of the use case can be etermine by a specific path from the initial activity to the en one an our proposal consists in using AD as the common information collector of both, the generation an ranking of test cases an the operation time measurement of each scenario. This is our reference moel for requisite specification base on applying use case (in a not ifferent way as it is usual in evelopment practice) an ADs to clarify the behavior of the system to en users an evelopers who are Cancel? No User interface Inpunt user ID No Correct ID? YES Cancel? No User Show user ata Request confirmation interface Confirm eletion YES Confirm YES Show confirmation ata No Figure 2. Activity Diagram YES
For the formalization of the efinition of an AD, the following assertions will be use: DA: Activity Diagram Ca: Path from the initial noe to the final noe. N A = {graph noes representing Activities in the DA} N D = {graph noes representing Decisions in the DA} N F = {graph noes representing Forks in the DA} N J = {graph noes representing Joins in the DA} T = Transitions in the DA, i.e., every arrow between two ifferent elements an the associate guar, if it exits. N o = Origin of an arrow. N = Destination of an arrow. Now, an AD can be seen as: G = (N, T) N= N A U N D U N F U N J U {start point, en point} T= (ege, guar) an Guar { λ, conition} being λ the empty set conition = boolean expression ege i N O i = i x N + i, Ν an, if k a) i > 1 N N J k = 1.. i N o N F k b) > 1 N o N F k = 1.. N N J 2.0 Test Case Generation an Ranking 2.1. Risk Analysis of the Use Cases Accoring with the NASA stanar STD- 8719.13-A [6] the risk is a function of the probability of an event occurs an the severity of the results of this non esirable event. In [7] the necessity of measure the risk are argue in terms of the probability of an error an the cost of it relate with economic cost an human cost. In Obect Oriente Development we shoul keep in min the relationship between Requirements, Use Cases an Test Cases which can be summarize with the following sentence: Test Cases are generate an valiate from an against Use Cases an these ones from an against requirements. So, even before of generate test cases, a stuy capable of ranking the potential test cases shoul be one in orer to get a test cases list with a priority of execution alreay assigne. The focus must be put on two ifferent areas as shown in [8]: - Expert Risk assignment: Using risk analysis tools, as escribe in [9], [7] an [10], a ranking of use case epening on the associate risk can be one. It s absolutely necessary the help of an expert who knows not only the probabilities of every scenario but the cost of an error in every alternate flow of them - Fault proneness assignment: o At Design Time: Using well known metrics riven to measure the faultproneness of esign classes in orer to rank the classes involve in every use case. o At Implementation Time: Using implementation metrics an coe revisions about coe style. 2.2. Test cases generation The application of use cases as reference for generating test cases has been treate in ifferent contributions [11]. Other work lines are base on [12] an [13]. In this case, we propose to use a test case selection criteria base on the exploration of the ifferent execution scenario, consiering a scenario as each ifferent path that coul be trace across an AD. In our metho [14], the first propose selection rule is a coverage criterion similar to the one establishe in [13]. Base on the graph theory of McCabe [15], the minimum set of paths shoul ensure that the execution trace crosses, at least once, all the arrows an eges of the graph [16]. It can be express as follows: A use case (as escribe by its AD) will be enough teste enough if the execution trace covers all the arrows or transitions in the iagram at least once. Accoring to this, five paths can be foun in the iagram of the figure 2 that can be conense in 4 types of interaction between the users an the system: Init eletion, ask for ID an Cancel Init eletion, ask for ID, introuce an incorrect ID, introuce a correct ID, eletion is confirme Init eletion, ask for ID, introuce a correct ID, eletion is cancelle Init eletion, ask for ID, introuce a correct ID, eletion is not confirme Seconly, following the traitional recommenations about black box test esign, an analysis of the omain of the input ata values shoul be one to etect ata groups or classes with a homogeneous behavior. This technique is calle equivalence classes. An equivalence class coul be compoun of a group of vali ata an a group of invali values. For
instance, if an input specification escribes a range of values, we consier two classes of invali ata (values uner an over the range limits) an a thir one that groups all the vali values. Our secon selection criterion can be escribe as follows: For each input ata action in a use case, every vali equivalence classes shoul be covere using the minimum number of test cases but each invali class shoul be inclue in a separate test case to monitor all the limit values. In orer to construct an AD with complete information about equivalence classes, we propose to introuce a sub-iagram for every activity noe ata input action is involve. In the rop user example, if we assume that a vali user i is any integer number with a maximum of six igits, the following ata shoul be consiere: 999999, 000000, A546B6, 1000000, -000001 It is absolutely essential that this information appears in the AD. UML hierarchical ADs are implemente in all commercial tools (e.g. Rational Rose) so they can be use to evelop the iagram shown in figure 3. 000000 999999 1000000-000001 no number Figure 3. Introuction of the subiagram 3.0 MTM Usability is efine as The effectiveness, efficiency an satisfaction in the way that a eterminate group of users get their goals using a system [17]. We must unerstan efficiency as the relationship between the neee resources to get a goal an the accuracy an completeness in the consecution of it. Base on this, one of the efinitive factors to evaluate the efficiency is the time the user spens to finish the task which coul be efine as operation time (the time the user nee to interact with the system) plus system time (the time the system nee to give back the expecte response. In aition, usability is one of the six main characteristics of software quality 18], so a strong relationship between operation time an software quality can be inferre. One of the most famous contributions to early measurement is the Fitt s Law [19], which is a principle of human movement publishe in 1954 by Paul Fitts which preicts the time require to move from a starting position to a final target area. The kin of motion it escribes is aime an rapi. The time neee to acquire a target is a function of the istance to the target, an the size of the target. Fitts' law is use to moel the act of pointing, both in the real worl, e.g. with a han or finger, an on a computer, e.g. with a mouse. Another important an very popular work on time measurement is the one relate with the GOMS family formal moels for user interface analysis [20] an [21]. The goal of this work is to raically reuce the time an cost of esigning usable systems through eveloping analytic engineering moels for usability base on valiate computational moels of human cognition an performance. These moels take a specification for a user interface esign an a escription of the user tasks that nee to be carrie out, an generate preictions of the time require to learn how to use the system, an the time require for carrying out specific tasks. These preictions can be use instea of empirically collecte ata for much of the esign process, thus saving consierable resources. The current moels aress the proceural quality of the interface -- the complexity, consistency, an spee of the proceures that the user must learn an execute in orer to make use of the system. These moels can help the esign prouce an interface that is reasonably usable, an then the slow an expensive empirical testing can be reserve for examining aspects of the interface not aresse by the moels, an as a final check on the esign. One of the most reference variant of GOMS is known as KLM (for Keystroke-Level Moel) [22]. In the KLM, users are assume to be experts performing routine behavior. This means no mistakes are mae, an no problemsolving activities occur. It also makes KLM- GOMS less useful for activities some amount of thought actually occurs. Actions are assume to be a mostly serial sequence of the following operators. Times taken from [22] are shown in table 1. These times coul be more accurate taking into account the profile of the user (expert, meium, basic) an all of them are etermine empirically an valiate by statistical controls. In the inustry, the work ivision on elemental tasks in orer to improve the performance of assembly line has been stuie since the early XX century.
K Keystroke 280 msec T(n) Type n characters P Point with mouse to something on the isplay 280*n msec 1100 msec B Press or release mouse button 100 msec BB Click a mouse button 200 msec H Home hans, either to the keyboar or mouse 400 msec M Mental, thinking 1200 msec W(t) Waiting for the system to respon t msec Table 1. KLM operators from Kieras As a result of the works of Taylor [23] an Gilbreth [24] which were oriente to the evelopment of machinery an operator knowlege, an using the experience accumulate uring more than fifty years, several stanars were evelope to preict times in assembly lines. Two of them are MTM [25], [26] an Work Factor [27]. Our work starts applying a mixture of both to a eterminate activity in a software specification iagram. With the help of an expert in traitional MTM all the possible interactions between a human an a computer program have been stuie iviing them in basic elements an esigning a tool for ata collection. After that the time neee for every element was calculate an a table with all this times measure in (Time Measurement Unit; =1/100.000 hour) was built (Table 2). PU1T Keystroke Initial Conition: Hans on rest BE Space bar 15.1 IT Enter key 21.6 ES Scape key 19.0 ES Special $, % & @ 32.6 PUTE Type something Initial Conition: Hans on keyboar EN Normal Typing 4.0 SE Special Punctuation Signs 11.4 FD Arrow keys 14.8 LETX Rea Something 1P First wor of the text 7.3 TR Rea an translate 11.6 SP Following wors 5.0 LLPU Point with the mouse Initial Conition: Han on Mouse PP0 PE02 Exact Position 2 cm 4.0 2 Accuracy 2 cm 9.6 PE04 Exact Position 4 cm 6.0 PP0 4 Accuracy 4 cm 11.6 CO1O1M. Get an obect 16 Ob at 16 cm from us 10.8 30 Ob at 30 cm from us 14.8 20 Ob at 20 cm from us 12.0 CS1O1M. Get an obect an place it again in other location Get an Move Ob at 16 cm 16 from us 22.0 30 Get an Move Ob at 20 cm 20 from us 24.5 Get an Move Ob at 30 cm from us 30.1 SMST2M. Place both hans in some (keyboar). Left han on rest, right han on mouse 16 Keyboar at 16cm 10.8 20 Keyboar at 20cm 12.0 Table 2: Propose times for basic movements on software applications
To en with the stuy, in one han, a mental element, mentione in Work Factor, was inclue to taking into account those mental process that on t imply a physical motion or change. An, in the other han, a set of important auxiliary elements in software artifacts were taking into account (table 3). Now, we are reay to assign a time measurement to every transition in the AD epening on the basic elements involve in its consecution. ET Eye Movement =15.2*T/D PM Max 20 UMT. 4.0 EF Eye focus 7.3 G2 Get Control 5.6 TD CLIC Click on Mouse 2.0 Mental Process. Time to react if the operator is not aware 3.3 Time to take simple ecisions 3.3 Reflection Process, GC45 45º hea turn 6.7 PR Time to memorize an GC50 50º hea turn 10.0 remember later 3.3 Table 3: Propose auxiliary elements 4.0 Formal Moel of Extene Activity Diagrams Once we know the way to generate an rank test cases an the way to evaluate the operation time, an extene formal moel for ADs is neee to express formally an algorithm to get the esire results but it s necessary to start from these three restrictions: - A well-balance AD [4] shoul be use as starting point. - Let s consier an acyclic AD. As far as we are concern, it s necessary to ensure that every noe in the AD is visite at least once. Two types of loops can be foun in a AD. Those the probability of any number of cycles are the same an those the probability of a new cycle is ecreasing. First type of loops can be simplifie as a new alternate path with a fixe probability. The probability of the secon one shoul follow a Poisson istribution. - The probability of executing a transition is inepenent from the previous one. In aition an in orer to simplify the algorithm, in this paper, the fault proneness stuy is omitte. The affecte elements are the following: N A = {graph noes representing Activities in the DA plus the list of ata to be consiere} In other wors: N A = N A x ata * x OT ata = (i, value * ) * represent the Kleen closure use in regular expressions an OT = time spent by an expert user to complete an activity measure in So, now G = (N, T ) : N= N A U N D U N F U N J U {start point, en point} T = (ege, guar, P, C) i + ege N O x N i, Ν i = i an, if k a) i > 1 N N J k = 1.. i N o N F k b) > 1 N o N F k = 1.. N N J P = Probability of a transaction calculate as: if ( n o, m) N D xn P = 1 if ( n o, m) N D xn 0 < P < 1 n P i = 1 si {( n o, m )...( n o, m )} ege i = 1 1 n ( n0, m ) ege i {1.. n},, = i C = Cost of an error in the transition, calculate as: if ( n o, m) N D xn C = 0 if ( n o, m) N D xn 0 C 5 Base on this, it s possible to write two algorithms, one for generation an rank of paths in the AD (Test Cases) an another for operation time evaluation.
4.1. Test cases generation algorithm 1. Generate an AD, restrictions compliant, for each use case. N ' N ' A N = N x ( 1, n )x OT an n 0 a. Assign values to attributes (P, C), using the techniques shown above. b. Buil a sub-iagram each input ata value is inclue (figure 3) an ecision noes referre to correctness of input ata isappear. So, ( i, vi) ata *, create : a new noe Ni a new transition t = (( N, Ni ), ( i = vi), P, C ) an t = (( No t, N t), gt, Pt, Ct ) T gt = ( i = vi) an ( i, vi) ata * elete t 2. Let S the set of ifferent paths existing in the new AD. p S let Tp the set of transition s in p let TD Tp, such as t = ( Not, Nt, gt, Pt, Ct ) TD : No t ND calculate the probabilit y of p as P ( p) = Pt t TD an calculate the cost of p as C ( p) = Max t TD ( Ct) 3. Rank the paths (Test Cases) use the risk of every path as a function f (P(p), C(p)). 4.2. Operation Time evaluation algorithm The calculation of the operation time is now quite simple. Let s see the following algorithm: 1. Generate an AD, restrictions compliant, for each use case. N ' ( N N ' D) a. Divie the action represente by N in basic elements. b. A software analyst must o an inspection of the user interface to calculate the OT of every element accoring tables 2 an 3. 2. Let S the set of ifferent paths existing in the new AD. Let s istinguish between two kin of paths p S let Np the sorte set of noes in p, Npi is the initial point an Npf the en one 1 n = ( Nn, ata n, OTn ) Np n Nf U N calculate the operation time of p as OT ( p) = OTn n Np 2 n = ( Np, ata p, OTp) Np such as n Nf let p = ( P', Pp, P' ' ) P ' is the path starting at Npi an ening in n let Pp the set of parallel paths starting at n P ' ' is the path starting at the last n Np N an ening in Npf let Np ' the sorte set of noes in P' an let Np ' ' the sorte set of noes in P' ' an calculate the operation time of p as OT ( p) = OT ( p' ) + OT ( Ppi) + Tcc * ( Pp 1) + Ppi Pp OT ( p' ' ) Tcc is a constant representingthe time neee by the user to change from one parallel path to other P p is the number of parallel paths of p 5.0 Conclusion In this paper, a formal moel for UML AD is propose an two of the many potential application of it, have been presente. But, from our point of view, the most important contribution is the formalization of the UML AD an its extension to the extene AD. The algorithms shown above shoul be taken as goo examples of the utility of using a formalization of UML artifacts an how these artifacts can enhance the esign process from software requirements as seen in previous works of the authors [8]. In other sie, it seems to be quite possible to establish a correlation between operation time an risk. Let s see these two reasonable arguments: - The cost of failure in an activity, in terms of user tolerance, is proportional to the operation time of it. - The longer the user interacts with the system the more likely he will make a mistake. Now, we nee a tool to emonstrate it empirically an the extene formalism coul be this tool. Future works are planne to exten the formal moel in orer to get a fully stuy of the risk.
This relation explaine in the previous paragraph an fault proneness analysis omitte before must be one extene this formalizations or, even, escribing new formal moel for other artifacts like collaboration iagrams, a relationship between classes on the classes iagram an scenarios on the use cases escription shoul be taking into account to a values of fault proneness to the evaluation of activities risk. References [1] Pressman, R.S., 2002. Software Engineering. A practitioners approach. McGraw-Hill, NY, USA, 2002. [2] Booch, G. et al., 1999. The Unifie Moeling Language User Guie, Aison- Wesley, Upper Sale River, USA. [3] Jacobson, I., et al., 1999. Unifie software evelopment, Aison-Wesley, Upper Sale River, USA. [4] OMG, 2001, Unifie Moelling Language Specification, version 1.4. [5] G. Schneier y J. P. Winters, Applying Use Cases. A Practical Guie, Aison- Wesley, 2001. [6] NASA, 1997, NASA Technical Stanar 8719.13A, Software Safety. [7] Hutcheson M.L., 2003, Software Testing Funamentals, Wiley Publishing Inc. 2003. [8] Fernanez an Lara, 2004. Meora e la calia en esarrollos orientaos a obetos utilizano especificaciones UML para la obtencion y preceencia e casos e prueba, AEMES, Spain. [9] Wang T., Hassan A., Gueem A. Abelmoez W., Goseva-Popstoanova K, Ammar, H., 2003, Architectural level risk assessment tool base on UML Specification, Proceeings of the 25 th International Conference on Software Engineering (ICSE 03) [10] Goseva-Popstoanova K., 2003, Architectural-Level Risk Analysis Using UML, IEEE transactions on software engineering, vol. 29, nº 10, octubre 2003, pp. 946-960. [11] Fernánez, J.L., 2000. Utilización e casos e uso en las pruebas e aceptación. Actas e las V Jornaas e Innovación y Calia el Software, San Sebastián, Spain, pp. 65-76. [12] Choi E.M. an von Mayrhauser, A., Testing obect-oriente systems using extene usecases, PDPTA Conference, vol. 2. [13] Memnon, A.T. et al., 2001. Coverage criteria for GUI testing. 8th European Soft. Engineering Conference (ESEC) & 9th ACM SIGSOFT Intern. Symp. on the Founations of Soft. Eng. (FSE-9), Vienna, Austria. [14] Fernánez, L. an Lara, P., 2003. Generación e casos e prueba a partir e especificaciones UML. Actas e las VIII Jornaas e Innovación y Calia el Software, Barcelona, Spain, pp. 48-58. [15] McCabe, T.J., 1976. A complexity measure, IEEE Trans.s on software engineering, vol. 2, pp. 228-363. [16] Myers, G.J., 1979. The art of software testing. Aison-Wesley, New York, USA [17] Garcia Barriocanal, E. Tesis octoral: Propuesta e un moelo e conocimiento para el uso e cuestionarios en la evaluacion e la usabilia, Universia e Alcalá e Henares, Abril 2004. [18] ISO, 1991. Information technology. Software quality evaluation characteristics, ISO, Geneve, Switzerlan. [19] Paul M. Fitts (1954). The information capacity of the human motor system in controlling the amplitue of movement. Journal of Experimental Psychology, volume 47, number 6, June 1954, pp. 381-391. (Reprinte in Journal of Experimental Psychology: General, 121(3):262--269, 1992). [20] Kieras, D. E.. A Guie to GOMS moel usability evaluation using NGOMSL. In M. Helaner, T. Lanauer, 1997 an P. Prabhu (Es.), Hanbook of human-computer interaction. (Secon Eition). Amsteram: North-Hollan. 733-766. [21] Bonnie E.J. an Kieras D.; Using GOMS for User Interface Design an Evaluation: Which Technique?; ACM ToCCHI, 1996 [22] Kieras D. Using the Keystroke-Level Moel to Estimate Execution Times, Univ. of Michigan; ftp.eecs.umich.eu/people/kieras/, 2001 [23] F. W. Taylor, The principles of Scientific Management, Harper & Brothers, Nueva york, 1911, 144 páginas [24] Gilbreth, F.B., Memoria presentaa en la reunión aunual e la American Society of Mecanical Engineers; New York, Dic. 9-5- 1921 [25] Maynar, 1975, Manual e la ingeniería e la proucción inustrial; H.B. Maynar; E. Reverté S.A., 1975; ISBN: 84-291- 2670-8 [26] Ralph, 1970. Estuio e movimientos y tiempos; Ralph M. Barnes; E. Aguilar S.A., 1970 [27] Joseph H. Quick et al. Work-Factor Time Stanars, McGraw-Hill Book Co., New York, 1962