Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Applications programs running on mobile devices are becoming so popular in the business [1]. Mobile applications are different from desktop applications because mobile devices are resource-limited embedded systems and their application domain is smaller than desktop domain. A mobile platform consists of various source codes to control a microprocessor and hardware. Mobile applications include various software that use APIs supported by a mobile platform [2]. This paper presents a development technique to help developers understand and define the domain of requirements.

In Sect. 2, we introduce the popular related works for software development process, SPEM(Software and Systems Process Engineering Meta-model) and EPF(Eclipse Process Framework). In Sect. 3, we introduce the characteristics of mobile applications. The software architecture of mobile applications and three models for applications are introduced in Sect. 4. And then we present a development technique, AppSpec, in Sect. 5. We apply our method to an application example in Sect. 6, and the compare our technique with the related works in Sect. 7. Finally we come to a conclusion with brief summary in Sect. 8.

2 Related Works

2.1 SPEM and EPF

The Eclipse Process Framework (EPF) [3, 4] aims at producing a customizable software process engineering framework, with exemplary process content and tools, supporting a broad variety of project types and development styles. The Eclipse Process Framework (EPF) is an open source project that is managed by the Eclipse Foundation. It lies under the top-level Eclipse Technology Project. It has two goals:

  • To provide an extensible framework and exemplary tools for software process engineering—method and process authoring, library management, configuring and publishing a process.

  • To provide exemplary and extensible process content for a range of software development and management processes supporting iterative, agile, and incremental development, and applicable to a broad set of development platforms and applications. For instance, EPF provides the OpenUP, an agile software development process optimized for small projects.

By using EPF Composer you can create your own software development process by structuring it in one specific way using a predefined schema. This schema is an evolution of the SPEM 1.1 OMG specification referred to as the Unified Method Architecture (UMA). Major parts of UMA went into the adopted revision of SPEM, SPEM 2.0 [5]. The UMA and SPEM schemata support the organization of large amounts of descriptions for development methods and processes. Such method content and processes do not have to be limited to software engineering, but can also cover other design and engineering disciplines, such as mechanical engineering, business transformation, sales cycles, and so on.

2.2 Masam

The MASAM [6] is providing the process based on the Agile Methodology for developing applications software operated on mobile platform. The MASAM gives benefits of rapid development and the reuse of domain knowledge for mobile software. The MASAM methodology is defined as EPF and was distributed to companies for developing mobile applications.

The MASAM has advantage of the SPEM. It can define process according to the context of the mobile company. It supports companies developing mobile applications software. Companies have to tailor MASAM’s methodology according to their environments.

3 Characteristics of Mobile Applications

There are two kinds of traditional mobile applications: web applications and native applications [7]. Web-based applications consist of web pages optimized for mobile devices and can be developed by using HTML, JavaScript and CSS. They usually run on a server, so they cannot access the mobile devices’ feature (for example, the physical camera device). Native applications are developed for specific mobile devices. They can access the functionalities of mobile devices, such as GPS, file storage, databases, SMS, mail box and etc. They can be downloaded, installed, and sold in applications store. In this paper, mobile applications refer to native mobile applications.

Mobile devices, in particular smart phones, have been popular in our life. Mobile applications are necessary for providing smart phone devices with functionalities for mobile data services. Mobile devices like smart phones are resource-limited embedded systems. And they are developed separately on different development platforms with different operating systems such as RIM of Blackberry, Windows Phone, iOS, Symbian, and Android [8].

Developers for mobile applications have difficulties in handling different devices, multiple operating systems and different programming languages such as Java, Objective-C, and Visual C ++. In addition, mobile applications are developed in small-scale, fast-paced projects to meet competitive market demand [9].

Development of mobile applications program with Android requires Java programming language using the Android SDK which provides the tools and APIs necessary for development [10]. An applications program is packaged as an Android package, “apk” file. An APK file includes all the files related to a single Android application. Figure 1 shows the Android applications architecture.

Fig. 1
figure 1

Android system architecture

Full size image

4 Architecture of Applications Program

