Speed delivery of Android devices and applications with model-driven development

Along with the Android software stack rapidly gaining market share for applications on a variety of devices, embedded product designs are becoming more complex and product lifecycles are shrinking. Efficient development has become essential. This article presents several situations where using model-driven development (MDD) can help developers speed the delivery of Android-based devices and applications.

Share:

Beery D. Holstein (Beery.Holstein@il.ibm.com), Senior Manager, Rhapsody Product Development, IBM

Photo of Beery D. HolsteinBeery Holstein has more than 20 years experience in developing software engineering tools and over a decade of experience with developing Rhapsody, an MDD tool for the embedded, real-time software development industry. He was one of the first members of the team that developed Rhapsody, before it became part of IBM Rational software (i-Logix and then Telelogic). Beery is now managing the development of the core product, including among other things, the code generation, reverse engineering, and round-trip capabilities that underlie support for Android.



06 June 2011

Also available in Chinese

The Android software stack is rapidly gaining market share for applications on a variety of devices, such as smart phones, tablets, televisions, and in-vehicle information and entertainment systems. The diversity of market segments, an explosion in the number of new devices, and the demands of heterogeneous users are forcing device manufacturers and application providers to introduce high-quality, innovative products in shorter time frames. At the same time, shrinking development budgets and a tough economic environment make efficient use of development resources a critical necessity.

With embedded product designs becoming more complex and product lifecycles shrinking, efficient development has become essential. The emergence of model-driven development (MDD) has made it possible to accelerate the development process. With MDD, software engineers can more clearly understand and analyze requirements, define design specifications, test system concepts using simulation, and automatically generate code for direct deployment on the target hardware. This article presents several scenarios where using MDD can help developers speed the delivery of Android-based devices and applications.

About the Android stack

Android is a software stack for mobile devices. It includes an operating system, middleware, and key applications (see the link to "What is Android" in Resources for more information). The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform, using the Java programming language. These include a device emulator, tools for debugging, memory and performance profiling, and a plug-in for the Eclipse development environment. Figure 1 shows the major components of the Android operating system within the application framework, libraries, Android runtime, and Linux kernel.

Figure 1. Major components of the Android software stack
5 layers that build the Android stack

Larger view of Figure 1.

Android software developers can be classified into two kinds: platform vendors and application developers.

  • Platform vendors are the companies that combine software and hardware to produce the actual devices. These devices serve as the hosting environment for smart device applications, at least for the "on-device" portion of the application. (Many such applications also include a server component.)
  • Application developers are the organizations that create the software that calls upon the services exposed by the Android device ("the platform"). In this categorization, it is important to note that platform vendors frequently want to deliver their devices preloaded with a set of applications so that the devices are useful immediately, as delivered Consequently, it is common for platform vendors to develop applications and to ensure that applications developed by third parties work properly with the device the vendor intended to provide.

Model-driven development for embedded systems

Models are used to represent a system at higher levels of abstraction, while promoting consistency, accuracy, and precision. Because the models are at a higher level of abstraction than the source code, they permit the construction of views that can answer specific questions about the functionality, structure, or behavior of the system or software. It is important to distinguish between "pictures" and semantic models. A disconnected picture showing a vague concept can be useful, but a semantically deep model that represents details of the relevant aspects of the software can provide huge benefits to the developer and other stakeholders. Specifically, good models are connected to the software so they always represent the actual content of the source, which increases consistency across views and improves communication of the software.

