Accounting for platform effects in the design of real-time software using model-based methods

Marcus Vitruvius Pollio was a Roman engineer whose legacy includes the oldest surviving engineering textbook, written in the first century B.C.¹ A consummate engineer, Vitruvius dealt with both practical and theoretical matters in his books. His work covers the full scope of the engineering art of the times, ranging from the practical details of the setting properties of concrete, to theoretical discussions on the benefits and hazards of engineering models, to philosophical statements of universal principles of engineering (many of which are as applicable today as they were more than 2000 years ago). For instance, Vitruvius observes that: “[all] machinery is derived from nature, and is founded on the teaching and instruction of the revolution of the firmament.” That is, all engineering products, regardless of their specific technology or purpose, are ultimately constrained by the laws of physics, which must be properly understood and accounted for in the process of design.

However, there are many software practitioners who feel that physics has no place in their domain, which may be one of the reasons why software design has diverged from traditional engineering methods and culture. After all, software can be used to create fully artificial worlds, with their own laws, limited only by the imagination of their creators. The following statement recently published in the Communications of the ACM exemplifies this school of thought: “Because [programs] are put in the context of a set of information requirements, they observe no natural limits other than those imposed by those requirements. Unlike the world of engineering, there are no immutable laws to violate” (emphasis added by the author).² Unfortunately, for applications that are sensitive to time (e.g., systems that need to meet deadlines) or resources (memory, power consumption, etc.), this view of software design can lead to disaster. For example, designers of safety-critical aerospace systems are often limited to using older-generation processor technologies that have been properly certified for the environments in which the systems need to operate. The limited processing power of those technologies can significantly curb design freedom, leading to application architectures whose forms are influenced as much by these limitations as they are by the functional requirements of the system.

On the other hand, designing software that is highly tuned to a particular platform can also have major drawbacks: such software is often difficult to transfer to new or different platforms, requiring expensive rewrites (this is particularly important given the rapid evolution of hardware technology). Platform-specific software can also lead to increased design complexity, as the application logic tends to get intertwined with platform-specific technology details. These unwanted effects have motivated a design approach called platform-independent design, the objective of which is to generate designs that disregard irrelevant technological details of platforms, leading to simpler and more portable software. Unfortunately, this principle is all too often incorrectly interpreted as “platform-ignorant design,” in which all considerations of platform effects are blithely ignored. In such cases, it is useful to recall the famous dictum often attributed to Einstein that things should be made as simple as possible—but no simpler. In other words, while platform independence implies disregarding irrelevant technological details, it does not suggest disregarding the platform and its effects in their entirety, particularly in the case of applications with stringent time and resource constraints.

Finding the proper balance for platform-independent design is one of the skills that successful software designers must acquire, and not just in the real-time and embedded software domains (after all, response time is a concern for practically all software systems, as are upper bounds on required computing resources). This puts software designers in the same category as traditional engineers, for whom this type of trade-off is a primary design issue. In this paper, we describe a systematic approach to dealing with this problem, an approach based on explicitly identifying the ranges of acceptable platform properties for an application and specifying such ranges in a platform-neutral way.

In the following section, we first define and explain the concept of an application platform, extending it beyond the base hardware connotation. Next, we examine the nature of the relationship between applications and platforms and provide a general method of modeling this relationship. Following that, we describe an approach to dealing with platform effects on application design. This approach is referred to as the “acceptable platform pattern.” Finally, we briefly discuss how the recently adopted standard UML (Unified Modeling Language) profile for modeling and analysis of real-time and embedded systems (MARTE)³ can be used to realize this pattern effectively using model-driven development and the UML version 2 specification.⁴

This paper expressly avoids the use of the term “nonfunctional requirements,” even though it has become quite pervasive, particularly in the domain of real-time and embedded systems. While this may at first seem overly pedantic, experience has shown that this term can lead to an implicit bias that can adversely affect software designs. One purely formal objection to this term is that it constitutes a negative characterization: the concept is described by what it is not—which leaves far too much space for interpretation. However, much more problematic is that it creates the misleading impression that the “nonfunctional” aspects of a system can be considered and dealt with separately from the “functional” aspects (i.e., the desired operational behavior of a system). Furthermore, as a reflection of the pervasive “idealistic” (i.e., platform-independent) view of software design, once “nonfunctional” requirements are separated from the functional ones, they tend to become a second-order concern, to be addressed only after the functionality of the system has been handled satisfactorily. As noted previously, this often leads to suboptimal and inadequate designs. Long-term experience has clearly demonstrated that system qualities such a high levels of fault tolerance, scalability, responsiveness, or security are not features that can be easily retrofitted onto a system that was not designed with them in mind from the beginning. Consequently, in place of “nonfunctional requirements,” we shall use the much more appropriate and descriptive term “quality of service” (QoS), which is semantically more closely bound to the notion of a corresponding service (i.e., the “functional” aspect).