The mobile application installed on the mobile phone usually consists of two layers: the graphical user interface and the business logic. Figure 2 shows the architecture of mobile applications. The graphic user interface is for user interaction and the business logic is the function of applications program installed the mobile phones. The mobile applications may communicate with a server through a network.

Fig. 2
figure 2

Architecture of mobile applications

Full size image

The software architecture of business logic for a mobile application can be designed by three models presented in [11]: the application model, the graphic user interface model, and feature model.

An application model represents the mobile application program. The mobile application program can be represented by the graphic user interface model and the feature model. The graphic user interface model represents screens of mobile phones that users interact to get data services. The screens include the buttons of menu for functions to do the application. The functions are accomplished by clicking the button of menu. The source code for functions is represented by the feature model. The functions for the menu in the screen are represented by the feature model. Figure 3 shows the relationships among three models of an application.

Fig. 3
figure 3

Three models of an application

Full size image

In our paper, the application model is described by the use-case diagram, the mind map, and the architecture design diagram presented by AppSpec that are explained in Sect. 5. The graphic user interface model is described by the navigation design diagram and the page detail design diagram. The feature model is source codes for the functions to perform the application.

5 Development Procedure of AppSpec

We propose a development technique, AppSpec, for mobile applications, which includes five phases: requirements analysis, architecture design, navigation design, page design, and implementation and testing. Figure 4 shows the entire development cycle. This procedure is iterative between phases to support feedback. The iterative feedback improves the product quality through recursive review and evaluation. AppSpec is an improved version of the previous method presented in [12, 13].

Fig. 4
figure 4

Development procedure of AppSpec

Full size image

5.1 Development Phases

Requirements Analysis. Developers define the goals and functions of the mobile applications. The purpose of the requirements analysis phase is to analyze the application domain through the viewpoint of users. Therefore, the communication between developers and users is very important. The success or failure of a project is dependent on the degree of understanding the user’s requirements.

In this phase, developers define the target users who will use the application. They also analyze the contents and functions, constraints, and who is going to provide the new content. The product of this phase is requirements specification. The specification is described by the Use-case diagram and the Mind-Map.

Architecture Design. Developers determine the most suitable architecture according to the result of the requirements analysis phase. Developers divide the application domains into sub-applications. Well-defined architecture can reduce the complexity of the system and provide the work boundaries for developers. The product of this phase is the architecture design diagram.

Navigation Design. Developers define navigation relationships between pages (screens of smart phones) of the mobile applications. The navigation relationship includes the link relationship and data migration between the pages. The mobile applications program generally consists of more than one page. Users of applications navigate the pages to retrieve some information or to accomplish what they want to do. The product of this phase is the navigation design diagram.

Page Design. Developers design the screen layouts and functions for all of the pages. The pages can be classified into static pages and dynamic pages according to their functions. The function of static pages is to show their contents. The function of dynamic pages is to accomplish tasks such as data processing or accessing databases. The product of this phase is the page detail design diagram. Page detail design diagram consists of the design pattern and the functional flows of each page.

Implementation and Testing. The analysis and design specifications can be implemented in a straightforward manner by programming all of the page detail design diagrams. The behavior of the mobile applications must be tested on the emulator and on the real mobile device because the applications on an emulator may perform differently from running on a real mobile device with various hardware and software versions [14].

5.2 Graphic Notations

Our method provides program developers with two main notations, the component and the connector, for modeling diagrams in each phase of AppSpec. Components represent the functional modules of the system while connectors represent the interactions between components. Figure 5 shows the notations of the diagrams for modeling applications.

Fig. 5
figure 5

Graphic notations for design diagrams

Full size image

Components in the diagrams are classified into the architecture component, the page component, the passive component, the active component, the database component, the group component, and the condition component.

The architecture component is used to represent the structure of applications in the architecture diagram. It is a function of an application. The page component represents a page in the navigation design diagram. The passive component represents a static functional module. The active component represents a dynamic module. The database component represents a data repository. The group component can be used to combine a set of components into one group of functions. The condition component is used to specify a condition. All of these components are used in the page detail design diagram.

