Component-Based Development in J2ME: A Framework for Graphical Interface Development in Mobile Devices Leandro Marques do Nascimento 1, Leonardo Amorim de Barros 2, Eduardo Santana Almeida 1, Silvio Romero de Lemos Meira 2 1 Recife Center for Advanced Studies and Systems C.E.S.A.R Recife PE Brazil 2 Informatics Center Federal University of Pernambuco (UFPE) Recife PE Brazil {lmn2,lab2,esa2,srlm}@cin.ufpe.br Abstract. In high-growth markets such as those that depend upon Java 2 Micro Edition (J2ME), application development with quality in a reduced time has become crucial for success. However, the diversity of handsets with this technology implies in many ports of every application, mainly in aspects related to Graphical User Interface (GUI). This paper describes the development of a framework for creating GUI in J2ME, reducing codification effort and usually producing more attractive applications. This framework was developed using a Component-Based Software Development (CBSD) method adapted for the J2ME context; both the CBSD usage and the modifications are described in the paper. 1. Introduction Java 2 Micro Edition (J2ME) [10] is being reveled as a good business opportunity for mobile phone companies. According to the site 3G Americas [1], 25% of J2ME users increase their monthly bill from 5 to 10 dollars due to the applications usage. As this market is in constant growth, there is a great demand for more applications to be developed in less time and, in this way, software reuse techniques become essential, such as Component-Based Software Development [2] (CBSD). However, an important feature in J2ME technology is the reduced number of unnecessary features, maintaining the smallest number of components and functionalities. Then, if some application tries to use only the native API available for developing GUI in J2ME, probably it will not get an attractive visual aspect. To reach this objective, the application must use low level graphical components, which are based on painting the screen pixel per pixel, using pre defined images, or, at most, using graphics primitives such as: line, square or circle, for example [10]. If so, the development becomes hard and time consuming. In this context, the purpose of this paper is to create a framework that encapsulates basic graphical components in order to decrease software development time, excluding low level API usage, and increase the applications quality, adding a more attractive visual aspect to them. This paper is organized as follows: Section 2 presents briefly a background of software reuse, software components and CBSD methods. Section 3 describes the case study with the framework description and the UML Components method adaptations to J2ME context. Finally, the Section 4 presents the concluding remarks and future directions.
2. Software Reuse and Component-Based Software Development (CBSD) Software reuse concept is, at most times, related to software components. One well accepted definition for software component is the Szyperski s [16]: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. (pp. 41). RiSE 1 has adopted this definition in its work and it will be used across this paper for other citations. 2.1. CBSD Methods The development of software components demands a systematic approach, just as any other software process. Thus, using methods or processes for this kind of development eases the construction of more complex systems that integrate all parts. In this way, it can be reasonable the great number of research in this field that result in some CBSD methods [14]. Some of these methods are extensions of others already existent, which use the Object-Oriented (OO) paradigm. Among the cited methods, it can be widely found in the literature: Catalysis [6], Rational Unified Process (RUP) [9], Select Perspective [8], and UML Components [3]. Based on Stojanovic s et al. [14] research, UML Components was chosen to construct the proposed framework because it has large documentation with easy access; it is easily integrated with UML through stereotypes, which have tool support, such as, Jude 2 and Poseidon 3 ; and, finally, it is well accepted by industry and academy [4]. 2.2. UML Components There are many different extension mechanisms for UML, but, probably, the most used, according to Cheesman and Daniels [3], are the stereotypes. In its original version [12], UML allows that any element in the diagram has a stereotype attached, facilitating the language extension. There are six stereotypes of UML Components that can be added to entities in a typical UML diagram [3]: Type (<<type>>); Datatype (<<datatype>>); Interface type (<<interface type>>); Component Specification (<<comp spec>>); Offers (<<offers>>); and Core (<<core>>). 2.3. UML Components Process: Overview Cheesman and Daniels [3] defined a workflow for component development based on RUP. The workflow has the following activities: Requirements, Specification, Provisioning, Assembly Test and Deployment. They correspond directly to RUP activities except for the Specification activity, which will be the paper focus and is where the UML Components concepts are applied. This activity is divided in three phases: Component Identification, Component Interaction, and Component Specification. 1 Reuse in Software Engineering Group RiSE. Available on http://www.rise.com.br. 2 Jude UML Modeling Tool. Available on http://www.esm.jp/jude-web/en/index.html. 3 Gentleware Poseidon UML Modeling Tool. Available on http://www.gentleware.com.
Through the following Section 3, the UML Components process was applied to construct the proposed J2ME GUI framework. Then, the three phases of Component Identification (Section 3.1.1), Component Interaction (Section 3.1.2) and Component Specification (Section 3.1.3) were adapted. 3. Defining the Framework Developing user interfaces for small devices such as cell phones, pagers, PDAs, and so forth presents much more of a challenge. These devices have an even more restrictive user interface. The display capabilities of these devices may be restricted to a screen that is only an inch or two wide. Often, these devices are utilized with one hand and without the full attention of the user. Therefore, even simple pointing devices may not be available for user input. According to some J2ME technologies, such as MIDP [11], PersonalJava [13] and SuperWaba [15], a well designed GUI framework should provide high-level and low-level APIs. A high-level API is intended for business applications and provides abstraction from low-level graphics management and placement of graphical elements. The high-level API provides a series of widgets or predefined graphical elements that can be added to and used on a display. With the high-level GUI API, the device, and not the application, handles the layout, scrolling, navigation, and visual characteristics such as color, shape, font and painting of the elements on the display. Some of the common high-level components available on the earlier mentioned J2ME technologies are: A standard adaptable screen. It presents a screen for the target device with a title bar (with text and an icon), a space in the middle of the screen to allow customized items to be added, command buttons at the bottom left and right and a context menu button between this two command buttons; A standard form. It encapsulates a set of standard items to handle the user s input, such as text fields, text areas, list boxes, check boxes and labels, for example; A screen message. It is an extension of the standard adaptable screen used to display a text to user, such as the application help; A popup. It is used to display short messages to the user, such as warning, error or information messages, using as background a standard adaptable screen. Alternatively, in the low-level GUI API, the application has much more control over the display. This API was developed for applications such as games where the precise control and placement of graphical elements is required. In the low-level GUI API, a series of drawing methods allow the applications to create the display, shape by shape, if necessary, and paint it to the screen. 3.1. Applying UML Components UML Component defines two kinds of contracts established between framework entities: usage and realization. The usage contract is the one between a component object s interface and its clients. The realization contract is the contract between a component specification and its implementation.
To use UML Components on the framework construction, it is necessary to make some adaptations. One of the suggested adaptations is: consider the association between the <<core>> type and the <<interface type>> stereotype to indicate a realization contract. During the GUI development in J2ME, it is mandatory to handle events triggered by the user. So, a component that will be used for the construction of different graphical interfaces can not preview how the triggered event will be handled. Thus, this component should establish a realization contract with the other part that will use it. For better understanding realization contract, the low level J2ME API, Canvas class, available for constructing GUI can be used. The API contains methods to treat events that happen when the user presses or releases a device key. These methods bodies must be implemented by the class that extends Canvas or by the class that will extend the framework components. Another suggestion for adaptations is to consider the type <<core>> that does not have any association with an <<interface type>> stereotype to indicate a usage contract. It means the <<core>> entities without an association with a <<interface type>> can be used directly by the other parts, which do not have to extend the component behavior. Other adaptations are suggested in the following sections. 3.1.1. Component Identification In this phase, the steps to be followed are: identify system interfaces and operations; identify business interfaces; create initial component specification and architecture; specify component architecture. Considering that there is no use case specification for the framework and this artifact is used to identify system interfaces and operations then this step will not be performed. After constructing a business concept model and refining it to determine which the core types are, Figure 1 shows the result obtained. The business type model reflects the requirements necessities. CustomScreen entity represents the standard adaptable screen with two command buttons (Button) and a context menu (ContextMenu). CustomForm is the standard form that can receive items of the type CustomTextArea, CustomTextField, CustomCheckBox, CustomLabel, CustomListBox and CustomRadioButton. CustomMessage represents the message on the screen with a possible scroll bar. CustomPopup is the popup with a CustomScreen as background. After identifying core types, the next step would be to identify business interfaces. However, this step should be adapted for this framework. Figure 1. Business type model with core types identified.
UML Components consider interfaces as the description of a service provided by a specific component. In this particular case of J2ME GUI framework, the components are not service providers, but entities that have a predefined behavior to be reused or extended. As said in Section 3.1, the core types that need to be extended by third parties have an association with a <<interface type>> stereotype. Thus, the operations in the entity that uses the <<interface type>> stereotype are those which need to be extended by third parties, establishing a realization contract. The initial interface specification adds the paintcontent method in ICustomScreen interface type (Figure 2). This method is responsible for painting the screen middle space. The two entities which extend CustomScreen have the operation implemented. 3.1.2. Component Interaction Figure 2. Initial interface specification. The main goal of this phase is to discover the business interfaces operations and its respective signatures. For the framework, it was considered that <<core>> types encapsulate the stereotypes <<interface type>> for the case of usage contract. Then, the operations related to the <<core>> types will also be analyzed. An adaptation in the process should be made to reach the goal of this phase. In this way, a unique step will be performed: analyze in details the initial design of the framework and find operations relative to the types <<core>> and <<interface type>>. Figure 3 shows the analysis result. 3.1.3. Component Specification This phase is focused on producing the interface information model and building the component specification model. According to the UML Components process, three steps should be followed in order to reach this goal: (I) define interface information models; (II) specify pre/post-conditions; and (III) mount the component specification. The first step is not applicable to this case study because the interface, defined by the stereotype <<interface type>>, is already associated with a <<core>> type, which already has the information present in this model. It means that Figure 3 already contains the interface information model. Also, the second step is also not applicable to this case study because it is used for systems that have well defined business rules. Usually pre/post conditions are extracted from the use case specifications and it is not the case of the framework.
Figure 3. Operations definition for the framework with its respective signatures. Finally the third step can be performed getting as input the framework operations definition (Figure 3). Figure 4 displays the result of this phase. 3.1.4. Framework Results Figure 4. Framework component specification. The framework was codified with approximately 5749 lines of non-commented source code (NCSLOC) in a total of 15975 lines of code. The final Java Archive (JAR) file has 52 KB. Considering that a J2ME application could use 150 KB, then the framework would use 34% of the total application space, leaving the missing 98 KB available for development of the entire application. Also, the framework was well documented to provide a useful API. It can be realized by observing the comments percentage: 57% of the total number of lines in the framework are comments. A simple application (Figure 5) used as example was developed reusing the framework and its final size was 72 KB, including images, with 407 NCSLOC. The images were used to give the application a more customized visual aspect. However, it is possible to create an entire application without using images and the framework will adapt all application screens to the available size of the handset display. To make a comparison, J2ME Polish [7] was used to generate some screens. The tool uses generic MIDP configurations and also specific configurations for different devices. The tool facilitates in screen construction and flow control, but still does not allow the customization, as it is possible with the framework, because it uses MIDP API, which is restricted by the handset capabilities.
This framework has been used and maintained by C.E.S.A.R in some Motorola iden 1 projects. For now, the development team responsible for the framework is considering it as a potential way of reducing the projects time. There are three reasons for this reduction: Reduced number of code inspections. As C.E.S.A.R. is applying CMMI 3 practices, then code inspections are mandatory. All framework components had passed through a formal inspection, and every new project which reuses the framework does not need to inspect the code again. According to the Software Quality Assurance Team, the time used for code inspections is about 10% to 20% of the entire project time; Reduced number of bugs. As the components are being reused across many projects, the number of bugs per line of code is reduced; Reduced codification time. Considering the learning curve time, developers take from 10% to 15% less time to implement new functionalities. This value can be observed through a time control tool used in the organization. Figure 5. Screens constructed from the framework. 1) Standard adaptable screen. 2) Standard adaptable screen with active context menu. 3) Standard form with CustomTextField and CustomCheckBox components appended. 4) Popup with a visual effect applied to the background screen. 5) Message screen with a scroll bar. 6, 7 and 8) Examples of standard MIDP screens. 4. Concluding Remarks and Future Directions This paper described the development of a framework which is responsible for creating GUI in J2ME, reducing the codification effort and producing a more attractive visual aspect of the application. To guide all the development phases, it was used a CBSD method (UML Components), which helps in the construction of a well-structured and 1 Motorola iden - Integrated Digital Enhanced Network. Available on http://idenphones.motorola.com.
modeled framework with more quality. During the method application, some suggestions have been made to adapt the process to the J2ME context. The main contribution of this paper is aligned with the purposes of MIDP 3.0, currently on development, which aims to follow the idea of using components in J2ME applications, as it was published at JavaOne 2005 [17]. This new version allows installing a set of components in a handset and, after that, any other application installed in that handset would reuse those components. As a future work, the framework would include Generative Programming (GP) [5] idea and then, it would be possible to manipulate the components through a visual interface, resulting in an initial source code implementation ready to be customized. References [1] 3G Americas. Available on http://www.3gamericas.org, accessed in August, 2006. [2] Bachmann, F.; Bass, L.; Buhman, C.; Comella-Dorda, S.; Long, F.; Robert, J.; Seacord, R.; Wallnau, K. Technical Concepts of Component-Based Software Engineering, 2nd Edition, Carnegie Mellon Software Engineering Institute, May, 2000. [3] Cheesman, J.; Daniels, J. UML Components: A Simple Process for Specifying Component-Based Software, Addison-Wesley, 2001. [4] Component-Based Design: A Complete Worked Example. Available on http://oopsla.acm.org/oopsla2k/fp/tutorials/tut71.html, accessed in January, 2006. [5] Czarnecki, K.; Eisenecker, U. W. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000. [6] D'Souza, D.; Wills, A. C. Objects, Components, and Frameworks with UML - The Catalysis Approach, Addison-Wesley, 2001. [7] J2ME Polish. Available on http://www.j2mepolish.org/, accessed in August 2006. [8] Jacobson, I., et. al. Object-Oriented Software Engineering - A Use Case-Driven Approach, Reading, MA: Addison-Wesley, 1992. [9] Jacobson, I., et. al. The Unified Software Development Process, Addison-Wesley. USA 4th edition, 2001. [10] Java 2 Platform, Micro Edition (J2ME). Available on http://java.sun.com/j2me/, accessed in August, 2006. [11] Muchow, J., W. Core J2ME Technology & MIDP, Pearson Makron Books, 2004. [12] OMG - Object Management Group: Unified Modeling Language 1.3 specification. Available on http://www.omg.org/uml/, accessed in January, 2006. [13] PersonalJava Application Environment. Available on http://java.sun.com/products/personaljava/, accessed in August, 2006. [14] Stojanovic, Z.; Dahanayake, A.; Sol, H. A Methodology Framework for Component-Based System Development Support, The 6th CaiSE/IFIP8.1 International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD), Interlaken, Switzerland, June, 2001. [15] SuperWaba: The Real Power of Mobile Computing. Available on http://www.superwaba.com.br, accessed in August 2006. [16] Szyperski, C. Component Software Beyond Object-Oriented Programming, Addison-Wesley, 2002. [17] The Mobility and Devices Track at JavaOne 2005. Available on http://developers.sun.com/techtopics/mobility/javaone2005/j2metrack.html, accessed in September, 2005.