Component reusability in cross-platform mobile solutions

Transcription

1 U N I V E R S I T Y O F C O P E N H A G E N Component reusability in cross-platform mobile solutions Master s thesis Ivaylo Tahirski Supervisor: Konstantinos Manikas August 12, 2015

2 Abstract Software and code reuse is a very important aspect of software engineering. By reusing existing functionality developers can save time implementing applications and systems. Also, by reusing software and code we minimize the threat of programming errors. One of the prime examples of software reuse are components. Components can be represented as a software package, web service, web resource, or a module that encapsulates a set of related functions. We believe that mobile platforms and more concrete cross-platform mobile development solutions can benefit from the use of components. In this thesis we analyze the basic characteristics of software components and component models. We analyze different papers in order to find characteristics and requirements that components and component models need to comply with. We then turn our focus to implementation of components on mobile platforms and analyze what characteristics are kept in order to better understand the environment. By analyzing different papers we aim to provide information on how components are implemented on the leading mobile platforms, what additional requirements are posed by the environment and what approaches are used to create components. We also investigate cross-platform solutions for mobile platforms in order to identify potential problems involving the reuse of software components. Thus we propose an architectural prototype of a solution that can increase software reuse by interpreting components that are build for distribution on certain cross-platform solution in order for them to be used in other cross-platform solutions. The results of our investigation show that the main characteristics of components are autonomy, independence and composability. Component models are responsible for creating components that respond to those requirements and are also responsible for defining the way components communicate with each-other once they are composed into a system. By analyzing how components are created and distributed on mobile platforms and cross-platform mobile development frameworks we find additional requirements for mobile components and how those requirements affect the component models provided by those cross-platform frameworks. This information provides basis for our architectural prototype. The evaluation of the architectural prototype leads us to believe that interpretation of components for distributing them to different crossplatform solutions is possible, even though it poses additional limitations to the components. By distributing components across different mobile development frameworks we can increase code and functionality re-usability and minimize development time and resources.

3 Acknowledgments I would like to express my gratitude towards my supervisor, Konstantinos Manikas, for his comments, remarks, directions and overall involvement throughout the work process on this thesis. Ivaylo Tahirski, Copenhagen, August 2015

4 Contents 1 Introduction The mobile domain Mobile applications development Software reuse and components The general problem Method Research questions Approach Background Components Definitions, properties, requirements Component life cycle Component models Definitions, properties, requirements Categorization Summary Component models in mobile platforms Properties and requirements Categorization Summary Analysis of existing mobile component models Native components for Android, ios and Windows mobile Appcelerator Alloy OSGi Xamarin CORBA Oracle ADF Mobile Summary Analysis Global domain investigation Sub domain investigation Architectual prototype Module viewpoint Component and Connector viewpoint

5 4.3.3 Allocation viewpoint Evaluation Results Discussion Potential threats to validity Future work Conclusion 50 Appendices 52 A Source code 53 Bibliography 54 3

6 Chapter 1 Introduction In this chapter we present information about the mobile software development domain and introduce the problem we investigate. 1.1 The mobile domain Mobile software development can be defined as development of applications that are distributed on mobile devices. Those devices can be mobile phones, tablets, personal data assistants (PDAs) or even watches. Each type of mobile device has a unique way in which it communicates with its user. For example the way a person can use an application on a mobile phone differs from a tablet, because of the different screen sizes and the different UI (User interface) characteristics. Currently there are three main operating systems that are supported on many mobile devices (even though there are more than three operating systems on the current mobile market): Android, ios and Windows phone. Those three platforms are different from each-other, because of the interfaces they use, the way they communicate with the different modules that are present on the device (for example accelerometer or camera) and in terms of how applications are developed and distributed on the platforms. Each one of those platforms has special requirements to its applications. For example when an application is build for Android it needs to structure its behavior in regards to different activities which communicate with each other. Activities can also be used to create services which can be used by other applications thus creating reusable functionality. For ios the applications are switching between different views in order to complete a specific task. Also running background tasks as services on ios is not allowed in the same way as in Android. In order for an application to be distributed to a certain platform it must comply with the requirements and specifications given by that 4

7 platform. Each mobile platform has specific ways to create applications. Each platform uses a specific language and user interface components and an API (Application programming interface) for communicating with the hardware of the device. However those platforms also have architectural similarities (for example the way they represent information lists) which provide a base for creating development frameworks different than the recommended ones. This provides software engineers with alternatives for application development for these mobile platforms. Some of those alternative methods are described in the next section. 1.2 Mobile applications development There are two popular different ways applications can be developed for mobile platforms. The first one is by using the native tools that the platform provides. For example Android applications are developed by using the Android API and the developer is required to use Java as a native language [1]. ios uses Objective C as a main programming language and provides different APIs (Application programming interfaces) for communication with the operating system [5]. The second way for creating applications is by using a hybrid approach. Hybrid mobile applications are built with a combination of web technologies like HTML, CSS, and JavaScript [14]. The main goal behind such way of creating applications is to reuse the code in order to distribute the application on more than one platforms without the need to develop it from scratch again. Naturally, there are frameworks that target only one platform and allow developers to create hybrid applications for that particular platform. An example of such framework is Framework 7 which targets ios [2]. Another way of creating hybrid applications is to use the build in WebView which is provided by Android, ios and Windows phone. The WebView creates a build in browser in which the developer can run a web application, however these types of applications can not use the native functionality of the operating system. An example of such application is the first version of the IGN mobile application for Android [4]. The latest version of this application however, uses WebView only to display article content. There are different ways to create a mobile applications. In this thesis we focus on cross-platform solutions because they provide code re-usability and allow developers to create applications and components which can be distributed to multiple operating systems. 5