The most popular modeling language in the world is the Unified Modeling Language (UML), which has been in use for over a decade with huge success. UML is based on a relatively formal definition, known as a metamodel, which gives the language both precision and scope. UML diagrams provide a view of system aspects by graphically representing the model elements and their relationships. A model that focuses on the functionality and behavior of the application can be used to generate a fully executable application that is ready to be deployed on a specific target, RTOS, middleware, and communication mechanisms (see the two books by Bruce Powell Douglass cited in Resources.

Note:
IBM® Rational® Rhapsody® is a visual development environment for systems engineers and software developers who are creating real-time or embedded systems and software. The author uses this software to demonstrate some of the concepts involved in model-driven development (MDD) in convergence with the Android SDK for this article.


Converging MDD with Android software development

MDD provides several ways to speed up the development of Android devices. This is accomplished through a deeper understanding of Android applications and the Android framework, by updating and creating Android applications, and by connecting the software development to requirements, testing, and planning. These benefits are leveraged from within Eclipse, which is the primary development environment for Android hosts, both the Android SDK and the MDD tools for Android.

The Android API as part of the model

UML is a powerful language for modeling, but it provides only a generic template of information for systems. Over the years, UML has spawned a number of variants, known as profiles, for specific areas of development. Modeling closer to the relevant domain reduces ambiguity and provides a clearer view of the design intention for colleagues and customers.

To facilitate development in the Android domain, the Android Framework is being visualized through a model library that consists of the various packages, classes, and public interfaces found in the Android API and through a profile that encapsulates some of the main Android building blocks as stereotypes. Developers can drag elements from the profile and from the model library into UML diagrams. This enriches the design with API use and guides Android application generation from the model. Figure 2 shows a UML profile and a model library based on the Android API. The profile and the model library are used during visualization, creation, and update of Android applications from within the MDD tooling. This enables developers to use the Android terminology in designs.

Figure 2. The Android API visualized through a model library and a UML profile
Packages (Model Library) and Profile for Android

Developing an Android device involves new code, modifications to existing code, existing code that does not change, and third-party libraries. Existing code and third-party libraries can be visualized in the model, resulting in a graphical representation of their structure and relations using UML class diagrams. Such visualization allows developers to understand different aspects of an existing Android application and to communicate them to various stakeholders, such as customers, managers, architects, other developers, and testers. They can also extract documentation from the model, thereby providing a different aspect of communication.

During visualization of an application (and parts of its associated AndroidManifest.xml file), the Android profile and model library are automatically used to identify Android-specific elements, such as activities and services. This results in visualizing not only the application itself, but also its relationship to and its use of the Android API, as shown in Figure 3. Also shown is how MDD is integrated as a plug-in for the Eclipse environment (see the link to Paul Urban's article in Resources), facilitating modeling, coding, and simulation alongside the Android Development Tools (ADT).

Figure 3. Visualizing the structure and algorithm of an Android application
Eclipse with both Java and modeling perspectives

Larger view of Figure 3.

In addition to providing graphical representation, MDD tools can depict execution of the application inside the graphical environment, which enables a better understanding of the application's runtime behavior. Figure 4 shows how the runtime interactions between elements in an Android application that was instrumented with a code agent are automatically captured during its execution. The interactions are captured to a UML sequence diagram in which the vertical lines in the sequence diagram are elements from the Android application, and the horizontal lines show the invocation of operations between elements. By showing the higher-level abstraction of interactions between several elements in the Android application, the runtime behavior of an application is better understood and better communicated to various stakeholders.

Figure 4. Graphical environment provides insight into runtime behavior
Function calls inside Notepad shown on SD

Larger view of Figure 4.

Creation and updating

It is of very little practical value to have diagrams that are not directly connected to the source code. Experience has clearly shown that having two representations of the system semantics, one in the model and the other in the code, quickly diverges so that the model and the code no longer match.

Starting with a fresh model or from a model used to visualize an existing Android application, a matched Eclipse-Android project is created by the MDD plug-in, and the project is populated with code generated from the model. This includes the static portion of the models (for example, packages, classes, and operations) and the behavior modeling (state machine). During this process, the Android profile and model library are automatically used to create some of the "glue" code needed to connect the user code to the Android framework.

Figure 5 shows code generated from a structural model representation. As developers change the model, the source code is automatically updated. Similarly, if the source code is updated, the model is automatically changed to reflect the new source code contents. This ability to associate the model code associativity promotes agility, because the developer can choose to work either in the model or in the source code, and synchronicity between the two is automatically maintained.

Figure 5. Code generated from the structural model
source code and class diagram matching it

Debugging and testing

Although defects are most likely introduced early in the process, they are often found only later on. Moreover, the cost for repairing defects goes up exponentially the later they are discovered. As a result, the challenge is how to find defects closer to the time that they are introduced. If the model correctly depicts the intended functionality and behavior of the application, the model can be brought to life and used to enable early testing and debugging at the model level of abstraction.

In Figure 6, an Android simulator is used to execute an application generated from a model. You can simultaneously see the active state highlighted in UML state charts (created by the developer and used earlier in generating the application) and view the UML sequence diagrams that were automatically generated during execution. You can then compare the sequence diagrams to the application's expected behavior, so you can validate proper design operation. You can also compare the automatically generated sequence diagrams to those from a previous execution of the application to identify changes in behavior that might indicate regressions. A model-based testing (MBT) tool can further use the automatically generated sequence diagrams to execute them automatically, thus both driving and monitoring testing.

Figure 6. Debugging can be done at the code level and model level
Animated statechart and sequence diagram, timer

Larger view of Figure 6.

Collaboration

Developing Android devices and applications can involve managing host system development, legacy application maintenance, hardware development, and more. Managing the integration of these different domains introduces complexity and requires that a holistic view of the architecture be available to development teams working independently on these different domains. The complexity of Android devices leads to increasing challenges in managing joint development lifecycles, testing sequences, and rollouts, and in monitoring and managing these systems after they are delivered. The challenge is further expanded by the large number of distributed teams, which often include agencies, contractors, OEMs, and suppliers.

Continuous validation and verification is fostered by combining requirements, models, quality management, and project monitoring, as shown in Figure 7. The models are made centrally accessible to the entire team and become the source of the entire design. A demo on YouTube (see the link in Resources) shows how Rational Team Center is leveraged for project planning and monitoring.

Figure 7. Collaboratively managing delivery of a smart device or application
ALM tools integrated together

For example, as Figure 8 shows, MDD can be used to better understand requirements by visualizing them in the model. The requirements are stored in the model, and their relationship to design elements and test cases can be created, thereby helping to provide traceability information within the model. This, in turn, can be used during testing to produce requirements a coverage matrix and reports. The information from the requirements, such as the ID or specification, can be automatically generated into the Android application code to enable traceability from requirements, design in the model, and implementation in code.

Figure 8. Requirements as part of the model
Class diagram, requirements attached to classes

Larger view of Figure 8.


Conclusions

Combining MDD capabilities with the Android development environment can help improve productivity, as well as time to market, plus reduce costs. Aside from providing a convenient single environment for both Android coding and modeling, it offers developers visual specification of design requirements. Moreover, the framework can be used to visualize existing Android applications, thereby offering insight into their structure and behavior. The use of models that connect the requirements, design, and code also simplifies documentation and enables the document to be automatically generated.

After the model has been created within the Android development environment, Android applications can be automatically delivered. In addition, the model can be used to execute the design, providing validation and allowing defects to be discovered early in the design's lifecycle. This execution also offers automated software unit and regression testing for improved quality of code. The integrated environment is also a vital factor in enabling collaboration among distributed teams and across development organizations.

Resources

Learn

Get products and technologies

  • Download Rational Rhapsody Developer and try it free for 30 days.
  • Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, Mobile development
ArticleID=678055
ArticleTitle=Speed delivery of Android devices and applications with model-driven development
publish-date=06062011