Since hardware is required for the running of a software application, one can compare its impact to the impact that construction materials have in traditional engineering disciplines. Specifically, in domains such as architecture or mechanical engineering, designers must be fully aware of the key qualities of their chosen construction materials, since they can have fundamental repercussions on the overall design. In fact, this is why the choice of construction materials (e.g., wood versus concrete) is often one of the first design choices made. As argued in the previous section, the hardware platform can in many situations have an equally fundamental impact on software.

However, the platform supporting a given software application consists of more than simply hardware. Between an application and its hardware platform there are typically intervening layers of software, such as operating systems (OSs) and domain-specific frameworks. The capabilities and QoS characteristics of these intermediate layers can also have a dramatic impact on application software design. For instance, the design of an embedded application such as a telephone switching system, which needs to deal with multiple concurrent asynchronous inputs, is likely be much simpler if it is designed to run on top of a multitasking OS than if it is not.

Taking into account the foregoing considerations, we expand the definition of a platform for a given application to include the set of software and hardware that the application uses to meet its requirements. This fairly general definition encompasses both distributed and non-distributed systems as well as homogeneous and heterogeneous systems. A given platform might incorporate multiple processing nodes, the communication network and facilities that interconnect them, and the software that unites all of the elements into a system. It can be as broad as the entire Internet or as narrow as a single stand-alone microprocessor.

Based on this, a platform can be viewed as a provider of one or more platform services, which are used by applications for their implementations. Platform services typically include capabilities such as processing, communications services, storage services, timing services, or access to specialized devices (sensors, actuators, etc.). Although platform services are used to implement applications, they are not part of any particular application per se. This is because, in the general case, a platform can simultaneously support more than one application, so that individual service instances may be used by more than one application.

The basic conceptual model of platforms, applications, and the relationships between them that emerges from this view is depicted in Figure 1 and described below. We will refine this model slightly later.

Figure 1

The platform concept as defined above is a recursive one: software platforms such as OSs or software frameworks are themselves applications running on top of lower-level platforms. Furthermore, they are often layered internally as well, resulting in multiple platform stacks, all of which ultimately converge at the hardware level.

A well-known example of a platform stack is the seven-layer model of the open systems interconnection (OSI) reference model defined by the International Standards Organization (ISO).⁵ In this case, except for the topmost (“Application”) layer, each layer is a platform that provides communication services to the layer directly above. Thus, each intermediate layer is both an application and a platform.

This type of layering pattern serves two primary purposes: (1) each layer masks the details of its own implementation, including its own platform (i.e., the layer directly below it; an example of the well-known principle of information hiding⁶); and (2) each layer provides capabilities (i.e., services) to the layer above that are not directly available from its own platform. These “value-added” platform services are typically implemented using the more primitive and more general services of its own platform.

In effect, a layer transforms one platform with its set of platform services into a different one with a different set of services. For this reason, platform layering is sometimes referred to as virtual machine layering. Although each layer abstracts the platform below, virtual machine layering should not be confused with abstraction layering (such as described in the RM-ODP [Open Distributed Processing Reference Model]⁷), in which each single system is viewed at different levels of abstraction. In contrast, each layer in a virtual machine stack represents a different entity, adding functionality that does not exist in its supporting layer.

A key design principle of virtual machine layering is strict adjacency, that is, a layer is only allowed direct access to its immediately neighboring platform layer, and not to any of the platform layers below that. Clearly, violating this principle would defeat the primary information-hiding purpose of virtual machine layering. (There is one more important basic characterization of virtual machines, namely that whereas the application is dependent on the platform, the platform is not dependent in any way on the application; this is not of major concern for the discussion in this paper.)

However, this core principle appears to present some conceptual difficulties. As part of the software that implements the different layers above the hardware, each of these software layers will likely need access to a variety of different platform services, such as storage management and timing. For example, each layer will need access to a storage management service (e.g., to get or release dynamic memory). Furthermore, it is likely that each layer will need the same kind of storage service. Where should such services reside with respect to the OSI layers, keeping in mind adherence to the strict adjacency principle?

