Software architectural principles in contemporary mobile software: from conception to practice
Architectural principles in Android
We now describe the software architectural concepts and principles that have played a significant role in addressing the challenges described in Section 2, and illustrate them using the architecture of K-9 mail.
4.1. Software architecture building blocks
In any software project, implementation of the software is preceded with a design activity. The design process could be either formal, whereby the design decisions are documented in some preliminary architectural models, or informal, whereby the designer be confused with the usage of the term to mean moving computations to a different platform. simply draws an initial decomposition of the system on a whiteboard. Regardless of the approach followed, the key to this process is how the developer conceptualizes a software system, i.e., the design idioms and elements a developer employs to decompose a system into its constituent parts. Object-oriented constructs, such as classes, are typically too low-level for conceptualizing the high-level structure of a complex software system. The pioneering work of Wolf and Perry (1992), as well as Shaw and Garlan (1996), showed that a proper abstraction for reasoning about the elements of a software system are its Components, Connectors, and their Configurations. Subsequent research on Prism (Medvidovic et al., 2003; Malek et al., 2005; 2007), an architectural design framework for mobile software, showed that these abstractions also provide a proper level of granularity for the design and construction of mobile software. In practice, many of the same constructs devised by the software-architecture research community can be observed in the Android framework. Components are also the basic building blocks of Android apps Google. Android provides four types of components:
1.Activity provides the basis of the Android user interface Google. Each app may have multiple Activities representing different screens of the app to the user. The Accounts component in Fig. 2 is an example of an Activity that allows the user to view the status of its mailbox accounts, and corresponds to the bottom-most screen depicted in Fig. 1.
2. Service provides the background processing capabilities, and does not provide any user interface Google. The MailService component in Fig. 2 is an example of a service that periodically downloads mail from the server, which can occur while a user interacts with another app.
3. Content provider offers data storage and retrieval capabilities to other components Google. It can be used to share and persist data within components of an app, as well as across apps. EmailProvider in Fig. 2 is an example of a Content Provider; it maintains a repository of downloaded emails on a device.
4. Broadcast receiver responds asynchronously to system-wide message broadcasts Google. A Broadcast Receiver typically acts as a gateway to other components, and passes messages to Activities or Services for handling. RemoteControlReceiver is an example of a Broadcast Receiver in Fig. 2, and it dispatches Intents for externally controlling the behavior of K-9. Although classi- fied as a component type in Android, we argue that Broadcast Receiver is best explained as a connector; this is an issue that we revisit later in this paper.
Android also supports lower-level components, called Fragments, that provide another layer of abstraction within an Activity Google. A Fragment serves as a modular section of an Activity, responsible for handling events associated with a particular part of the corresponding user interface. Each Fragment has its own lifecycle, receives its own events, and can be added or removed while its enclosing Activity is running Google. Components and whole apps in Android communicate with one another using a variety of mechanisms. Although the Android literature does not refer to them as connectors, Androidrsquo;s runtime environment provides a variety of connector types. Our study revealed four types of connectors (Mehta et al., 2000) in Android:
1. Explicit message-based connectors enable the exchange of explicit Intents using Androidrsquo;s inter-process communication (IPC) mechanism. An Intent message consists of a payload as well as meta-data describing it Google. The meta-data includes action, data, and category, specifying the general action to be performed by the recipient component, the type of payload, andthe kind of component that should handle the Intent, respectively. An explicit Intent is one where the message is tagged with its recipient Google.
2. Implicit message-based connectors enable the exchange of implicit Intents using Androidrsquo;s IPC mechanism. An implicit Intent is one where the message is not tagged with its intended recipient Google. Rather, its meta-data (i.e., action, data, category) is matched against the Intent Filters specified by other components. Intent Filters are Androidrsquo;s way of specifying the provided interfaces of a component. An Intent Filter describes the kinds of requests a given component can respond to. Interestingly, however, Android does not provide a mechanism to specify required interfaces; we will revisit the implications of this later in the paper.
3. Data access connectors correspond to Androidrsquo;s Content Resolver Google, which provides an interface for adding, removing, and querying the stored data in a Content Provider.
4. Remote procedure calls (RPC) provide IPC through methodinvocation interaction using stubs, which are automatically generated from the specification of a componentrsquo;s interfaces in Androidrsquo;s Interface Definition Language Google.
Finally, Android provides a separate XML file, called manifest, that accompanies each app Google. This file allows for specification of the systemrsquo;s configuration in terms
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[254810]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