Connectors in the diagrams are classified into the general link, the indirect link, the direct link, the data link, the DB link, and the sequence link.

The general link represents the existence of any relationships between two components in the architecture design diagram. The indirect link and the data link represent the transitions occurred by a user’s clicking on a button. The indirect link does not contain a data transmission between two components. But the data link contains a data transmission between two components. The direct link represents an automatic page link in the program. The Database link represents a data transmission between a functional module and a database. The sequence link represents the sequence of the activation of components. The Database link and the sequence link are used in the page detail design diagram.

5.3 Diagrams

The following five kinds of diagrams are produced after we finish all phases of AppSpec:

  • The use-case diagram

  • The mind map

  • The architecture design diagram

  • The navigation design diagram

  • The page detail design diagram.

The Use-case Diagram. Application developers must consider the kind of users of the system to be developed. Also they define the functions that users want to do according to their roles. The use-case diagram represents the users of the target system and the functions to be developed within the system to give services to users.

The Mind Map. In order to derive the functions and information for the target system, developers need to extract them from the requirements. The mind map represents the relationships between functions and information.

The Architecture Design Diagram. The architecture of software is defined by computational components and interactions among components. The well-defined structure makes it easy to integrate and maintain the parts of a large application. The architecture design diagram shows the vertical and horizontal structure between functions of applications and does not include the information about the detail algorithms. This diagram is concretized in the navigation design diagram and the page detail design diagram.

The Navigation Design Diagram. The most important characteristic of applications is the navigation feature. Because web applications consist of pages, users of web applications have to explore pages to search for information or accomplish what they want to do.

The navigation design diagram represents the navigation relationships among pages. It shows the link relationships and data transformation between pages.

The Page Detail Design Diagram. The page detail design diagram represents each web page in detail. The pages are classified into static pages or dynamic pages according to their tasks. Some pages may include the characteristics of both.

The static pages display their contents and are described by the design patterns. On the other hand, the dynamic pages perform some tasks and are described by the functional flows to represent the algorithms for the tasks.

6 Application Example: An Application for Ordering a Menu at Inverse-Auction

We applied our method to developing a mobile application that arranges a deal between a user and a company. This application keeps the information about companies by the category of menu. Users can order their menu through the application and then companies can bid their prices for the menu at auction. Users and companies can write reviews and declarations for their deals. A user in this application is a customer who orders a menu. A company is a seller who produces the menu. In case that a user orders a menu, companies that are interested in the order offer their own prices to the user. Then the user chooses one of companies that offer their prices for the menu. Users usually select a company that bids the lowest price for the menu. Figure 6 shows the main screen of the application we want to develop and the development environment for the application.

Fig. 6
figure 6

Application program development environment

Full size image

The first phase of the development procedure in AppSPec is the requirements analysis. In this phase, we develop the use-case diagram and the mind map for the application.

Figure 7 is the use-case diagram that shows the users of the application and their interactions with the application. Users are defined by their roles. In this application, the users are the User and the Company. The roles of the User are to verify their information, to write articles about deal reviews and declarations for the Company, and to make a registration of an auction with the User’s location. The roles of the Company are to bid a price of a menu from the User at auction that is registered by the User, to verify their information, to write articles about declarations about the User, and to keep information about regular customers or black consumers. The User chooses one of companies that offer cheaper prices for the menu.

Fig. 7
figure 7

The use-case diagram

Full size image

Figure 8 is the mind map that shows the functions and information of the application. The mind map is extracted and defined from requirements. This application includes the functions for login, user information, business information, category of menu, and auction. The user information consists of user Id, password, name, phone number, and email address. The business information about a company consists of company Id, password, company name, phone number, and email address.

Fig. 8
figure 8

The mind map

Full size image

The second phase of AppSpec is the architecture design. The product of the architecture design is the architecture design diagram. Figure 7 shows the architecture design diagram for the main starting page of the application. The application includes two computational components: ‘Menu selection’ and ‘Auction registration’. The component ‘Menu selection’ is processed by the two components, List of companies and No registered company, dealing with the menu which users ordered. The architecture design diagram includes architecture components and general links.

