Component-Based Real-Time Design: Mapping HRT-HOOD to UML

Transcription

1 Component-Based Real-Time Design: Mapping HRT-HOOD to UML T. Vardanega Università di Padova via G. Belzoni 7 I Padova, Italy tullio.vardanega@math.unipd.it M. Di Natale Scuola Superiore S.Anna viale R. Piaggio 34 I Pontedera, Italy marco@sssup.it S. Mazzini, M. D Alessandro Intecs S.p.A. via U. Forti - Trav. A, 5 I Pisa, Italy silvia.mazzini@pisa.intecs.it Abstract This paper reports from a project that transposed the HRT-HOOD design method and development process onto a tailored profile of the UML meta-model. HRT-HOOD has methodological strengths which make it apt for componentbased design of hard real-time systems. The UML metamodel is so flexible and comprehensive that it can express and support specific design methods and processes, without leaning towards any in particular. This paper discusses technical and methodological choices made in the mapping and reviews them in the light of a pair of case studies. 1. Introduction The need to reuse software components in embedded systems poses a significant challenge to industrial software processes in view of the ever-increasing software complexity, product diversification and market pressure. Component-based and object-oriented (OO) design techniques promise important progress towards this goal. UML [13, 12, 15], offers notation and a meta-model for the most common OO paradigms. The UML provisions are gaining increasing acceptance because of their generality supplemented by features for extensibility and customization. As a distinct downside of this generality, up to version 1.4, UML lacked most of the features usually required for the design of hard real-time embedded components and consequently spawned a few custom-built profiles. Considerable progress is being made in this regard by the advent of UML 2.0 [12, 15], which, as we will note in this paper, incorporates enhancements that go very much in the direction sought by our HRT-UML project. HRT-HOOD [3] was developed in response to the requirements of mission critical aerospace application developers and captured them so well to earn in its niche domain the reputation of being the answer to the demands from the development of time-critical systems. From the methodological standpoint, HRT-HOOD thus was a true success story, yet critically undermined by shortage of productive enabling technology. The scarcity the HOOD technology offer and the massive surge of the UML caused us to consider whether and how the value of HRT-HOOD could be migrated to and, where appropriate, augmented by the UML meta-model. As a further deciding factor, UML has affirmed itself as the single lingua franca across the software development process as a whole, from requirements analysis down to verification, a status that HOOD cannot compete with. The project vision rested on four founding principles: ffl the prevalence of instances over classes (and of the object model over the class model) in an HRT-minded OO development ffl the provision of support for hierarchical decomposition and for the representation of the topological structure of objects ffl the derivation of classes by means of instance-level examples from an immanent class model kept in the background of the designer workspace (thus without forcing classification upon those who are content with composition) ffl the definition of composable objects, which allow the designer to differentiate between required objects and provided interface instances and to replace the former with the latter as the development progresses. The project built on these four premises, finding insufficient support for them in UML 1.4 [13]. The arrival of UML 2.0 [12], however, seems to have retrospectively confirmed the full value of the intuition behind them. Two independent case studies were launched to assess the expressive power of the method, with specific regard to reuse-geared component-based HRT design. The two case studies redesigned in HRT-UML sizeable parts of two distinct and complementary space software projects, both set on ambitious reuse objectives and expressly aimed at