One possibility is for each layer to provide all of the necessary implementation services for its adjacent layer. For example, each layer would provide the same storage management service. The problem here is that this would mean either multiple implementations of the same service or some mechanism for relaying the services of its own platform (and, arguably, violating the adjacency principle). In either case, there will be some duplication overhead and inefficiency.

A more elegant and more effective solution is to implement orthogonal service stacks. The OSI model focuses exclusively on the communication services infrastructure and specifies nothing about other kinds of services. The layering here is strictly based on the specific needs of communications services. It is perfectly reasonable to assume that different types of services may have different layering criteria and, possibly, a different number of layers. Therefore, it is inappropriate to fit all the various types of platform services into a single, unified layer hierarchy. Instead, each different type of service can have its own custom layer stack. Furthermore, as different service stacks use other service stacks for their own implementation, the structure that emerges is a complex one that covers as many dimensions as there are service stacks.

One of the consequences of this multidimensional view of platform stacks is that it is not possible to represent complex system architectures accurately using simple, two-dimensional layered structures (a common, but inaccurate and misleading practice). Instead, they involve complex, multidimensional stack topologies, all of which converge on a common hardware layer at the bottom. This intricate but accurate representation of layered applications and platforms is necessary when specifying system architectures to an implementation team or for more precise analysis of key performance indicators.

Another useful conclusion that can be drawn from the conceptual model in Figure 1 is that the relationship between an application and its platform can be viewed as a client/server relationship, with the applications being clients of services provided by the platform. This view is helpful, since it allows us to deal with the various aspects of the application-platform relationships using the well-understood client/server paradigm.

To properly account for the physical effects of the various platforms, all of which are fundamentally dependent on the physical characteristics of the underlying hardware platform, it is convenient to introduce the concept of the QoS characteristics of a service. This is a specification of how well a particular service can be performed or how well it needs to be performed. This definition identifies the two complementary perspectives of QoS. From the platform side, there is the perspective of the available or provided QoS; i.e., the QoS that the platform can offer to the application; from the application side, the concern is with the required QoS, that is, what the application needs.

Clearly, if a system is to function properly and meet its requirements, it is necessary for the provided QoS characteristics of the platform to be greater than or equal to the required QoS characteristics of the application. Unfortunately, it is rarely straightforward to predict whether the provided QoS characteristics of a given platform are sufficient, because platforms are often shared by multiple applications that contend for the same platform resources (e.g., memory or CPU), thereby interfering with each other's operation. Computing the effects of this interference is extremely difficult, since it often depends on the dynamic state of the executing applications and the idiosyncratic nature of the services involved.

By definition, a platform involves hardware, which means that it has a physical extent. In other words, it occupies physical space and has one or more locations, which may be geographically dispersed. This is particularly relevant when dealing with distributed platforms, such as modern LAN-based systems or the Internet. Physical distribution implies that a platform service may have more than one access point. Furthermore, the same service may have different QoS characteristics at different access points, depending on the platform characteristics at each location. To deal with these aspects, we introduce two basic refinements to the conceptual model of platforms: service provision points (SPPs) and QoS domains.

An SPP is a specific interaction point belonging to a specific platform at which an application can request the corresponding platform service (see Figure 2). Each SPP has: (1) a location that identifies its position relative to its platform; (2) an identity that distinguishes it from all other SPPs owned by the same platform; (3) a service type that identifies the services that can be accessed through it; and (4) a set of provided QoS characteristics that specify the QoS values of the services offered by the SPP at a particular point in time. In principle, an SPP can change its location and its QoS characteristics over time, but not its identity or service type.

Figure 2

The purpose of the SPP concept is to account for the fact that, at any given point in time, the QoS obtained for a particular usage of a platform service is a function of the time and location at which the service is being provided. It is also a convenient and systematic mechanism for introducing the concept of platform QoS. The simplest possible case is that of a platform service that has just a single static SPP, one that remains in the same location with an unvarying QoS.

A QoS domain is a collection of one or more SPPs, either of different or identical service types, such that the provided QoS characteristics of all SPPs of any given type have the same QoS values. In other words, a QoS domain models an environment where the QoS is homogenous throughout (i.e., it is independent of the SPP location within the domain). This does not imply that the precise QoS values experienced will necessarily be identical for each usage, since some QoS characteristics may be specified as value ranges or probability distributions. However, those ranges or distributions will apply equally to all SPPs belonging to the same domain.