8 1.3 Software reuse and components Software reuse is a process of creating software systems from existing software rather than building software systems from scratch [29]. Code reuse aims to save time and resources and reduce redundancy by taking advantage of assets that have already been created in some form within the development process. Examples of software reuse can be software libraries, design patterns, frameworks and other. In this thesis we focus on software components as a form of software reuse. A software component can be described as a software package, service or module that encapsulates a set of related functions or data. Components can be deployed individually to a system and they can communicate with each other via interfaces. Through those interfaces components can provide services to the rest of the system. 1.4 The general problem The research problem is based on the idea of code reuse across multiple mobile platforms, more specific on the notion of Write once, run anywhere [20]. Currently there are many different cross-platform solutions such as Phonegap, Ionic, Appcelerator, Xamarin, Sencha or EnyoJs. They allow developers to program applications in a well known language (such as JavaScript or C#) and distribute them to multiple mobile platforms. Most mobile cross-platform solutions communicate with the different operating systems by exposing APIs (application programming interfaces) that give the developer access to the native functionality of the platform. Solutions such as Xamarin, Ionic and Appcelerator Alloy allow the developer to create components for the solution and distribute them on different applications developed using that same solution. This approach provides code and functionality re-usability for the current solution, however components created this way can not be used outside of the platforms they are build in. Therefore those software components can be used only on those platforms. This requirement restricts software reuse thus requiring developers to focus only on the use of one of those platforms. As pointed out in [25] software reuse is a very important part of software development - The goal of off-the-shelf components is to reduce the cognitive effort, the number of keystrokes, and therefore the amount of time required to design, implement, and debug a new software system. A main problem for component re-usability is the abstraction level in which it is presented. Even though components can be implemented in different programming languages, a software engineer should not be required to search a big source code library in order to determine how to use a component [25]. Reusable components can save development 6

9 time and minimize the amount of programming errors, however creating a practical library of reusable components can be a challenge. Software components should be language neutral and independently implemented of software services [36]. This property is tied to software reuse since components can be described as the building blocks of a system. By using components we improve productivity, maintainability, portability and quality of software systems. Based on those characteristics [36] describes certain metrics for software re-usability in regards to cost and development time. From the information presented in [25] that copmonents should be globally available and independent of the environment they are distributed to and the metrics provided by [36] (Component Reusability Level and Component Reusability Percentage) we deduce that the difference in the development approach used by hybrid mobile frameworks provides a problem for component re-usability. If a developer wants to use the functionality provided by a component developed for example in Xamarin and distribute it to Alloy the developer needs to implement this component from scratch. This shows that those components are environment-dependent. If those components could be distributed and used in another environment, re-usability can be increased and development time can be saved. There are many mobile cross-platform development solutions such as Xamarin, Appcelerator Alloy, Phonegap, Enyo JS, Oracle ADF Mobile, Sencha Touch [9] which provide different approaches to develop mobile applications. New solutions are also being developed. This means that if a software developer wants to create a component that is compatible with more than one cross-platform solution this developer must create it from scratch for every different framework it should be used on. However if there exists a software solution that can interpret the component for many different platforms this process will be significantly faster. We can not find information on whether the described problem has been addressed directly. However there are different approaches in solving the code re-usability in different platforms. The first approach is proposed by Unity Game Engine [13] which translates JavaSctipt, C#, Java and Objective C code in order to allow the developer of the game to distribute it to different platforms: Windows, Linux, Android, ios, Web. Another approach is proposed by Microsoft in the distribution of Windows 10 for mobile platforms [16]. The main idea of the solution is that Windows 10 will provide software developers with tools to compile applications created for Android and ios to be able to run on Windows 10 for mobile. The main issue with the above described approaches is that they are focused on specific environments. In the case of Unity their proposed solution only interprets code associated with the Unity game engine and 7

10 the provided functionality from it. This limits the solution to work only under Unity game engine which does not increase the overall software re-usability over the different platforms, even though it allows game developers to distribute their game across multiple platforms. In the case of Windows 10 the solution is still experimental and it focuses on compiling existing applications for Android or ios in order for them to be distributed to Windows 10 mobile and does not provide a way for distributing Windows 10 mobile applications to Android and ios. This approach can increase software re-usability for Windows mobile, but not for the other platforms. We aim to increase code and functionality re-usability by allowing software components created by different cross-platform frameworks to be distributed to and recognized by other mobile development frameworks. Since we aim at distributing components on different crossplatform mobile frameworks once deployed to an application the provided functionality can be used in all mobile platforms the framework supports. This approach will save development time and minimize the possibility of programming errors. To address the problem with component re-usability we provide a solution that interprets the code of a component and produces a new one that can be distributed to and understood by different platform. Components are created from multiple files that are written in different languages (for example a component in Alloy is using JavaScript, XML and Json for creating a component [11]). Therefore we use different parsers for the programming and markup languages used in the different components and map the provided results in such a way that the newly constructed component can be distributed to a different platform. We aim to provide robust easily extendable solution. Therefore we divide the tasks of identifying, parsing, interpreting and constructing a component to different execution layers. Each layer is responsible for exactly one task and delivers information to the next layer in order to complete the interpretation process and construct a new component that can be distributed to Xamarin. We test our prototype by using different components developed in Alloy. Each component has different code structure in order to test the parsing and interpreting methods. We define functions, even listeners and objects in order to determine to what degree the given code can be parsed and interpreted. As a result of our experiment we found out that interpreting components from one framework to another is possible, even though it is limiting. Depending on the code style information about functions, types and objects can be extracted and successfully interpreted, however there are instances where the type of a variable can not be determined. In those instances the code requires additional analysis before interpretation. 8

11 Chapter 2 Method In this chapter we describe the method we use to address the problem and formulate the research questions we aim to answer. 2.1 Research questions Since components are essential part of code re-usability [36] we need to have a better understanding on how components are build and how they are re-used in different software systems and environments. This information can provide a base for better understanding on how components are created and distributed in mobile platforms. We also need to better understanding to what extend those components comply with general requirements and characteristics. Cross-platform development is important for software re-usability and there are many solutions that provide different approaches to application development [24]. Some of those platforms such as Alloy, Xamarin and Sencha use software components and offer tools for creating them in order to provide re-usable functionality to the applications. To have better understanding on components supported by cross-platform solutions we need to understand the development process and how those components are distributed to their respective environments. Based on these criteria we need to provide and answer on those research questions: What are the main characteristics of components and component models? How mobile cross platform solutions are used to create components? How can software components, that are developed for a specific cross-platform solution be reused across other frameworks and what are the downsides to such reuse? 9

12 2.2 Approach We divided our approach in three main steps: global domain investigation, sub-domain investigation, architectural prototype and evaluation. We use the global domain investigation to uncover the main characteristics of components and how component models fulfill them. Secondly we narrow our domain to the major mobile platforms and investigate to what extent the properties uncovered in the global domain are fulfilled in the mobile sub-domain. We also investigate how cross-platform mobile solutions support the creation of components as part of the mobile sub-domain. Based on our findings we propose an architectural prototype that aims to solve a common problem associated with components created by cross-platform solutions. In order to have better understanding of components and component models we need to find information on their characteristics and to what degree those characteristics are fulfilled by components distributed on mobile platforms. In order to do that we draw inspiration from the method proposed in [26]. In medical practice the evidence-based approach consists of three practices: clinical expert opinion, external scientific evidence and client perspectives in order to provide high-quality services reflecting the interests and needs of the individuals it will serve. As concluded in the paper software engineering can benefit from the evidence based approach provided that it deals with specific problems. Inferring from this approach we analyze research papers regarding the properties of software components and analyze existing component models in order to provide information on the general characteristics of a component [33] and how they are addressed by existing component models. This provides us with better understanding of components and component models and helps us to critically assess the needs of individuals who use them. In the global domain investigation we analyze different papers that provide information about components and component models. We provide definitions for what a component is and identify and describe main properties of components. We also provide information on different component models, what their characteristics are and what is their approach to creating and distributing components. Finally, we provide categorizations for component models based on different characteristics of the described models in order to have a better understanding on how they work and what do they have in common. In the sub-domain investigation we focus on mobile platforms. We primarily focus on Android, ios and Windows phone. We provide information on how components are created and what part of the characteristics we found in the global domain are also valid in the mobile domain. We also provide information on different cross-platform solutions and investigate how components are created in their context. This gives us better understanding on how component models are defined and 10

13 behave in mobile environments. Based on our findings we provide information on what we consider to be improved in terms of functionality and re-usability. The sub-domain investigation also provides architectural requirements for our design. We provide an architectural design for our solution. The description of the solution is based on the 3+1 structure presented in [21]. In our case we use model, component & connector and allocation viewpoints. The solution uses externally developed modules, but they are included and referenced as software packages inside the system, therefore they are not described in the allocation viewpoint. The model viewpoint is concerned with how functionality of the system maps to static development units and the component & connector viewpoint is concerned with the runtime mapping of functionality to components of the architecture [21]. We also limit our model viewpoint to using package overview and package dependency diagram because our solution currently does not interact with external systems. Even though deployment is not the focus of the given architectural description, we provide information on how the solution can be deployed in order to have a better description of our solution. We also consider an architectural description based on the 4+1 approach proposed by [28], however we find it unsuitable for describing our solution. The paper [28] describes logical, process, physical and development views. The logical view is the object model of the design if one is used. The process view captures the concurrency and synchronization aspects of the design. The physical view describes the mapping(s) of the software onto the hardware and reflects its distributed aspect. Finally the development view describes the static organization of the software in its development environment. All those views are represented by use cases or scenarios which are accompanied by specific diagrams. However those diagrams are designed in accordance to the researchers perspective on how the diagrams should function, which makes them harder to understand than diagrams made using a well known language such as UML. Therefore we base our architectural description on the 3+1 approach instead of the 4+1. Based on the findings presented in [18] and [23] we decided to use a software prototype for evaluating our architectural design. By creating a software prototype we can evaluate the practicality of our solution. We can also provide information on what difficulties must be addressed in order our solution to meet the presented architectural requirements. As defined by [23] Prototypes embody design hypotheses and enable designers to test them. Our prototype aims to provide information on the validity of our architectural design. We focus on Xamarin and Appcelerator Titanium as base cases for our solution, because they are concentrically different, use different programming languages and paradigms to create reusable components which can be deployed to different cross-platform applica- 11

14 tions developed by using those frameworks. We provide a solution that interprets JavaScript to C#, JSON to XML and XML to XAML in order to construct components that can work on both platforms. This means that the solution can receive component developed for use in Alloy and interpret it in such a way that it can be distributed to Xamarin. We evaluate our solution by providing examples of components that should be interpreted and then used in applications. We provide simple cases through which we determine how well does our prototype perform and what limitations does it have. We also use open source components through which we detect how well different source code elements can be detected and how they are translated. Based on our findings we provide final results and potential threats to validity for our solution. Those cases do not cover all scenarios for the prototype evaluation as proposed by [18] they provide general information for evaluation and verification of the prototype. 12

15 Chapter 3 Background In this chapter we analyze the literature that describes the main properties of component based development and extract the most important characteristics of component models. We provide information about different component models, categorize them and identify which of the component based development requirements are fulfilled by them. We also focus on component models in the mobile platform domain, extract general information about their properties and requirements, categorize and identify to what degree they fulfill general and domain specific component model requirements. 3.1 Components Definitions, properties, requirements The aim of component based development is to create, use or reuse components in order to build different systems by assembling them using composition mechanisms [31]. A component is a software package that encapsulates in itself a set of related functions or relevant data. It is a unit of composition with contractually specified interfaces and context dependencies only [27]. In general principle components should be modular and cohesive. This means that a component should be able to work on its own and be independent of other components. There are many definitions of software components, but none of them is universally accepted [33]. Still, we can create an overall picture on what a component is based on those definitions [33]. Here is a list of definitions presented in [33], such as: 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 13

16 A software component can be defined as a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard A software component must satisfy the following conditions - it can be used by other software elements which in this case will be named clients. The model should also possess official and clear usage description which is sufficient for a client author to use it and the component should not be tied to any fixed number of clients. From the above we can infer some basic properties of components. First a component must be independent [33]. This means that it should be able to function on its own as well as in composition with other components. A component should be deployed independently of other components [33]. In that case the deployment of a component can be done individually without the need of other components to be deployed beforehand. Components should be composable in a certain environment [30]. Here we define the composability of a component as its ability to become part of a system. This is done by deploying it and connecting it to other components in a given environment. The ability to compose components shows how the components are structured in a system. Components should be able to communicate with each other [33]. When composed components have services that they use (provided by other components) and services that they provide. The two types of services are defined as provided (lollipops) and required (sockets) respectively [31]. In order for those services to exist, components should communicate with each other in a certain environment. Figure 1: A software component (adapted from [31]) From [27] we can infer more component characteristics: Software units of independent deployment - each component can be deployed independently of other components. Subject to composition - all components can be composed into a system. 14

17 Specified interfaces - each component should specify interfaces for interaction. Explicit context dependencies - dependencies between components in certain context should be explicitly defined Cross-tier and -platform components - components can be run on different platforms as well as both on client and service tiers. Modular verification and validation - each component should be verifiable in a module before it can be deployed in a bigger system Component life cycle One of the main properties of a component is its life cycle. It defines how components are constructed and composed. In this chapter we present the idealized component life cycle [33]. The ideal component life cycle is constructed of three distinctive phases - design phase, deployment phase and run-time phase [32]. In the design phase components are constructed and deposited to repository in such a way that they can be retrieved later when needed. In the deployment phase components are retrieved from the repository and compiled to binary code. After that these components are ready to be composed into a system that is ready for execution. In the final - runtime phase, components are instantiated with data and executed. There is no new composition or re-composition in the run-time phase. As described above in the design phase components have to be constructed, cataloged, and stored in a repository. As a main requirement for the repository we pointed out that it should store and manage depositing and retrieving different components. This means that in order for a component to be retrieved it must have a suitable index provided by the repository [33]. Ideally the repository must also provide a search facility for retrieving indexed components. The repository may include a builder tool which must first be able to construct new components in order for them to be deployed to the repository. It can also retrieve components from the repository, compose them and deposit them back. The ideal component life cycle is based on commonly accepted criteria in component based development that components are pre-existing reusable software units that can be produced and used by independent parties and can be copied and instantiated [32]. Finally components can be composed into other composite components, which in term can be composed into even larger composites. This means that new components can be created by combining existing ones and still keep the general properties of a component described in the previous paragraph. 15

18 In the ideal life cycle there can also be provided an assembler tool [33]. It is used to retrieve the components from the repository and if necessary compile the components into a binary code and assemble them into a system. 3.2 Component models A component framework provides a programming environment for software components and contains a component model [27]. In this section we provide information about component models, their properties, requirements and categorize existing component models based on those notions Definitions, properties, requirements A component model defines the implementation, documentation and deployment of a component. The component model describes how a component is developed, how it communicates with other components and how it is deployed to the environment so that the system can work with it [27]. In summary a component model consists of component semantics, component syntax and component composition. Generally component models aim to provide reuse of software, reduced complexity and lower cost of development [27]. The aim of component reuse is that different components can be build and reused in different compositions of environments. This supports the notion of developing a piece of software once and then distributing it to different platforms. To reduce complexity the functionality of a given software solution can be divided between reusable components. This means that to change certain type of functionality or fix a problem in the system you only need to do it on the level of a specific component, not on the level of the whole system. Developing components lowers the cost of development, because they can be reused once they are created and their composition can also be changed. This means that there is no need to re-develop functionality for a new solution from the ground up. We provide some additional definitions to component models which can be useful for better understanding the ideas behind concept. They are primarily connected to the semantics of component based development that component models need to comply with. Provided and required services [33]: As defined in section provided services are the operations per- 16

19 formed by the component and required services are the ones that are needed by the component so that it can produce the provided services. Component model interfaces [33]: The interfaces of the component model should contain specifications of both provided and required services. They should also provide specification of any dependencies between required and provided services. Cross-platform and cross-tier development [27]: Even though it is not a main requirement for component models it can be inferred from the definition that a component aims to provide software re-usability. This means supporting many different platforms with different composition, development environment and interface handling. Thus a component should be implemented once and distributed to several different platforms. Modular verification and validation (V & V) [27]: V & V is needed because when a component is build we need to make sure that it will work correctly on every platform it is distributed to. As mentioned previously the component models have their specific semantics. To define components a Component definition language can be used [33]. Of course the component definition language is not necessarily the same as the implementation language. An example of component definition language is UML 2.0. In that case we define the components as separate architectural elements without specifying their implementation. In other cases however the definition language coincides with the implementation language [33]. An example of that can be.net where each component can be defined as an object that is an instance of a class which defines the component unambiguously. Thus, the definition and implementation language are one and the same. The next important point we need to make for software component models is composition. In order for the different components to work in a system they need to be composed. For composing different components a composition language can be used. A composition language is used to define composition of the software components so that they can be able to communicate with each other and be able to construct a larger block or system [33]. However some modern programming languages do not support such composition. For example Java does not natively support the communication between two components. To achieve this it requires an additional extension that supports the specification of connections between the components. An example of such extension is ArchJava. 17

20 Web Services are composed by orchestration, typically using a workflow language like Business Process Execution Language [30]. Furthermore important for compositions is the Composition theory. This theory can help us to calculate and predict the result of application of a composition operator to set of components [33]. Composition of components can take place during different stages. Stages form the component life cycle and they are defined as design, deployment and runtime phase. In summary during the design phase components are designed, defined, and constructed in the source code (there is also possibility for compilation to binary). At the deployment phase components are deployed into a target execution environment, while during the runtime phase component binaries are instantiated and those instances are executed into the system Categorization Based on the characteristics and requirements of component models, different categorizations of component models can be provided. As a first general categorization we can divide component models in two categories - component models where the components are defined as architectural units and component models where components are defined as objects (that are instances of a class) [30]. In the first category we can assign component models such as UML 2.0, Kobra, Palladio and X-MAN. In the second category we can assign.net, Enterprise Java Beans (EJBs), OSGi, JavaBeans. As the base of the second categorization the way components are composed can be used. Depending on the composition component models can be categorized as [33]: Design without repository: in the design phase there is no repository. The components are constructed from scratch and composition is possible, but in the deployment phase no new composition is possible. For example Acme is an architectural description language where each component is described as architectural unit. Each unit can have ports for interaction with the environment. They can act as either a sink or source. In this context the components are composed of connectors that act as the middle man for communicating and coordinating. Since Acme is designed without repository the components and connectors have to be structured from the ground up. 18

21 Design with Deposit-Only Repository: new components can be deposited in a repository but cannot be retrieved from it. Composition is possible, but composed components (composites) can not be retrieved from the repository. An example of this design is Enterprise Java Beans (EJB). Components are managed by a container. Each component must be accompanied by several interfaces for managing the component (in the case of java beans they are two). They are used to expose the functions that are needed so that the components can communicate. In EJB the home interface is responsible for representing the component life cycle: create, destroy and locate a bean instance. The remote interface is responsible for representing tasks that are performed by the component (in EJB case it is referred to as âăijbeanâăi). After the design phase comes the runtime phase. This means that no new compositions can be created after the design phase is over. In the runtime phase instances of the beans can be created and executed in the existing environment (EJB container in our case). Deployment with Repository: new components can be deposited in a repository during the design but cannot be retrieved from it. Composition is not possible in the design phase. An example of this class is JavaBeans, even though it is no longer actively used or maintained [27]. In it a component is described as a bean which is any Java class that contains methods, events and properties. In order to be executed or composed beans must be dragged into a container. For JavaBeans there is also a container called ToolBox which is part of BDK (Beans Development Kit). It acts as a repository for the components to which for each bean, a JAR file containing the bean implementation class, the event state object, and the event listener interface are deployed. From the ToolBox components (called beans) can be extracted, composed, instantiated and executed in the BeanBox. This means that again the composition is only supported in the deployment phase and that the individual components can not be recommissioned once that phase is done. In the deployment phase the composition is specified by declaration of the event model which is responsible for the description of the communication between the components. Design with Repository: new components can be deposited in a repository during the design phase and components can be 19

22 retrieved from the repository. Composition is possible and composites can be deposited in the repository. An example of this class is Koala, a component model for consumer electronics product software. In Koala a component is a unit which has a specification and implementation. Semantically in Koala components are units of computation and control connected in an architecture. Syntactically, components are defined in an ADL(Architectural Design Language)-like language [33]. Koala component definitions are compiled by the Koala compiler to their implementation in a programming language. There are two other ways to categorize the different component models: based on semantics and component syntax [33]. Based on semantics component models interpret components as classes defined by the implementation language, objects (every component is an instance of a class defined in the implementation language) or architectural units (they are defined as abstract element os the system). Based on component syntax the models can define components through an object oriented programming language, an interactive data language which represents the connections between the component and the environment which it communicates and through architecture description language which describes how components are deployed and communicate through the environment, but does not provide information on how those components are created. Those classifications can be founds in tables 1 and 2. Category Models where the components are classes Models where the components are objects Models where the components are architectural units Component model example Enterprise Java Beans.NET UML 2.0 Table 1: Classification of component models based on semantics Category Models in which components are defined by object-oriented programming language Models in which an IDL(Interactive Data Language) is used and components can be defined in programming language with mappings to the IDL Models in which the components are defined as ADL(Architecture description language) Component model example Enterprise Java Beans,.NET Web services + BPEL(Business Process Execution Language) UML

23 Table 2: Classification of component models based on syntax Based on the different definitions and characteristics of software component models a new classification can be created [27]. For this classification each component model should answer these questions: Does the component model support independent software units? Can each component be independently deployed? How composition is specified and during which phase and also as pointed in [27] Can composition of components be specified in such a way that composites are components? Interface specification: as pointed in the previous section a characteristic of the component models is that their interfaces should contain specifications of the required and provided services. It is important to know which of the current component models fulfil this requirement. Are components / environment / context that a component depends on explicit and described in the component? For the classification outlined in Table 3 we focus on component models that are actively user and/or maintained. Namely those are EJB (Enterprise Java Beans),.NET, OSGi, Web Services, Enterprise Java Beans, UML 2.0 and Paladio. We decided to focus on these because they are currently relevant and/or actively maintained. Component model Independent software units Composition Contractually specified interfaces EJB Yes Partial Yes No.NET Yes Partial Yes Partial OSGi Yes Partial Yes No Explicit context dependencies Web services Yes Partial Yes No UML 2.0 No Yes Yes Yes Paladio Partial Yes Yes Yes X-MAN Partial Yes Yes No Summary Table 3: Classification of component models [27] In conclusion, even though there is no unified definition for component based development [33] we can still outline several main characteristics that component models must comply with. They are responsible for defining and describing the behavior of components. Component models 21

24 need to define how components are composed in a system and how they communicate in that system. They need to define the dependency of components in terms of context and environment. Through the different classifications we manage to extract information on the basic construction of component models, to what extend they comply with general definitions of components and how by using them we can increase software re-usability. The modern component models used in the final classification do not fulfill all of those requirements, as it can be seen from table 3. This shows that we have to improve component models in order for them to support more requirements and we have a solid base to work with. 3.3 Component models in mobile platforms In this section we provide information about component models aimed to support mobile platforms and additional requirements or properties that must be supported by such component models. We provide information about current component models that support mobile platforms and categorize them according to the additional requirements defined in this section Properties and requirements The characteristics of component models for mobile platforms are no different from the general component models. However there are few more interesting platform specific properties and requirements that should be outlined. The basis of a component model that support mobile platforms is their software architecture [35]. The architecture can be described using two types of views: logical view and process view. The logical view is describes the logical structure of the system, while the process view describes the behavior of the different components and the evolution of the architecture over time. We can distinguish between three types of architecture: static, dynamic and mobile (fully dynamic) [35]. Static architecture can be defined as architecture in which after initialization of a system, new connections between system s components can not be created and old connections can not be destroyed. Dynamic architecture is an architecture with dynamic reconfigurations. In such architecture evolution rules of the software system over time exist. In other words its components and connections are created and destroyed during the system s runtime according to the rules from 22

25 its design-time [35]. Mobile architecture (dynamic with component mobility) is described as a dynamic architecture where components can change their context in the systems logical structure during execution. The main problematic areas connected to mobile platforms are user experience, resource and power consumption, application maintenance and device heterogeneity [34]. One of the main goals when creating a solution for mobile platform is to design best user experience possible. As described in the design guidelines for ios and Android the user experience is one of the primary concerns when an application is being evaluated. The resource and power consumption problem is connected with the fact that mobile devices are still limited when it comes to power and resources. Application maintenance is needed because mobile operating systems are constantly updated and often make some applications unusable on their newest versions. The problem of device heterogeneity comes from the fact that there are many different operating system providers and device providers [34]. For example even though many mobile manufacturers are using Android as operating system for their mobile devices, they still make many modifications to it which makes it unique. This means that there is no guarantee that applications created for Android will work on this modified version according to reports from Google Play store. The above described problematic areas can be used as our basis for outlining our requirements to a component model that can support different mobile platforms. Since we have many different operating systems (OS) each with their own development environment, requirements and specifications we need to either develop component for each OS individually or use a cross-platform solution. There are several main problems that a cross platform solution must face [34]: required tools, programming languages, user interface declarations and memory management. Even though those problems apply to general mobile development they also have strong emphasis on component based development. Each platform has its own programming tool. For example in order to create a component (or any other software) for ios you need a Mac with installed Xcode [5]. The cross-platform solution should comply with those requirements. 23

26 Each platform supports different programming language. Android uses Java, ios uses objective C and Windows phone C#. This suggests that in order for an application to be deployed to the operating system it must be developed and compiled in the native language for the system. Therefore the cross-platform solution should provide a connection between the native language for developing the application and the language that the solution uses. Every platform has different type of user interface (UI). Even though they share several UI elements like a listing of items they are declared and created in a different way. The cross-platform solution is not required to provide a way for the developer to use those UI components, but if such functionality is not present a required user experience might be lost. Every platform has different memory management. For example the file structure of Android differs from the file structure of ios. Also important is the way the memory is managed in the device [1]. On Android you are not allowed to install application on an external memory card. This means that the application must comply with the limits of the internal storage provided by a specific device. Because of these differences between mobile platforms there are requirements that can be posed on a component model that aims to support multiple mobile platforms. The most relevant requirements regarding cross platform component development are: unified way to design, implement and/or run application on all available platforms that allows to use components on each host, efficiency of the applications generated by using a cross platform solution, the user mobility and adaptability [34]. The unified way to design and implement a component is a relevant requirement, because since the solution provides multiple platforms the components should be developed in such a way that they can be distributed on those platforms. Application efficiency and lightweight is required, because of the limited resources of the mobile devices and also of the performance expectations of the end users [3]. The requirement of user mobility is concerned with the way a mobile device is used, the fact that it is not always connected to a network and is in constant motion. The cross-platform solution must be adaptable because the software platforms for mobile devices are evolving and the solution must be able to reflect that. The efficiency of cross-platform solutions is important because as we mentioned above the resources of a mobile device are limited [34]. For example the cross platform solution Appcelertor builds a native environment on top of JavaScript code which causes the final solution to be bigger in size than it actually is. Also this way of building the applica- 24

27 tion causes performance issues on slower devices. The mobility constraints are due to the fact that a mobile device is always in motion which causes dynamic context modifications, for example connectivity and location changes [34]. For example a sport tracking application needs to actively respond to changes to the phone location and the data that the accelerometer sends in order to be able to accurately track an activity that is performed by a certain user. The solution should be easily adaptable [34]. That is inferred primarily from the fact that the mobile domain evolves fast [19]. For example there is significant difference between the current version of ios and the same operating system two years ago. If the applications that were developed for the old system were not changed it would have been no longer possible for them to run on the modern platform [5]. Some more interesting aspects of mobile component models can potentially be self organization and logical mobility [38]. Those two properties may be relevant for mobile component model in the long term primarily due to the nature of current mobile operating systems to change [1] Categorization Developing component for multiple mobile platforms is an essential requirement for mobile component models, therefore in this section we focus on component models that support cross platform development. We can distinguish between three types of cross platform implementations [34]: cross-compiler, solutions based on model driven engineering and source code interpreters. Cross-compiler is a solution that takes an existing code and compiles it in a solution that can be executed on different mobile platforms. An example of cross-compiler solution is Corona. Corona is a software development kit that uses C++/OpenGL as a base for cross-platform mobile development. The solutions based on model driven engineering focus on exploiting domain models, rather than on algorithmic concepts. An example of such solution is UsiXML. UsiXML is a XML-compliant markup language that describes the UI for multiple contexts of use such as Character User Interfaces (CUIs), Graphical User Interfaces (GUIs), Auditory User Interfaces, and Multimodal User Interfaces [15]. Source code interpreters translate in real time source code to executable instructions. We can distinguish two types of interpreters: virtual machines and solutions based on the web languages. An example of a solution based on web language is PhoneGap. PhoneGap is an open 25

28 source framework that allows you to create mobile applications using JavaScript API (Application Program Interface). In this categorization we consider component models that are relevant and/or currently used and maintained. Namely we look into Xamarin, OSGi, Oracle ADF, Appcelerator Alloy and CORBA [37]. We chose to focus on these platforms, because they are currently relevant and/or actively maintained. We also analyse at least one representative of the three different component model implementation categories. We are not considering cross platform solutions such as Phone Gap and Enyo JS, because there is no documentation that those platforms support development of components. Xamarin can be assigned in the category of cross-compilers. It provides cross-platform implementation of features in.net using Mono.NET Framework and provides a compiler that, depending on the platform you wish to build the application for, produces a native app or an integrated.net application and runtime [12]. Appcelerator Alloy is a representative of the source code interpreter category. It allows the developer to use JavaScript as the base programming language for developing cross-platform components. It surrounds the JavaScript code with native code so that the component can be executed in a native environment. On Figure 2 can be seen the overall structure of Alloy. Figure 2: Appcelerator Alloy architecture (adapted from [10]) CORBA is a representative of solutions based on model driven software engineering [37]. The CORBA component model (CCM) defines a component architecture and a container framework in which the component life cycle takes place. Oracle ADF can be considered representative of the source code interpreter category. It uses HTML5 as base for creating applications for Android and ios. Oracle ADF Mobile leverages component based development approach to create rich user interfaces across multiple platforms and devices. [6]. 26

29 OSGi can not be considered a representative of any of the above defined categories primarily, because it does not work as a cross compiler or interpreter. It also is not a representative of the model driven software engineering category. However it manages to run components using the JVM (Java Virtual machine) on different platforms. The main categorization we are going to use is based on the categorization described in table 3 in section The component models for mobile platforms need to support these given requirements: is every component an independent software unit, does the component model support composition of components, does the component model support creating complex components, does the component model support cross platform development and finally does it support modular verification. In the context of this categorization, cross platform development implies that the component model should support the notion of develop once and deploy the component to many platforms. Modular verification infers to verifying components to the specific platform requirements before the component is deployed to it. This can prevent potential errors. Component model Independent software units Composition Complex component creation Crossplatform Modular Verification Xamarin Yes Partial Yes Partial No Alloy Yes Partial Yes Partial Partial CORBA Yes Partial Yes Yes No OSGi Yes Partial Not specified Oracle Yes Partial Not ADF specified Partial Partial Table 4: Classification of mobile component models Summary In conclusion we can see that there is a solid base for software component development on mobile platforms. We can also see that the existing component models do not fully cover all component model requirements. Also the current component models we analyze are restricted to the three major mobile platforms on the market: Android, ios and Windows Mobile and are currently unprepared to support the emerging ones like Ubuntu touch, Jolla and Firefox OS. No No 27

30 3.4 Analysis of existing mobile component models In this chapter we analyze existing mobile component models and provide an analysis of their specifications and functionality. More specifically those component models are OSGi, Xamarin, Appcelerator Alloy, CORBA and Oracle ADF. We also provide analysis on how components are supported in the three main mobile platforms: Android, ios and Windows Mobile. There are also other mobile platforms such as FireFox OS, Ubuntu Touch and Sailfish OS. However currently their market share is much lower that Android, ios and Windows Mobile, therefore we will not consider them in this analysis. Moreover we provide an architectural description of a component model that supports cross-platform mobile development based on the information we have obtained by analyzing the above mentioned component models Native components for Android, ios and Windows mobile In this section we analyze native component technologies for the leading mobile operating systems. We provide information on how components are defined in the context of the specific operating system and give an example of how they are deployed, connected and communicate with each-other. Android In Android components are divided into four main categories: Activities, Services, Content Providers and Broadcast Receivers [22]. Activities are responsible for interaction with the user and presentation of the user interface. Services are used to run background tasks. They do not have user interface and can be accessed by different applications installed on Android. Content providers are used to provide structured set of data for applications. They manage the access, provide encapsulation and define mechanisms for data security [1]. The Broadcast receivers are used to receive and respond to broadcast messages from the Android system or other applications. These messages are called events or intents. For example an application can send a broadcast event that notifies other applications that certain content has been downloaded and is ready to use. Communication between components in Android is accomplished by using Intents and Intent filters. An intent announces a wish for communication and the intent filter receives this wish. In order for the communication to be successful the intend should match the conditions of 28

31 the filter. This means that all components that communicate with each other need to use those rules in order to make successful communication. ios In ios a component can be considered the application itself. The main difference between ios and Android is in the structure of the operating system and how it communicates with its applications. In ios every application is a stand-alone application and it can expose certain functionality to other applications to use. However this is done strictly inside the application by using SDK (Software Development Kit) frameworks provided by Apple [5] which means that this functionality can not be exposed as a separate component. The development limitations pose a obstacle for creating components that can be distributed on more than one operating system. This means that when creating such components we need to take into account all those limitations. Windows mobile In Windows mobile components are distributed as packages [17]. Packages are the logical building blocks of the Windows Phone operating system. They contain all the files, libraries, registry settings, executables, and data on the phone. They are deployed individually in the operating system and can communicate between each other in it. Each package is identified through an XML file that contains information about the component ID, what sub-components does it contain (if any) and the package registration key. The main issue is that this component structure is primarily connected to the hardware system. This means that it can not apply to the software architecture of the operating system. However components can once again be developed in the restriction of a single application. The different components can communicate with each-other within the same application and use different functionalities presented by the operating system Appcelerator Alloy Appcelerator Alloy is a MVC (Model View Controller) based framework for the Titanium SDK (Software Development Kit) designed to develop cross-platform mobile applications. In Alloy, a component is created by using Alloy Widgets framework. A widget is self-contained component that can be easily distributed to Alloy-powered Titanium projects [11]. 29

32 Each component has its own identification file widget.json. The file contains a unique ID which is the only mandatory field used for identifying the component. In future the min-alloy-version, min-titaniumversion and platforms keys will also be checked by Alloy for proper validation of the component. The implementation of an Alloy component is also based on the MVC design pattern. Components are build in directory called widgets which is separate from the main solution. Figure 3: Alloy solution structure (adapted from [11]) Alloy supports the creation of new components by constructing them form existing components. This is done by using the Import Widget functionality inside of the component instead of the solution itself. The Import Widget functionality can be described as procedure for composing widgets and assigning how they communicate with each other and with the solution. For example Alloy uses a Widget object to access the provided services of the imported component. Instance of a component can be created by using the Widget.createWidget(widget name, [controller name], [params]) function provided by Alloy. This instance is used to give the solution or other components in the solution access to the component. This shows that composition of components is possible only when the solution is being build. Once the component is connected to the solution and a compiled binary is produced there is no way for the components to be re-composed or to add new components to the solution without creating a new binary. 30