2 component-based design. The projects used UML as the design notation and HRT-HOOD to inspire the design process. For one case study the project reference was the first iteration of the software architecture of the attitude and orbit control system to fly onboard the European Space Agency s sibling satellites Herschel and Planck due for launch in early For the other, the reference was the latest version of the OBOSS library of reusable software components for the data handling and command system of European Space Agency s new-generation satellites [17]. In this paper we first set the scene for the foundational choices of the method and then discuss them in the light of the findings from the case studies. 2. Component-Based Real-Time Design Component-based design may boost productivity and reliability by facilitating extensive reusability of software units. A component can be a product derived from the analysis, design or implementation phases of the life-cycle, commonly used as a vehicle for the reuse of two basic design aspects: Functionality: The functional syntax and the semantics of the solution the component represents. Structure: The structural abstraction that the component represents, whose extent can range from fine-grained architectural features to subsystem or system level. Components can be specified using abstractions that range from abstract interfaces and framework architectures, to box-port-wire paradigms, to fully realised designs at various levels of structural granularity. Components should be easily adaptable to meet changing processing requirements and environmental constraints through controlled modification techniques (like inheritance and genericity). Most component-based approaches only take the functional aspect of reuse into account, but a real-time system shifts emphasis on the combined satisfaction of functional and temporal requirements. Before reusing the functionality of a component, the real-time designer should know its implications on timing behavior, which may well depend on the internal structure of its realisation. Several interesting notation systems, formalized methodologies and software processes for real-time embedded systems have been defined in the last decade. We obviously cannot discuss them all in this paper, where we limit the discussion to those more directly concerned with our project Object-orientation and UML Object orientation (OO) is a paradigm designed to facilitate reuse. A class represents an understandable black box abstraction and the basic unit of reuse. A class is an encapsulation boundary that contains a set of related data. These data may only be accessed or transformed through the use of operations defined in the class interface, which decouples the set of services (methods) offered or required by an object from their implementation [2]. An OO architecture consists of class instances that interact by means of message passing usually expressed in terms of service calls. UML comprises a meta-model definition and a graphical representation of the formal language, but intentionally refrains from including any design process; rather, it expects that various design processes may be defined using the base language. A UML system model is seen under different views, each corresponding to one or more (types of) diagrams. The general notation of UML can be specialized by designating certain uses of specific constructs as bearing some special semantics; such specializations are called stereotypes. A stereotype is a handy way to classify and label recurring uses of semantically-characterised modeling elements (e.g.: classes, associations, etc.) UML itself includes a range of widely used stereotypes. Extension mechanisms, geared towards domain-specific requirements, are usually provided in the context of a profile. The real-time systems community, for instance, has long been in demand for more specific (i.e., more semantically characterised) concepts and notations in order to cope with the following intrinsic limitations of UML, cf. e.g.: [11, 14]. UML 2.0 has made very promising progress towards productive support of component-based real-time design. In addition to incorporating the OMG SPT, the UML profile for Schedulability, Performance and Time [16], it has expressly catered for structured and hierarchical modeling, thus acknowledging the possible combination of hierarchical decomposition (and its top-down nature) with the bottom-up spin of compositional reasoning. Not surprisingly, the latter notion distinctly emerged as a key requirement from our project s analysis HOOD The founding principle of HOOD [7] was hierarchical, top-down development. HOOD uses the (singleton) object as the main design abstraction. A HOOD object is an encapsulated unit fully defined by its provided and required interfaces, and internally structured as a set of cooperating child objects. The interfaces include operations that can be annotated with information on the associated data flows and possible exceptions, and with the synchronisation semantics of the operation invocations. Objects in HOOD may be active or passive: an active object possesses an own thread of control, and the execution of its provided operations may be constrained by the current internal state of the object. HOOD objects have a structured textual description, called ODS for Object Description Skeleton, which can be