For example, consider a QoS domain that offers a communications service. Within such a domain, communication properties such as delay, throughput, and reliability are the same regardless of which SPP is used to access that service. On the other hand, two different QoS domains offering the same service type can have very different QoS values. For instance, a messaging service between two nodes located on a LAN will have very different communication delays and reliability properties than the same service operating across the Internet. These services would be represented by two different QoS domains.

QoS domains are useful for a number of reasons. First, they simplify the modeling of islands of homogeneity in a heterogeneous platform, which is how many distributed platforms are constructed (e.g., through federation of multiple platforms). Common examples of QoS domains are OSs, middleware, security domains, application frameworks, and so on. In addition, QoS domains can greatly simplify software deployment, since they can reduce the granularity of the problem involved in matching application platform requirements to individual platforms. Finally, application designers can exploit QoS domains to simplify their designs by explicitly targeting parts of their application to specific QoS domains. For example, a QoS domain may have a “fail-stop” processing-service QoS characteristic; in such a domain, the failure of the processing service implies simultaneous complete failure of all applications in that domain. This means that applications intended for such a domain do not need to provide complex recovery code to deal with partial system failures.

The conceptual model of platforms described above is quite general and covers most of the interesting types of platforms encountered in practice. It not only allows the qualitative modeling of platforms but, through the QoS characteristics mechanism, it also enables the modeling of the quantitative aspects that can be so crucial in the design of real-time systems. Hence, we refer to it as the canonical platform model. A simplified Meta Object Facility (MOF)⁸ metamodel that identifies the basic concepts of canonical platforms and their relationships is shown in Figure 3.

Figure 3

In the introduction, we discussed the tension that exists between the need to make applications platform-independent so that they can be easily transferred to new or different platforms and the need to account for the impact of platform characteristics on the design of software. In this section, we explain how to resolve this apparent dilemma using the concepts from the canonical platform model.

Software deployment involves the allocation of applications to platforms. A key issue involved in this is ensuring that a platform offers the right services and that these services have acceptable QoS characteristics from the point of view of the application. Part of the difficulty is that few applications have explicit declarations about the platform services they require and even fewer specify the required QoS. In the absence of such information, it becomes necessary to inspect the code or to discover it through trial and error. Particularly problematic is the lack of expected QoS characteristics, since that information is often implicit in the code. For example, does the application assume that communication is reliable or not? What are the assumed worst-case communications delays? What kind of context-switching overhead is acceptable? What is the minimal processor speed required for the application to meet its deadlines?

One way of dealing with this issue that matches the canonical platform model is through the concept of service access points (SAPs). An SAP is similar to an SPP except that it is attached to the application and it represents an explicit declaration of a required platform service. It has an identity that uniquely distinguishes it within the context of its application, a service type, and a required QoS characteristic.

With SAPs, deployment is reduced to matching each application SAP to a corresponding SPP on the platform; that is, matching clients to servers. A corresponding SPP for a given SAP is one that matches the service type of the SAP and which provides QoS characteristics that are at least equal to if not better than the required QoS characteristics of the SAP.

Due to sharing of platform resources, having a provided QoS that is equal to or greater than the required QoS may not always be sufficient. Thus, a processor may provide the desired performance for either of two applications but may not meet the required QoS when hosting both at the same time. This means that additional analyses may be necessary to properly determine whether or not a particular platform will support a given application. Well-known examples of such analyses are various types of schedulability analysis^9,10 and performance analyses based on queuing theory.^11,12 The SAP-SPP mechanism can greatly simplify such analyses, since it provides explicit and systematic facilities for dealing with QoS issues.

As noted earlier, QoS domains are also beneficial in dealing with deployment problems, since applications are typically designed with specific homogeneous platforms in mind (e.g., an application may be designed to run on a particular framework, such as J2EE** or .NET,** or for a particular OS such as Linux**). In such cases, it may be sufficient to match QoS domains rather than individual SAP-SPP pairs.

