Development of Graphical User Interface by Applying Philosophy of Use Case Maps Ebitisam K. ELBERKAWI *, Mohamed M. ELAMMARI ** * Academy of Graduate Studies, Benghazi, Libya
[email protected] **Faculty of Information Technology, Garyounis University, Benghazi, Libya
[email protected] Abstract: Graphical User Interface (GUI) development is as important as other aspects and phases of programming, as GUI elements are typically the only means by which the user interacts with the program. Thus, even if the functionality of the application is perfectly executed, if its GUI is difficult to use, this can result in an implementation failure. In such cases, the user will switch to another application, which is easier and more flexible, even if its internal functionality is inferior. Therefore, the GUI must primarily be user-friendly, and must be built on strong foundations and pillars. This paper introduces an approach for designing GUI based on a model that offers visual description of high-level system logic—Use Case Maps (UCMs), which is utilized in three phases. Keywords: Graphical User Interface, Use Case Maps.
1. Introduction There is no doubt that the role played by the Graphical User Interface (GUI) in making systems more successful is very important. In practice, it is not uncommon for strong performance systems to fail at their implementation stage due to the shortcomings in their GUI. The GUI is the interface between the user and the system and thus plays the key role in the application acceptance. In short, although GUIs typically include less complex elements to develop, they are critical to the success of the system. Moreover, given that their acceptance relies on user preference, they are often the hardest part of the system to develop. Thus, GUI designers and programmers must achieve a high degree of cooperation in the design of GUI. Analysis and design phases are integral part of project life cycle and they must incorporate GUI from the inception. In addition, user input is essential aspect of GUI construction and design. This paper presents an approach to GUI design that is based on the primary phases of system development and supports the role of the user. Such approach increases the chance of cooperation between the GUI designer and programmer as well as ensures that the final product meets user requirements. In this paper, we focus on the design of GUI through Use Case Maps (UCMs) as one of high-level models. The approach proposed in this paper is composed of three phases, starting from UCMs and ending in GUI: the first phase (Responsibility Analysis) produces a Responsibility Diagram (RD); second phase (GUI Design) produces GUI Design Tables (GUI_DT),
which contain all details of designing the GUI; and last phase (GUI Development) produces the GUI. The rest of the paper is organized as follows: Section 2 gives a summary of some pertinent literature, where key findings and comparisons of these works are discussed. Section 3 describes the three phases of our GUI design approach in more detail. Its implementation was further elaborated on through a case study in Section 4. Finally, Section 5 presents discussion, followed by the key conclusions and recommendation for future works.
2. Literature Review Most of the extant studies related to our work focus on achieving GUI design using Unified Modeling Language (UML), as was done in works [4,5,7]. There is also some evidence [4,7] of a GUI design through Use Cases. Thus, it is worth to briefly elaborate on the role of Use Cases and system details they present, which is at the level of the system functions from viewpoint of external actors. On the other hand, work by Almendros-Jim´enez and Iribarne [7], focus has been made on the relation without knowing the role of the relation , as each of these two relations has an important role in Use Case Model. Moreover, Pinheiro and Paton [5] focus on UI modeling by means of UML. Within this work, we have seen strong and weak aspects in the UML and have identified their respective roles in UI modeling. Same authors in [6] primarily focused on the aspects of GUI that are not covered by UML. Hence, they introduced additional notation when designing Interactive Applications. Thus all previous attempts to
dessign a GUI hhave both addvantages an nd disadvanttages and d, in generall, most depeend on Use Cases. Thuss, the aim m of this w work is to design a general g apprroach thrrough whichh GUI is deeveloped, ussing UCMs as a hig gh-level moddel . Th he main advaantage for seelecting UCM M for the deesign of GUI is bassed on its many m advan ntages, incluuding hig gh-level design view, combining g structure and beh havior in oone view inn a graphicaal, and easyy to understand wayy, in additionn to its comp pact form, w which pro ovides wealthh of informaation [1, 2]. Mo oreover, an important and a useful linkage l betw ween UC CM and manny kinds of diagrams d forr one of the m most known modeliing languagges, namely UML, cann be esttablished. UC CM acts as an a intermediary betweenn Use casse diagramss (UCDs), which w descrribe the syystem witthout any deetails (Blackk-Box), and other behavvioral diaagrams, whiich describee more dettails that m make understanding the system very difficcult (Glass-B Box). Mo oreover, UC CM providess a link betw ween behavvioral diaagrams and sstructural diaagram. In th his respect, U UCM can n be perceiveed as Gray-B Box [3], as itt bridges thee gap bettween requuirements and desig gn. Based on afo orementionedd features and sup pport for the com mpetence off UCM, it has h been selected to bee the bassis from whiich the GUI will w be develloped. UC CMs are precise strucctural entitiees that conntain eno ough inform mation in highhly condenseed form to ennable a person p to visuualize system m behavior. UCMs U (as shhown in Figure 1) provide a high-level view of caausal seq quences in tthe system as a whole, in the form m of patths, which arre known as scenarios. In n general, UC CMs maay have manny paths (for simplicity,, the figure only sho ows one). A Although thee causality expressed e byy the patths is undderstood byy humans, this may not neccessarily bbe the casse for ind dividual sy stem com mponents.
Th his is a very common chharacteristic of the typess of sysstems with which w we aree concerned and results in i a patth-centric sy ystem view, rather than a conventioonal com mponent-cen ntric view.
3. The Apprroach Th he approach proposed in this paper comprises c thhree phaases. In the first phase, rrules are app plied to UCM Ms, wh here the RD will be gennerated. Thee second phhase inv volves apply ying rules too RD, wheree we will have con ntents of GU UI_DT in theiir different kinds. k In the last phaase, contentts of the GU UI_DT are converted into i theeir corresponding GUI elements, resulting inn a com mplete GUII with all oof its elemeents. Thus, the eleements of GUI G coveredd in our work w are Form, Bu utton, Textbo ox, Label, andd List. Figurre 2 and Tablle 1 claarify the app proach phasees and their relationship,, as weell as the professionnal in ch harge for the implementation n of each phaase.
Figure F 2: The A Approach Phases. Table T 1: The Ap Approach Phasess. Phase Name
Availability oof
Descriptio on
Result
Responsibility Analysis
UCM
Apply ruless to UCM
RD
Fiigure 1: Exam mple of a UC CM. A filled circlee indicates a start-pointt of a path— —the point where sstimuli occuur, causing activity to start pro ogressing aloong the path.. Similarly, a bar indicatees an end d-point—thee point where the effecct of stimulii are fellt. Thus, pathhs trace causal sequencees between sstartand d end-poinnts. The causal c sequ uences connnect ressponsibilitiess, indicated by b named po oints along ppaths (e.g., r1, r2 and r3). Paths P are su uperimposedd on recctangular boxxes represennting operatio onal componnents of the system ((e.g., C1, C22 and C3), to indicate w where com mponents pparticipate in the cau usal sequennces. and Ind dividual patths may crooss many components c com mponents maay have manny paths crossing them. Th he basic aassumption is that sttimulus-respponse beh havior can be representedd in a simplee way with ppaths.
m Of the system GUI Design
RD
Apply rules to o RD
GUI_ DT T
GUI G Development
GUI_ DT
bles Convert tab into design off GUI
GUI
3.1 1 First Phase: Responnsibility An nalysis 3.1 1.1 Rules A number of ru ules have beeen proposed d, dependingg on thee importance of input,, processing g, output, and a intteraction with h the user foor each respo onsibility of the UC CM. In this context, the re responsibility y refers to tassks,
actions or functions to be performed. This distribution of responsibilities was the basis of construction of most rules presented below, with the aim to achieve the desired results through application. Rule 1 A component in UCM is a form, where this component contains at least one responsibility that requires GUI elements. Rule 2 Sequence of forms is based on the sequence of components in UCM. Rule 3 A responsibility will be considered if it requires GUI elements for: • Obtaining required input for implementing its work • Executing its work • Showing the output resulting from implementing its work • Interacting with the user to show him a message Rule 4 A responsibility that needs GUI elements for its input must have: • (X) text boxes • (X) labels • (2)buttons (‘Ok’ and ‘Cancel’ button) where X is a number dependent on the number of data inputs. Rule 5 A responsibility that requires GUI elements for executing its work must have: • (1) button (Execute Button) Rule 6 A responsibility that requires GUI elements to display its output must have: • (Y) lists • (Y) labels where Y is a number dependent on the number of resulting outputs. Rule 7 A responsibility that needs GUI elements for interaction with the user is a separate form containing a message with a button the function of which is to close the display form. Rule 8 If a responsibility requires a sub-input based on essential input (Multi-input), then, an independent form is generated to receive additional input using the same input rules as defined in Rule 4.
Rule 9 If a responsibility requires a sub-output based on essential output (Multi-output), then, an independent form is generated to show additional output using the same output rules as described in Rule 6. Rule 10 The main form of the system is generated based on forms obtained from above-mentioned rules, i.e. using (Bottom_Up) approach. Rule 11 For each main form, there is an ‘Exit’ button and a ‘Return’ button for each sub-form. Rule 12 Applications of specific graphical user interface [13], such as ATM system, require no main form and no ‘Exit’ and ‘Return’ buttons. This type of systems has relay forms with no need to return to the main form to select a specific form. Accordingly, a ‘Welcome’ form is displayed in the beginning of user interaction, which is followed by the remaining forms. Rule 13 Cases that require more than one scenario represented by static stub notation using (Or) relation are translated into a number of buttons equal to the number of scenarios, where each button may cause moving to the form of the chosen scenario.
3.2 Second Phase: GUI Design 3.2.1 Responsibility Diagram (RD) RD is a diagram the notation of which has been built and especially designed to show what may result from the process of applying rules to UCMs. Table 2 explains RD notation. Table 2: RD Notation. R
Responsibility
(P)
Responsibility needs GUI elements in process
Responsibility needs GUI elements in input
(I)
(O)
Separation of Components
Responsibility needs GUI elements in output
Interaction with User
Responsibility needs output many times
(I )
Responsibility needs input many times
(O)
(I)
Responsibility needs already available GUI elements in input
Responsibility needs already available GUI elements ( O ) in output
Output from first responsibility used by another Responsibility dependent on another
S# N
Stub number (S#) and name (N)
3.3 Third Phase: GUI Development 3. General Design of Prerequisites Tables
3.3.1 GUI Design Tables (GUI_DT) As a result of the previous phase, i.e. applying rules to RD diagram, all necessary information about required GUI is obtained and is sorted into tables called GUI_DT. These tables are classified into four types, each providing information on the aspect of the GUI design required. Table 3 provides a list of these four tables and the corresponding explanation of their general design. The four tables presented are: 1. 2. 3. 4.
Components State Table GUI Elements Tables Prerequisites Tables Interactions Tables Table 3: General Design of GUI_DT. 1. General Design of Component State Table
Number: One table for each system. Explanation: In this table, there is an illustration for each component of the system UCM, required to design a GUI, in terms of whether this component has or does not have the following: • GUI elements in accordance with the contents of this component of responsibilities that require them. • Interaction with the user by showing him/her a message based on the responsibilities that require interaction. The meaning of symbols and figures Symbols X Indicates possession. - Indicates no possession. Figures None
Number A number of tables equals to GUI Elements Tables. Number of Prerequisite tables = Number of GUI elements tables
Explanation In these tables, the prerequisites that must be met for each responsibility that requires GUI elements is clarified, in terms of whether the prerequisite is relative to another responsibility and its location, as well as the component and the type of this relation. The meaning of symbols and figures Symbols
↑ ↔
Relative to responsibility in previous component Relative to responsibility in the same component
Figures None 4. General Design of Interactions Tables Number A number of tables equals to the number of components that interact with the user and are thus described by Component State Table. Therefore, the number of these tables is equal to or less than the number of components of the system that GUI is designed for. Number of interaction tables 2000, 3rd Intternational Co onference on the Unified Modeling M Lannguage, LNC CS 1939, 16--31, York, UK, 2000. [3]] Amyot, D, Use Case M Maps and UM ML for Compplex Software-D Driven System ms, Unpublisshed, Onlinee at http://www w.usecasemapss.org/pub/uml99.pdf 1999. [4]] Elkoutbi M. M and Kelller R. K., “User Interfface ML Scenarioss and High-Leevel Prototyping g Based on UM Petri Nets,” In 21st International Conference on Application n and Theoryy of Petri Netts (ICATPN '000), pages 166-186, 2000. [5] Pinheiro da Silva P.. and Paton n N.W., “U User
Interface Modeling with UML,” Informattion Modeling and Knoowledge Baases XII, H. Jaakkola, H. Kangassaalo, and E. Kawaguchi, K eds., IOS Press, pp. 203–21 7, 2001. [6]] Pinheiro daa Silva P., Paaton N., “UM MLi: The Unified Modeling Language L forr Interactive Applications,” A ” In Proceeding gs «UML» 20000, Evans, A., Kent, S. (E Eds), LNCS, Voll. 1939, 117-1132, Springer-Verlag, 2000.. [7] Almendros-Jim´enez J. M M. and Iribarn ne L., “Designning GUI Comp ponents for UM ML Use Casees,” In 12th IE EEE International Conferencce and Worrkshops on the Engineering of Computeer-Based Systtems (ECBS’005), pages 210– –217, IEEE Coomputer Socieety Press, 2005. Weeb Sites [8] Http://www w.earlyimpact..com/productccart/shopping-cart-softwaare-101.asp.(077/2010) [9] Http://www w.eshoppinginndia.com/info//onlineshopping-g guide.html.(077/2010) [10 0] Http://www w.indiaplaza.inn/quickstep.asspx.(06/2010) [11 1] Http://www w.tesco.ie/easyySteps.htm. (0 07/2010)