3 viewed as the method meta-model. The ODS contains a number of fields that specify the types, constants and operations the object provides or requires and it may also contain a description of the object behaviour in formalisms of liking to the designer, the typical choice being state machines, for which HOOD offers a graphical notation called Object State Transition Diagram. Hierarchical design in HOOD proceeds through recursive decomposition from a single root object. The final product is a hierarchical structure called HOOD design tree. Where HOOD originally forced a rigid top-down decomposition approach upon the design process, OO promotes a strong flavour of bottom-up reasoning. Either way, though, it is infrequent that the interface of the system components would be precisely defined in the early design phase. A combination of the two flavours therefore seems a more realistic acknowledgment of the designer need. A HOOD non-terminal (parent) object is one which decomposes to a set of child objects. The non-terminal object is said to be in an include relation with its child objects. The descriptor (class) of a non-terminal object will therefore bear an equivalent relation with the classes of the internal objects. A HOOD include relation is complemented by an implemented by relation, which sets the intended correspondence between the items provided by the interface of the non-terminal object and the items provided by the interface of its internals. A European Space Agency (ESA) project of the early 90s produced the HRT-HOOD specialization [3] of the pre- OO version of the method, specifically for HRT systems. A few years after, also on impulse from ESA, the HOOD User Group progressed the base method to version 4.0 [8], this time more OO-flavoured. HOOD 4 relaxed the rigid topdown approach of the method and allowed it to coexist with a distinct flavour of bottom-up reasoning, much in keeping with the view taken by HRT-UML. HOOD 4 and HRT-HOOD inspired P.D. Cornwell s proposal for a true component-based methodology [4]. Cornwell enriches the standard HOOD object with the declaration of a required interface and of a provided interface section, using Z [5] for functional specification and RTL [10] for specifying arbitrarily complex timing constraints. Cornwell also uses placeholders to represent design entities whose implementation is deferred. Such placeholder are akin to abstract interfaces and yet are allowed to participate in object diagrams, much alike to what we propose in HRT-UML HRT-HOOD The definition of HRT-HOOD [3] had the twofold goal to follow suit from the HOOD method [7] and to fulfill the demands of a modern design method geared to HRT systems. HRT-HOOD shed generality from the design abstractions and made two distinctive choices: (a) to incorporate explicit design and analysis support for the abstractions that are typically required by real-time system designers; (b) to constrain the logical architecture design activity, which conveys the functional view of the system, so that it conform, by construction, to a computational model (expressed in terms of a specific set of objects, relations, operations and semantics) which warrants static timing analysis. HRT-HOOD broke the HOOD concept of active object down into that of cyclic (i.e., periodic) and sporadic, each with specific operation and synchronisation semantics and restrictions on the allowable provided and required interfaces. HRT-HOOD also introduced the concept of protected object to permit controlled sharing of resources, on inspiration from the equivalent addition to the Ada 95 programming language [9]. HRT-HOOD further added constraints on how parent objects should be decomposed without breaking the integrity of the parent type, and the requirement that no terminal object could qualify as active but had to specialise as either cyclic or sporadic. HRT-HOOD augmented the HOOD ODS to permit the capture and the expression of the real-time attributes of the object (e.g.: period, deadline, priority, criticality, worst-case computation time). The elicitation of the real-time attributes of objects whose dynamic semantics conform to a specific computational model allow HRT-HOOD designs to be analysed for their schedulability since early in the development cycle. HRT-HOOD further introduces a distinction between the synchronisation requirements on an object s operation and the internal concurrent activity within the (active) object itself. The method defines an agent for the synchronisation, called object control structure (OBCS), and uses the notion of thread to capture the concurrent activity within the object. The thread executes independently of the incoming operation requests (i.e., the invocation of the object s external operations), but when it honours them, it does so in the order dictated by the OBCS, which thus is charged with warranting that the object s provided interface is used exactly as specified. Interestingly, the UML 2.0 meta-model has full well captured the HRT-HOOD notion of OBCS and has usefully unfolded it in terms of interface, port and connection. 3. Mapping HRT-HOOD to UML The true strength of UML most definitely lays in its meta-model, i.e., in its rich selection and standardisation of concepts in support of OO modeling. UML does not define a tight correspondence between models and notations: there can be different notational rendering of the same UML