In the course of application software design, assumptions are often made about the nature of the platform for which the software is intended. Unfortunately, as noted earlier, these assumptions often remain implicit due to the lack of awareness of their significance. The SAP and QoS domain mechanisms provide a systematic facility for the explicit declaration of such assumptions. In fact, a specification of the complete set of SAPs and QoS domains of a given application determines the set of all platforms capable of successfully hosting that application. Consequently, we refer to this specification as the acceptable platform specification. Any platform that meets or exceeds the QoS characteristics of the acceptable platform is suitable for the application.

Since acceptable platforms can be defined in terms of QoS characteristics rather than in terms of specific technologies or platforms, they allow designers to fully factor platform effects into their designs without being bound to a particular platform or technology. Thus, the highly desirable goal of platform independence can be achieved, not by ignoring platform issues but, on the contrary, by explicitly declaring the assumptions that have been made about platforms using platform-independent QoS characteristics. One additional benefit of explicit acceptable platform specifications is that it becomes possible to formally validate the consistency, feasibility, and completeness of platform assumptions made in the application.

In the following section, we explain how the recently adopted MARTE standard, in combination with the newly revised Unified Modeling Language (UML 2), can be used to specify acceptable platform specifications.

UML 2⁴ is a significantly revised version of the original UML, first issued in 1996.¹³ The principal motivation for this revision was to adjust UML to better support model-driven development—an approach to software development in which models take on a central role in the development process. In particular, this involved refining the semantics of UML concepts and relationships, adding greater precision and clarity, thereby making the language much better-suited for formal specification as opposed to mere documentation.

However, UML 2 concepts tend to be defined at a relatively general level, since the language is intended to support a broad spectrum of different application domains. To give it the precision and expressive power required to accurately model real-time and embedded software systems, it needs to be specialized by refining some of the general concepts and adding missing capabilities. The recently adopted MARTE profile³ fulfills that purpose; it supplements standard UML with a number of specialized concepts characteristic of the real-time and embedded domain, including:

• A set of standard and highly expressive facilities for modeling common elements of hardware and software platforms, as well as relationships between applications and platforms

• Standard methods for modeling time, including diverse logical and physical models of time and corresponding timing mechanisms

• A standard way of specifying QoS characteristics, their functional relationships, and values

• A standard framework for analyzing UML models to which the MARTE profile has been applied. This includes special provisions for analyzing the schedulability of real-time systems and also for analyzing the throughput and timing performance of such systems. The profile can also be extended to support other types of analyses.

The MARTE profile can be used in two ways. In combination with UML, it can be used as a domain-specific language for specifying real-time software applications and their platforms. In some cases, it can even serve as a fully fledged implementation language. For example, MARTE can be used to model a real-time multitasking OS, since it directly supports domain-specific concepts such as tasks, schedulers and scheduling policies, mutual exclusion mechanisms, and so on. Alternatively, it can be used as a kind of optional overlay on top of existing (non-MARTE) UML models to annotate elements of those models with real-time-specific information, such as their QoS characteristics and values. In either case, models that use MARTE can be used to drive or generate implementations (e.g., using automatic code-generation methods) as well as to compute key performance indicators of systems, such as expected throughput, timing properties, resource usage, etc.

Figure 4 shows an example of how the MARTE profile can be used to model the hardware of a multi-core processor platform with two disk drives. The stereotypes shown in this diagram (which is an example of a UML collaboration diagram) such as «hwProcessor», «hwBus», and «hwDrive», representing physical processors, buses, and disk drives, respectively, are predefined by MARTE. Each stereotype includes a set of attributes that characterize the QoS characteristics of the corresponding resources (e.g., number of processor cores, the MIPS [millions of instructions per second] rating of a processor, or storage capacity of a memory device). The values of these characteristics can be supplied directly in the model as shown in this example.

Figure 4

One of the domain-specific modeling capabilities provided by MARTE is the generic component model (GCM). This is a specialization of the structured classifier concept of UML 2, which, among other features, includes the ability to represent objects with multiple points of interactions called ports. A port is a run-time entity that offers a set of services to clients. It may also specify a set of services that it, in turn, expects of its clients. The port concept is conceptually proximate to the SAP and SPP paradigms described earlier.

MARTE extends the base port concept in two ways. First, it allows direct specification of QoS characteristics, which is precisely what is needed for representing SAPs and SPPs. Second, whereas UML ports only support event-based discrete information flows (e.g., incoming and outgoing messages or operation calls), MARTE ports can also model continuous flows through ports. Consequently, MARTE ports can even be used to model services characterized by continuous quantities, such as processing (CPU) capacity or communications bandwidth.