The third phase of AppSpec is the navigation design. The product of navigation design is the navigation design diagram. Figure 10 shows the navigation design diagram for the architecture design diagram in Fig. 9. Figure 10 represents the navigation relationships between pages for the application by using the page component, the direct link, the data link, and the database link. If any companies dealing with the menu that a user orders exist, the list of companies is displayed. Or the message for no companies is displayed. The component in this diagram is concretized in the page detail design diagram.

Fig. 9
figure 9

The architecture design diagram

Full size image
Fig. 10
figure 10

The navigation design diagram

Full size image

After selecting a menu, the component ‘Auction registration’ is activated for auction. If there are not companies dealing with the menu a user ordered, the message “There are no registered companies” is given to the user. If there are companies dealing with the menu, the list of companies show on screen.

The fourth phase of AppSpec is the page design. The product of this page is the page detail design diagram. Figure 11 shows the page detail design diagram for Fig. 10. Figure 11a is the screen layout of the start page of the application. This screen includes seven image buttons and one icon. Users can choose one of buttons for menu they selected: all food, Korean food, Chinese food, Japanese food, school food, western food, or other food. Figure 11b represents the functional flows of the function “Menu”. It performs the component “View the company list” or the component “No registered companies” after it compares the menu from users with data stored in the DB for companies.

Fig. 11
figure 11

The page detail design diagram, a The design patterns b The functional flows

Full size image

7 Comparison with Related Works

We compare our AppSpec with EDF and MASAM in two aspects of development process and specification method.

7.1 Development Process

EDF and MASAM are based on the SPEM. SPEM is software and systems process engineering meta-model. The methodologies defined through SPEM have the following advantages:

  • Clear separation of method content definitions from the development process application of method content

  • Consistent maintenance of many alternative development processes

  • Many different lifecycle models

  • Flexible process variability and extensibility plug-in mechanism

  • Reusable process patterns of best practices for rapid process assembly

  • Replaceable and reusable process components realizing the principles of encapsulation

In order to get the advantages of SPEM above, all of the development team members must understand the concepts of process assets such as roles, tasks, and work product. It is not easy to define three kinds of process assets. And The processes given from SPEM may be tailored according to project characteristics.

On the other hand, the development procedure of AppSpec consists of five development phases and defines activities in each phases including requirements analysis, architecture design, navigation design, page design, and implementation and testing phase. So it is not general-purpose model, but simple and easy to apply it to mobile applications program.

7.2 Specification Method

EDF and MASAM provide many commercial tools to support their work products. Development teams using SPEM need to learn how to use tools for representing work products. It may be dependent on their process model.

Because AppSpec provides five development phases and work products in each phase including requirements analysis, architecture design, navigation design, page design, and implementation and testing phase, development members only learn the diagramming method in each phase. The diagrams represent the mobile applications by three models such as the application model, the graphic user interface model, and the feature model.

8 Conclusions

There are popular development methodologies for software. But they are general-purpose methodology for the business logics of data services in the real world. So their development procedure needs to be tailored to the mobile applications program.

Mobile applications are different from desktop applications because mobile devices are resource-limited embedded systems and their application domain is smaller than desktop domain. So we present a development technique, AppSpec, that is simply applicable to mobile software running on mobile devices. The development procedure of AppSpec consists of five development phases including requirements analysis, architecture design, navigation design, page design, and implementation and testing phase. It supports three models such as the application model, the graphic user interface model, and the feature model to represent the mobile application programs. The application model is described by the use-case diagram, the mind map, and the architecture design diagram. The graphic user interface model is described by the navigation design diagram and the page detail design diagram. The feature model is source codes for the functions to perform the application.

We applied our method to an application example, and presented documents with diagrams supported by AppSpec. AppSpec helps developers easily understand the requirements of a mobile application, and design its architecture and functional flows through three models. Our work in the future is to implement the graphic editor for supporting the procedures in AppSpec.