4 model (i.e., meta-model instance). In UML, meta-model and notation must thus be regarded as separate concerns. HOOD also exhibits a similar dichotomy: the so-called Object Description Skeleton (ODS) is a textual representation of the HOOD meta-model, with a diagram as its notation. Yet, a HOOD model can have only one representation in notational form, so that an ODS can be automatically rendered in terms of a diagram. Specification (meta-model) and notational rendering are thus separate concepts in both HOOD and UML, more keenly so in the latter than in the former. Accordingly, the mapping started first and foremost from correspondences at meta-model level before looking into notational issues. Our mapping goal was to render the [HRT-]HOOD metamodel in UML and possibly to augment it, while striving to preserve the essence of the HRT-HOOD process model. ([18] describes the latter as a reflective process that trades exceeding expressive power and design freedom for warranted structural conformance to a rigorously-defined computational model.) 3.1. Migrating HOOD Objects to UML In UML terms, HOOD objects represent the collapsed view of a descriptor, an object and a behavioral model. The object descriptor would be a lesser UML class, which can never be treated as a type. There can therefore be no class hierarchy, no attribute with a class as a type and no parameter with class as a type in any operation. Consequently, descriptors of HOOD objects cannot be included in inheritance hierarchy structures. An example of the behavioural model (which UML uses, for example, for collaborations) is the rendering of the synchronous/asynchronous semantics of operation calls whose specification is required as part of the operation specification in HOOD. Notably, the unfolding of such a collapsed view provides for more expressive power than we would obtain from the straight mapping of HOOD singleton object to the UML 2.0 classifier role in a collaboration structure. As we shall see, the former route delivers us from the singleton restriction, as lets us access and exploit the class properties of any object instance at will The Prevalence of Objects In standard OO methods, the architectural design of a system is predominantly concerned with class modeling. Conversely, the starting point for an HRT design instance clearly lays the topology of its object instances. From the HRT perspective, a system is built directly defining its objects and their links, instead of its classes and their relations. This need is clearly not catered for by the object modeling of standard OO methods, which simply aims to clarify behaviour and collaboration aspects through the use of scenarios, without however actually designing the system architecture. The HRT-HOOD development philosophy requires all system components to be statically known in number, operations and relations, and to be fully characterised for their real-time attributes, at design time. This requirement promotes object instances to foreground development entities over and above classes. The defining information for an HRT-HOOD system thus is the topology of its objects, that is, what the objects are in HRT terms and the way they are interconnected to one another, which the base HOOD method describes in terms of use and include relations. An HRT-HOOD system is built by directly defining its objects and their links, instead of its classes and their relations. We call topology orientation the characteristic of the HRT domain to require full knowledge about the way the objects in the system are interconnected. An HRT-HOOD design maps onto a pair of UML models: the class model and the object model. The class model alone cannot fully describe the system, for it misses topological information on the instance structure. The object model alone does also not suffice, for it lacks abstract specification of class properties. This choice unfolds separate conceptual elements that the HOOD meta-model was unequipped to single out, but that, we reckoned, all distinctly and usefully participate in the HRT design process. This decision, which deflected us from limiting the mapping to the instance view of the design, using the UML 2.0 classifier role, greatly augmented the expressive power of HRT-UML over that of HRT-HOOD. HRT design does require the object model to come to the foreground and the class model to rest in the background, but it does not want the two views to be isomorphic. Furthermore, we contend that it must definitely be possible for the designer to derive a class model from an HRT object model. In this way the object model attains total expressive power and gives rise to what our mapping calls the underlying class model. The topology-oriented nature of HRT systems is addressed in HRT-HOOD by providing support for: ffl hierarchical decomposition of the software design enabling the construction of abstract components encapsulating structured subcomponents; and ffl specification of implicit composite object descriptors defining not only the composition relations between component and composite entities, but also the topology of the composition. In the following we separately address the need for representing the hierarchical decomposition and the topology of structured objects and discuss for each the current findings from the case studies.