This leads to a relatively direct representation of the canonical platform model described in the section “On platforms.” That is, a platform can be modeled as a structured classifier (either as a structured class or as a UML collaboration) whose parts represent either QoS domains or platform components with MARTE ports corresponding to the SPPs of the platform and their associated QoS characteristics. For example, Figure 5 shows how the platform model from Figure 4 can be rendered using the concepts of the canonical model. Only the relevant aspects of the platform model are included here, resulting in a greatly simplified representation that is well suited for analysis. In this particular case, only the storage capacity and the processing power characteristics of the platform are deemed of interest. They are modeled by ports (SPPs) whose types and stereotypes match the types and stereotypes of the corresponding resources. In other words, these ports serve to selectively expose parts of the platform.

Figure 5

The same approach can be used to model acceptable platform specifications with the SAPs represented as MARTE ports of the appropriate kind. The only difference between a SAP and an SPP is that the former are conjugates of the corresponding SPPs; this simply means that the required and provided sides are inverted. Therefore, SAP ports are used to specify required platform services and QoS characteristics, as per the canonical model.

MARTE also provides the capability to model the relationships between elements of the application and elements of the acceptable platform. This is achieved by using the «allocate» dependency (a stereotype of the UML dependency modeling concept), which is a general mechanism for modeling deployment in MARTE. An example of this is shown in the collaboration diagram shown in Figure 6(A). In this case, the application consists simply of a client component that accesses a video-stream server over a network. The acceptable platform is represented by the five components enclosed within the orange rectangle. Each component of the acceptable platform is stereotyped by the appropriate MARTE stereotype and each has the appropriate SAPs. To reduce clutter, only the QoS characteristics of the apSNode component are shown. Note that the types of these SAPs correspond to the types of the SPPs defined in Figure 5 for the ServerNode class. The QoS values capture the required QoS characteristics of the application.

Figure 6

To determine whether this application can be deployed on a given platform, it is necessary to determine whether the platform can provide the required QoS. This, of course, depends on how the application is deployed on the platform, which is again represented using the «allocate» dependency, as shown in Figure 6(B). The platform, in this case, comprises three physical elements: two processing nodes and a local area network. One of the nodes (sn) is an instance of the abstract model (ServerNode) depicted in Figure 5.

The canonical model can significantly simplify analyses of this type, since it shows very precisely and yet very simply where and how the platform and the application meet. Only the aspects and values of interest to the analysis need to be specified.

Although software is ethereal, its execution is a physical phenomenon that occurs in real time and requires real physical resources and energy. Since the quality of the execution of a program is a direct consequence of the physical capacities of the hardware and software platforms on which it is run, it is sometimes necessary to factor platform limitations into the design of an application, similarly to the way that traditional engineering disciplines account for the properties of their construction materials. This is particularly important in the domain of real-time and embedded systems, where the quality of execution is a fundamental criterion of correctness. Unfortunately, there has not been much methodological or theoretical support for dealing with this problem, with the result that there is a high risk of failure—a risk whose magnitude is often only fully comprehended late in the development cycle, when design changes are protracted and expensive.

This paper has described an approach that provides a systematic and relatively straightforward conceptual framework for reasoning about platform effects on application designs. First, the relationship between an application and its platform is modeled as a case of the well-known and well-understood client/server paradigm, characterized by a formal contractual relationship between the two. The application is the client, with explicit specifications of the services that it expects of the platform including, notably, the QoS that it deems acceptable. Conversely, the platform plays the role of the server, with characterizations of the QoS that it can provide. The explicit nature of this contractual relationship can greatly simplify analyses of platform effects and is particularly well suited to formal analysis methods. Second, our conceptual framework includes a general model of the relatively complex internal structure of platforms, which goes beyond simple and frequently inaccurate two-dimensional renderings. This is not only useful as a guide for platform design but also enables much more accurate predictions of platform effects during analysis. Third, a platform-independent method for designing platform-sensitive applications was described as part of the approach. This is based on the acceptable platform pattern, which characterizes platforms in terms of technology-neutral QoS requirements. Finally, we have shown how this method can be realized using the latest industry standards for software modeling, MARTE and UML 2.

**Trademark, service mark, or registered trademark of Sun Microsystems, Inc., Microsoft Corp., or Linus Torvalds in the United States, other countries, or both.

Accepted for publication December 3, 2007; Published online May 8, 2008.