Conrmon features of current information systems have significant impact on software architectures of the systems. The systems can not be realised as monoliths, formal speciflcation of behaviour and interfaces of thc systenrs' parts are neccssary) as well as specification of their interaction. Moreover, the systems have to deal with many problems including the ability to clonc components and to move the copics across a network (componcnt mobility), creation, destruclion and updating of components and connections during the systems' runtime (dvnamic reconfiguration), maintaining components' compatibility, etc. In this paper, wc prcscnt the component modcl with support of mobile architectures and outlinc its formal basis. We also rcvicw thc rclated research on the currcnt theory and practicc of formal component-based dcvclopment of software systcms.
Increasing globalisation of information society and its progression creatc nceds
for extensivc and reliable information technology solutions. Common
requirements for current information systcms include adaptability to variable structure
of organisation, support of distributed activities, intcgration of well-establishcd
(third party) softwarc products, conncction to a variable sct of external systems,
etc. Thosc f'catures have significant irnpact on software architectures of the
systems. The systems can not be realised as monoliths, exact specification of
functions and intcrfaces of the systcms' parts are necessary, as well as
specification of their cornrnunication and deployrnent. Therefore, the information
systcms of organisations are realised as networks of quite autonomous, but
cooperative, units communicating asynchronously via messagesof appropriate
format. Unfortunately, design and implementation of thc systems have to deal
with many problems including the ability to clone components and to move the
copies acrossa network (i.e. component mob'il'itg), creation, destruction and
updating of components and connectionsduring the systems' runtimc (i.e. dgnami,c
reconfigurat'ion),maintaining components' compatibility, etc. [
Moreover, those distributcd information systems are getting involved. Thcir architecturcs are evolving during runtitne and fbrmal specifications arc necessary, particularly in critical applications. Design of the systemswith dynamic arch'itectures (i.e. architectrtreswith dynamic reconfigurations) and mobi,learch'itectures (i.e. dynamic architectures with component mobility) can not bc done by means of conventional software design mcthods. In most cases,these methods are able to dcscribe semi-formally only sequcntial processing or simple concurrcnt processing bounded to one component without advanced featurcs such as dynamic reconfiguration.
The component-baseddeuelopment(CBD, see [
Although the CBD can be the right way to cope with the problems of the distributcd information systems, it has some limitations in formal description, which restrict the full support for the mobilc architectures. Those restrictions can be delimitcd by usage of formal bases that do not consider dynamic reconfigurations and component mobility, strict isolation of control and businesslogic of components that does not ailow full integration of dynamic reconfigurations into the components, etc.
In this paper, we propose the component model with support of mobile architcctures and review the rclated current formal approaches to the CBD. The rcmainder of this papcr is organiscd as follows. In Section 2, wc introduce our proposcd approach in more detail. In Section 3, we review the main approaches that are relcvant to our subject. In Section 4, we discuss advantages and disadvantages compared with the rcviewed approaches. To conclude, in Section 5, we summarise our approach, current results and briefly outline the future work.
In this scction, wc describeour approach to the componcnt model with support of mobile architectures. The Figure 1 describesan outline of the component modcl's mcta-modcl. Three basic entities rcpresent thc core entitics of a component based architecture: a component, an interface and a connector.
The component is an active communicating entity in a component based software systcm. In our approach, thc componcnt consists of component abstraction and componcnt implemcntation. The component abstract'ion (ConpAbstraction in the rneta-model) representsthe component's specification and behaviour given by the component's formal description (scmantics of scrvices providcd by the component). The component 'implementat'ion (Conpftoplementation)rcpresents
conQtns SuDcomponen{s specific implementation of the component's behaviour (implementation of the serviccs). The implemcntation can bc primitive or compositc. The primi,tiue 'implementati,on (PrinitiveConplmpl) is realised dircctly, beyond the scope of architccture description (it is "a black-box"). The compos'itei,mplementati,on (conpositecomprnpl)is decomposableon a systcm of subcomponentsat the lower level of architecture dcscription (it is "a grey-box"). The subcomponents are rcpresented by component abstractions (ConpAbstraction).
The interface of a componcnt (descendantsof entity Interf ace) can be sorted according to its rclative location compared with the component into public and privatc interfaces. The publi,c i,nterfaces(euuruncrnterface and PubCtrt-Interface) are required or provided (attribute type of the entity) by u component to its neighbouring componcnts at the samc level of the architccture description (i.e. not to subcomponents of a neighbouring component, for example). The priuate i,nterfaces(lrivrunclnterface and Privctrtlnterface), which exist only in composite componcnts, are the components' public interfaces delegated into thc components' composite implementation where they arc available for the components' subcomponents. According to functionality of intcrfaces, we distinguish functional interfaces and control interfaces. The funct'ional,interfaces (luurunclnterface and PrivFuncfnterface) represent businessoricnted services. The control 'interfaces (euuctrtrnterface and Privctrt-rnterface) providc services for components' introspection (e.g. getFunclnterfacesO) and changes of an architecture and behaviour (startO and stopO). The servicesfor changesof an architecturc are, for example, packComponentOand unpackCornponent Ofor a component's transformation into and from a transmittable mcssage,respectively.
The connector is responsible for a rcliable communication between required and provided interfaces. It consists of connector abstraction and connector implcmentation. The connector abstract'ion(ConnAbstraction) representsan abstract connection of a pair of compatiblc interfaces. The connectorimplementation (Connlmprementationr)epresentsspecificimplcmentation of thc connector, which depends e.g. on comrnunication style (buffered and unbuffered connection) or a, type of synchronisation (blocking and output non-blocking).
We focus on behaviour particularly rclatedto the features of mobile arch'itectures, i.c. on creation and destruction of components and connectionsand on passingof components. Evolution of an architecturc begins in thc state where initialisation of ttre architccture is finishcd. Then, a new componenl can be creatcd by meansof duplication of an existing componcntl where thc new componcnt can be placed as a subcomponent of a parent component or sent via its outgoing connections (via providcd interfaccs) . Destruct'ion of a cornponent canbc done automatically after releasing of its provided interfaces (the componcnt is forgotten when there arc no outgoing connections). Creat'ion of new connect'ions between two intcrfaces can be done also by means of passing of componcnts. A componcnt, which is creating a new conncction, rcccives a component with a target interface and obtains the interface via the component's control interface. This enables a,cortrtectiotrto inter:connectsubcomponents of two different parent components if one of the subcomponent is accessiblevia passing of components, i.e. to sharc one subcomponent between many parent components. Destructi,on of a connect'ion can be done directly via connected interface (actually, the connection is forgotten) so no destruction is needed). The pass'ingof a component is realised by means of its control interface (the component is "packed" into a messagc) and control interface of target component (the message is "unpacked" and the component will become a subcomponent of thc target component).
As it follows from the description of behaviour, the connections can
intcrconnect required functional interfaces with (providcd2) control interfaces. This
allows to build systems where functional (business) requirements imply changes
of the systems' architectures.
2.2 Formal Description
The componcnt model's formal description can be realised by means of the
process algebra n-calculus, known as thc calculus of mobi,Ieprocesses[
Formal description of a C componcnt's behaviour can bc expressedas the z-calculus processC : (CtlC.) + stop.start.C.h is a non-detcrministic choice between a parallel composition of processcs,which rcpresent its functional part C7 and control part C", and the proccss that waits for "start" after it receives "stop" via names start and stop, respectively. Intcrfaces of the component C are reprcsented by free namcs in thc process C, by its parameters, if the C is dcnoted as a paramctric proccssC(p1,. ..,p^).
For componcnt abstraction C, the definition of the process Cy is givcn by a designcr of a system or a componcnt, which contains the component C as its t by -"""r packConponentOand unpackConponento 2 in ou. app"rfoach,the control interfacesare only provided (they provide a control)
ComponentModel wilh Support of Mobile Architectures 5 9 subcomponcnt. It represents required functional behaviour of thc system's or component's part. For componcnt primitive implementation C, the definitiorr of the process Cy is givcn by description of functional behaviour of the C component's implementation according to its specification (the implementation is "a blackbox"). For cornponent composite irnplementation, the definition of t h e p r o c e s s C y i s a p a r a l l e l c o m p o s i t i o n o f . n p r o c e s s e s C r ( p t , r , , . . . , p r , ^ 1 ) , . . . , Cn(pn,r,,. . . ,p,n,rn,)that represcnt component abstractions of thc C component's subcomponents, and their interconnections. For each connection between providcd interfaces reprcsented by names pr ,. . . ,pu and required interfaccs representedby namcs Qt,...,eu of the subcomponents,we can define parametric n-calculus process for binding the interfaces
B ( p r , . . . , p u , Q , , . . . ,: eii, ) i : I j : I
q i @ ) . p r ( r ) . B ( p r , . . . , p u , e t , . . . ,( Q1)u )
As it has been describcd in the previous section, the most of the features
of mobile architectures can bc reduced to the component mobility feature. In
thc n-calculus, this featurc can be dcscribed as passing of z--calculusprocesscs:
directly by mcans of higher ordcr z--calculusor indirectly by means of passing of
names ("an executor example" in [
In' c l/ p . p r .. . . , p ^ )\ : p l/ r )\ (/ -r/ \ p t \) . . ._r,\ p . ) ) uc(p,pt, . . ., p,n): (")(p(r).n(pt). . .r(p.)) ( ) \
Those processesimplement interfacespackO and unpackO, respectivcly. The control part of the component C is defined ffiC.:l.Pc. The proccss [/6: is used by a componcnt, which is a destination of passing of the c's interfaces.
There havc been proposcd several component models [
Thc component model FYactal [
Bchaviour of Fractal components can be formally describcd by means of
parametri'sed networks of commun'icati,ng automata language [
In the component model SOFA [
Thc SOFA uses a componen,t,d,efi,ni,t,i,olann,,gu,age(CDL) for specification of components and behaui,ourprotocols (BPs) for formal description of their behaviours. Thc BPs are regular-like cxpressions on the alphabet of event tokens reprcsenting cmitting and accepting method calls. Behaviour of a component (its interface, frame and architecture) can be dcscribed by a BP (interface, framc and architccture protocol, respectively) as the set of all traces of event tokens
ComponentModel with Supportof Mobile Architectures 6l generatcd by the BP. The architccture protocols can be generated automatically from architccture description by a CDL comp'iler. A protocol conformance relati,on ensures thc architecture protocol generatcs only traces allowed by the frame protocol. From dynamic architcctures, the SOFA allows only a dynamic update of componcnts during a system's runtime. The update consistsin change of implemcntation (i.e. an architecturc) of the component by a new one. Compatibility of thc implementations is guaranteed by thc conformance rclation of a protocol of the new architecture and the component's framc protocol.
Recently, the SOFA tcam is working on a new version of the component
modcl. The component model SOFA 2.0 [
Thc componcnt model proposed in this paper is able to handle mobile architcctures, unlike the SOFA that supports only a subset of dynamic architcctures or the Fractal/Fractive, which does not support components mobility. As is described in Section 2.2, the n-calculus provides fitting fbrmalism.
Moreovcr, the proposed semantics permits to combine provided control and required functional interfaces, e.g. in comparison with the Fractal/Fractive that also providcs control and functional interfaces. Regardless, in some cases,it separation descriptiou and vcrification of control and functional parts is needcd. The possiblc solution can be an application of typed z-calculus, which distinguishcs a type of names, and rcplacing of some communication patterns that use controlfunctional bindings by special z--calculusconstructions (c.g. a special stop/start processcs recursivcly controlling also subcomponents of a component, which is stopped/started). Rcgardless, for mobilc architectures, the ability to combine control and functional intcrfaces is nccessary.
The ncxt featurc of the component model is partially independencc of a component's specification from its implementation. This f'eatureis similar to the SOFA's component-templatc relationship. It allows to control behaviour of a primary component's implementation, define a composite component's border that isolatcs its subcomponcnts, which is called "a membranc" in the Fractal, ctc. Our goal is to expand thc specification-implerncntation rclationship of components so it allows runtimc replaccments of the components' implementations without need to stop a component during replacement, in comparison with the SOFA. We bclieve it can be achieved by means of component mobility.
Howcvcr, all above mcntioned fcatures will be parts of an ongoing work. 5
This paper dcscribesthc componcnt modcl with support of mobilc architectures. The component model splits a distributed information system into primitive and composite conrponents according of decomposability of the system's parts, the components' functional and control interfaces according to types of required or provided serviccs, and conncctors realising a communication layer betwccn the components. 'I'he components and the connectors are described at different levcls, as their specificatiorrsand irnplcrnentatious. Scrnanticsof thc entities can be describcd by means of z-calculus processes.
An ongoing work is rclated to completing cxact description of the componcnt model's formal semantics. Future work is mainly related to realisation of a supporting environmcnt, which allows intcgration of the model into a software development process, including integration of verificat,ion tools and implementation support.