5 Hierarchical Decomposition. UML 2.0 has made significant progress over its 1.4 revision in the provision of support for hierarchical decomposition. Where UML 1.4 only provided packages and subsystems, UML 2.0 now includes structured classes and components. The former options were clearly no match for the HOOD notion of parent object, which has a number of notable characteristics: it a strongly-enforced semantic role at design time, but it is fully replaced by its decomposition hierarchy at execution time, when the parent object disappears altogether. Furthermore, the HOOD notion of parent object is wholly indistinguishable from a child object until the decision is made to actually decompose. Viewing the UML 1.4 subsystem as an interface that will be subsequently replaced by a concrete realisation turned out to be an important revelation: UML allowed us to introduce an interesting separation (both conceptual and methodological) in the place where HOOD forces rigid identity between the parent object interface and its child structure realisation. If one were to retain the HOOD metamodel as is, the direct correspondent of the parent object should obviously be sought in the UML 2.0 structured class. Yet, the pre-uml 2.0 mapping reflection revealed the great potential of considering interfaces on their own merit, detached from imposing any particular child-level structure to the parent realisation. We will return to this issue shortly. The OO parallel to the HOOD include relation is composition. That of the corresponding implemented by relation is delegation. A HOOD non-terminal object thus is either a UML structured class, with a resolved composition of child objects or a UML component with a deferred realisation. The former is the default, the latter an explicit choice (tagging) by the designer. The implemented by relation between parent-provided operations and child-provided operations are mapped into delegation dependencies. HRT-UML retains the HOOD constraint that all operations of the parent class must be delegated. The HOOD use relation between any two objects entails a UML link between the corresponding instances and an association between their descriptor classes. A link between objects is required for them to interact, but the existence of the link in turn requires an association between the respective classes. In fact, the notion of required interface entailed by the HOOD use relation offers an opportunity to further explore the issue of interfaces. In plain HOOD, the required interface simply declares which of the provided operations of the used object the user object actually needs. In practice, it only exists as a reflection of the existence of the entity target of the use relation. If the object ceases to exist so does the required interface. Using a structured class as the target of the use relation while keeping the HOOD mind-set does not help either, for this freezes the topology of the target entity. Using interfaces instead of classes as the target of associations relaxes the need for exhaustive classification: the class of the actual object bound to a requiring object at design time is less important than the guarantee that the supplier object realise the required interface. This interpretation of required interface looks very promising for the realization of a component-based software development support for hard real-time systems in which the expected behaviour is more important than abstract classification. The required interface between objects directly maps to a dependency (an association) from the class of the source (client) object to a UML interface that defines the list and the signature of the operations required from the class of the target (supplier) object. Further specific information (e.g.: the conformance of the operation instance to the nonsuspension requirement and the worst-case execution time of it) will have to be tagged to such interface information to permit this concept to suit the HRT design philosophy. The final definition of the HOOD object stereotype was easily obtained using the UML support for notation specialisation to express the basic conceptual infrastructure as set out above. The mapping then had to produce the stereotype specialisations capable of expressing the conceptual enhancements that HRT-HOOD added to HOOD. That step, however, was preceded by a thorough search for parts of the HRT-HOOD method that might have descended more from inherent limitations of the HOOD expressive power than from intentional HRT characteristics. HRT systems normally exhibit shallow levels of hierarchical decomposition. This occurs because the verification needs of the development process call for early characterisation of the design components, which is obstructed by deep levels of specification. A direct consequence of this observation is that the HOOD notion of root object is too indeterminate to be of any useful value to an HRT design. In fact, an HRT system is thought of and viewed from the outset as a collaboration of concrete instances. HRT-UML views the HRT connotation of the parent object to be expressed as the aggregation of the HRT types of its terminal child objects. This notion implies (recursive) bottom-up reflection of the child HRT attributes on to the respective parent, thereby preserving the ability to perform static timing analysis of the system at any stage of design Structure of Composite Objects. In standard OO, a class model usually just describes the logical structure of a composite object (a non-terminal in HOOD). The actual structure of the individual instances is thus left to class constructors and factory operations. Unlike that, the inner structure of a composite class of an HRT system must be precisely defined at design time, which all of its (static) instances must equally abide by. Variability is limited to the setting of specific attribute values (e.g.: worst-case execution time of a concrete operation, parame-

6 ter initialisation, initial state). The structure of all instances of a class of HRT objects cannot thus be deferred to the logic of factory operations or class constructors, but it must be statically encoded in the object model. The class-level structure of an HRT object is more effectively defined by example, by inferring it from the structure of an actual instance, akin to the OO prototype design pattern proposed by the Gang of Four [6]. For this reason, the method calls prototype instance the corresponding concept, which directly maps into the UML 2.0 structured class. Classes can quite possibly exist in an HRT system as long as all of their instances are statically defined and expose their internal structure clearly. Under the guarantee of static resolution of the instance-to-class relation, recent evidence suggests that even some degree of polymorphism can prove acceptable to the implementation of HRT systems in so far as beneficial to the elegance and, marginally, to the execution speed of the resulting source code (cf.e.g.: [1]). The role of inheritance in the HRT-UML method is still being discussed. One plausible approach to it is the one taken by HOOD 4 [8], which permits derivation by specialisation but only on types, in keeping with the way Ada 95 introduced object-oriented programming via tagged types [9] Findings from the Case Studies. Experience from the case studies shows that reuse-supportive design combines top-down and bottom-up reasoning, whose coexistence is greatly aided by hierarchical decomposition, with its implications on composition and delegation. The reuse objectives of the design, however, also implied frequent escapes into background class modeling. This experience confirmed the basic intuition of the HRT-UML method, but also presented a challenging demand on it, whole implications are discussed in subsequent sections. The evaluation took advantage of the substitution of the HOOD root object by possibly multiple environment objects (already in HOOD and in HRT-UML) whose internal topology, but not the interface, may be deferred. The prescription that the parent object should be completely replaced at project generation time by the composition of its child objects was frequently debated amongst HOOD users and so it was in our case studies. The objection was to forcedly having to delegate all of the parent provided operations to child objects (some possibly viewed as artificial containers), instead of directly implementing some of them. Our project view was that the parent object had to stay what it was meant to be in HOOD, that is, a visibility gate for information hiding, not intended to participate in collaborations at child level, for this would break the principle of encapsulation. The evaluators placed extensive focus on the prototype instance notion. In particular they were tasked to assess the HOOD-inferred prescription that instances of the same prototype instance should all retain the same internal topology and only differ in attribute values and state evolution. The prototype instance concept was found intuitive and attractive, as was the notion of background class modeling. However, the constraint that the instance topology could only be cloned was criticised for being too restrictive. Conversely, the evaluators demanded support for abstracting actual objects into Ada-like generic units (i.e., templates). Ada generic units and the like are in fact viewed and used as very useful artifacts to produce reusable components. The provision of direct support for generic units was deemed inappropriate for the conceptual integrity of the method. A template view of the prototype instance would require that the formal parameters could be bound to actuals that be composite structures (i.e., parent objects) themselves and not just plain values or types. As we shall see in section 3.5 below, there seems to be a more method-friendly way of meeting this requirement The Underlying Class Model The HRT-HOOD development paradigm requires all systems components (all objects) to be fully characterised for type, attributes, operations and relations, at design time. This requirement excludes the use of any form of dynamic creation of instances that may occur at run time, which is one of the distinctive features of pure OO. This paradigm, however, need not abide by the HOOD meta-model concept of singleton class, which disallows even the very concept of multiple instantiation. Static (i.e., design-time) multiple instantiation is the natural middle ground between dynamic run-time creation and plain singletons. This concept was viewed to serve component-based HRT design well and to also be a good fit for the foreground object model / background class model approach of the proposed method. This strategy operates an inversion of the classical OO development paradigm. HRT design is viewed to start from object modeling, which can express system topology and capture the need (the opportunity) for multiple static instances of objects initially drawn as single objects. Accordingly, in the proposed design paradigm, the class model may also proceed from, instead of only preceding, the object model Findings from the Case Studies. The evaluation confirmed the method claim that HRT design aimed at system instances does start out with object modeling. Yet, it also attached crucial value to the provision of expressive design mechanisms to escape to background class modeling and to easily transition between the two views. The solutions the method proposed to this end (which are discussed below) were therefore scrutinised with special attention.

7 3.4. Deriving Classes by Examples With the prototype instance of the object descriptor providing the structure of object instances, the underlying class model only needs to contain the abstract inter-class associations. In this way, the prototype instance defines part of the semantics of a class, but it expresses it in terms of an object model that does not form part of the system under design. Instance generation (in the form of cloning) occurs entails escaping from the object model view to the background class model view. To facilitate this escape, HRT-UML objects carry a descriptor expressed as a pair comprised of: (a) the underlying class, describing the abstract properties of object instances of that class, such as HRT type, provided operation types, required attributes; and (b) the prototype instance, describing the object internal topology, much in the way of the UML 2.0 structured class. The former element is best expressed in class-model rendering and semantics; the latter in object-model rendering and semantics. No components of the object descriptor are displayed as part of the system design: they exist on a different plane, which the proposed method keeps separate from the design level. The designer is however allowed to escape to the object descriptor viewpoint, for example to study (for possible reuse) the prototype instance of a particular object, whether simple or aggregate. Representing entities in this viewpoint requires a specific notational rendering, which shows the topology of the base object and highlights the object parameters that need to be bound at instantiation Findings from the Case Studies. The evaluation found the notion of object descriptor useful, but confirmed the need for the prototype instance not to freeze the internal topology of all the actual objects derived from it. The following section shows how this demand can be met Towards Composable Objects The prototype instance part of the object descriptor carries a load of information value that deserves to be further explored and, desirably, unfolded in more atomic metamodel constituents. As we saw earlier on, HOOD captures crucial aspects of an object definition under the use and the include (and implemented by) relations. The former element may be viewed as the specification of the object required interface. The latter as the implementation of the object provided interface. From an object-model perspective, both interfaces have to be fully defined and fully characterised (hence, be realised) for a system design to qualify as HRT. For example, the provided interface of an HRT-HOOD sporadic object must include an asynchronous start operation that delivers the triggering event for the object s thread of control. Likewise, the required interface of an HRT-HOOD protected object cannot include any potentially blocking operation. From an object descriptor standpoint, however, such interfaces need not be concrete (i.e., directed towards specific object instances), but can simply be viewed as the expression of requirements on what would be required of internal and external instances to satisfy the interface specification of the entity in question. HRT-UML provides the notion of placeholder object to capture this concept. A placeholder object in the prototype instance of an object descriptor specifies the interface requirements to be satisfied for an instantiation of the object and its internal (include) and external (use) aggregates to succeed. The prototype instance concept promotes interfaces, instead of classes, as target entities of associations. Interface specification (which extends the corresponding UML notion, to include all the information contents required for HRT modeling) is more productive and expressive for our purposes than plain classification. Although this concept was developed independently of the tendering process leading to UML 2.0, it was very pleasing to see how closely it resembles the UML 2.0 notion of port. Placeholder objects are initially loose (i.e., unbound) when the prototype instance is created. Such creation occurs implicitly in the background dimension where the object descriptor resides. In the foreground design dimension, placeholder objects are bound to actual object instances that are visible in the instantiation environment and that satisfy the interface requirements. Topological issues arise as we take the HRT view of the use relation into account, which is only fully defined when set between specific instances. In order to preserve the information value of the prototype instance without breaking the integrity of the HRT dimension, we allow use relation to be directed towards placeholder objects, which can be statically bound to specific instances at a later stage of design. In general, placeholder objects will be unbound when the prototype instance of an object descriptor is first created; subsequently, they will be bound to actual objects that are visible in the instantiation environment. The target object of the binding will have to be of the same class as determined by the placeholder, or, in fact, provide the required interface. The expressive power of placeholder objects is especially attractive in the context of reuse-geared, componentbased HRT development, which views HRT design as the static assembling of fully realised instances. Thanks to the ability of placeholder objects to be the target of both use and implemented by relations of HOOD, and the combined use of prototype instance and hierarchical decomposition, the proposed method can accommodate two flavours of HRT components: one in which the link to the placeholder object is external to the prototype instance in

8 question (which thus denotes a fully-resolved component that allows multiple but complying instantiation contexts, much alike the UML 2.0 structured class); another in which the prototype instance itself is a composite, nonterminal object whose provided interface may be realised (implemented by) compliant instantiations of specific placeholder objects (hence akin to a UML 2.0 component). The latter flavour permits full-fledged forms of reuse by adaptation and configuration. Both flavours are obviously geared toward design by composition Findings from the Case Studies. The evaluation clearly showed that the placeholder object concept is a crucial asset for the method to satisfy its component-based reuse-minded HRT design objectives. Placeholder objects allow composability by placing emphasis on required and provided interfaces. Furthermore, placeholder objects only exist in the background class model, without thus breaking the HRT requirement for complete realisation of the object topology at object model level. The evaluation also noted that placeholder objects differ from UML parameterised classes (i.e., templates) in that the latter, much the same as HOOD generic objects, cannot be used in class modeling. The use of placeholder objects is currently being explored in the redesign of the OBOSS library of domainspecific reusable HRT components described in [17]. 4. Conclusion The project that prompted this paper started off with the objective of mapping HRT-HOOD onto the OO meta-model of UML 1.4. The undertaking raised methodological issues that concerns the real-time design process in general. The consolidation of UML 2.0, occurred towards the end of the project definition phase, has offered an excellent opportunity to retrospectively verify the value of the intuitions behind HRT-UML. The project team has recently completed an action to formally update the mapping to UML 2.0, with all indicators confirming the significance of the discussion reported in this paper. Acknowledgments. We are grateful to the authors of the case studies, Henrik Lauritzen, Jesper Lauritsen, Steen Ulrik Palm and Jan Storbank Pedersen, all of TERMA (DK), for their valuable and constructive observations. We acknowledge the financial support of the European Space Agency for the execution of the case studies. The HRT- UML method IPR are vested in both Intecs and the Italian Space Agency, the co-funder of the method definition project. References [1] A. Alonso, R. López, T. Vardanega, and J. de la Puente. Using object orientation in high integrity applications: A case study. In J. Blieberger and A. Strohmeier, editors, Proceedings 7 th Int l Conference on Reliable Software Technologies Ada Europe 2002, LNCS Springer-Verlag, [2] G. Booch. Object-Oriented Analysis and Design with Applications. The Benjamin/Cummings Publishing Company Inc., [3] A. Burns and A. Wellings. HRT-HOOD: A Structured Design Method for Hard Real-Time Systems. Real-Time Systems, 6:73 114, Kluwer Academic Publishers. [4] P. Cornwell. Reusable Component Engineering for Hard Real-Time Systems. PhD thesis, Department of Computer Science. University of York, ac.uk/ftpdir/reports/ycst ps.gz. [5] R. Di Giovanni and P. Iachini. HOOD and Z for the Development of Complex Software Systems. In VDM Europe, volume LNCS(428), pages Springer-Verlag, [6] E. Gamma, R. Helm, R. Johnson, and J. Vlissideds. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, [7] HOOD Technical Group. HOOD Reference Manual 3.1. Prentice Hall, Englewood Cliffs, NJ (USA), [8] HOOD Users Group and J. Rosen. HOOD - An Industrial Approach for Software Design. HOOD Users Group, ISBN X. [9] ISO. Ada Reference Manual. International Standardisation Organisation, Geneva, CH, ISO/IEC 8652:1995. [10] J. Jahanian and A. Mok. Safety Analysis of Timing Properties in Real-Time Systems. IEEE Transactions in Software Engineering, SE-12(9): , September [11] A. Moore. The (continuing) Evolution of UML for Real- Time Systems Development. Dedicated Systems Magazine, Q index004.htm. [12] Object Management Group (OMG). UML 2.0 Superstructure Specification, doc?ptc/ [13] Revision Task Force. OMG Unified Modeling Language Specification, Version 1.4. Technical report, Object Management Group (OMG), OMG document formal/ [14] B. Selic. Turning Clockwise: Using UML in the Real-Time Domain. Communications of the ACM, 42(10):46 54, [15] B. Selic. An Overview of UML 2.0. Lectures at the 2nd Estonian Summer School on Computer and Systems Science, August sum2003/?section=branselic. [16] B. Selic and J. Rumbaugh. Using UML for Modeling Complex Real-Time Systems. Technical report, Rational, whitepapers/umlrt.pdf, [17] T. Vardanega and G. Caspersen. Engineering Reuse for Onboard Embedded Real-Time Systems. Software - Practice and Experience, 32(3): , John Wiley & Sons. [18] T. Vardanega and J. van Katwijk. A Software Process for the Construction of Predictable On-Board Embedded Real-Time Systems. Software - Practice and Experience, 29(3): , John Wiley & Sons.