Assembling Paradigms of Programming in Software Engeneering

Transcription

1 Journal of Software Engineering and Appliations, 2016, 9, Published Online June 2016 in SiRes. Assembling Paradigms of Programming in Software Engeneering Eraterina M. Lavrisheva Mosow Institute of Physis and Tehnology (State University) MIPT, Dolgoprudny, Russia Reeived 20 April 2016; aepted 24 June 2016; published 27 June 2016 Copyright 2016 by author and Sientifi Researh Publishing In. This work is liensed under the Creative Commons Attribution International Liense (CC BY). Abstrat Assembling paradigms programming are based on the reuses in any programming language (PL) with the passport data of their settings in WSDL. The method of assembling is formal and seures o-operation of the different reuses (module, objet, omponent, servie and so on) being developed. A formal means of these paradigms reation with help of interfaes is presented. Interfae IDL (Stub, Skeleton) is ontaining data and operations for transmission data to other standard elements linked and desribes in the standard language IDL. Assembling will be realized by integration of reuses elements in these paradigms on the instrumental-tehnologial omplex (ITC). Keywords Paradigm, Assembling, Theory, Interfae, Reuses, Objet, Component, Servie, Program Systems, Interoperability, Multilanguages, Reengineering 1. Introdution The term paradigm was defined by R. Floyd (1978) and it is a theory and method for setting the style of the writing program. We onsider the paradigm: the modular, objet, omponent, servie, aspet, et. The essene of eah paradigm-independent formal desription of a software element an be used as reuses in other systems. The term build (assemble) was used by V. M. Glushkov (1974) in relation to programmes, whose role is similar to the onveyor assembly into the vehile Ford. This term began to be used by many programmers to build large programs on the IBM framework and almost all ome to a ommon definition of Assembly programming (1982). This programming is by a method of ombining (integration, omposition, aggregation) of the assemblies independent software elements with using the interfae (Stub, Skeleton) to more omplex software struture. Offered paradigms of programming are oriented on development of the omplex program systems from the different formal program elements of these paradigms with the use of interfae objets. A formal vehile inludes theoretial How to ite this paper: Lavrisheva, E.M. (2016) Assembling Paradigms of Programming in Software Engeneering. Journal of Software Engineering and Appliations, 9,

2 and applied aspets of planning the proper elements and operation of their integration in the omplex program systems (PS). Assembling polyglot elements is based on theory of fundamental type of data (FDT), arising up still in the 1970 years of past entury in the works Dijkstra, Hoare, Wirt, Agafonov and so on and ales and standard of general types of data of ISO/IEC (General Data Types GDT) for the generation GDT FDT. A given theory is originally realized on the assembly polyglot in the АPROP (1982) system. The failities of support of speifiation of elements in the multiple programming languages PL, desription of interfaes in the IDL language, saving them in library of prepared elements belong to them. Assembling elements of paradigms in the new PS is arried out by interfaes and the speial operations of instrumental-tehnologial omplex (ITC). These paradigms are taught on the ourse eduation Software engineering for students and also some themes SE for performing by bahelors, by master s degrees, graduate students of faulty of ybernetis of the Kiev national university of Tara s Shevhenko and faulty of informatis of the MIPT. A bunh of theoretial and applied aspets is implemented in the ITC ( and the KNU program fatory ( as CASE-instruments Students an study, reate, ertify and aumulate or onfigure objets and omponents in ITC repository, as well as assemble them in PS [1]-[5]. Next, the paper onsiders the modular assembly, an assembly objet, assembly omponents and Assembly servie programming and general means and methods for assembly programming. 2. Paradigm of the Modular Programming In 1970s years the modular programming, a basis of whih is made by methods of deomposition of subjet domain and integration modules in the omplex strutures appeared. The modules will realize some funtions and will use the funtions of other modules. Module it is logially finished part of the program, exeuting a definite funtion. He possesses by suh properties: ompleteness, independene, separate ompilation, repeated use and so on. The modules aumulated in libraries of the modules, as prepared details, from whih the more PS going and are adapted to the new terms of environment of their treatment. Suh strutures PS were designed top-down, the prepared modules got out from libraries of the modules and going to the new strutures PS. In institute of ybernetis АN of Ukraine development of different approahes to automated was onduted assembling the programs, inluding system of the omputer-aided of the programs manufaturing APROP ( ) [1] [2]. In her main onstituents were: module passport with the interfae (passed data and Call operators) speifiation, method of assembling the different PL modules and funtion of type of data onversion for lass of widely used PL mahines of ЕS. Base oneption of the APROP systeminterfae as a PL ommuniation and modules, on reord in different PL (FORTRAN, PL/1, Algol-60, Assembler, COBOL). Main its objets: module, module-mediator, interfae model of MIL (Module Interfae Language), library of the modules and method of assembling the different PL modules [6]-[10] Interfae Communiation of the Modules in PL Every pairs of modules in different PL assoiates by interfae as a module-mediator (stab in Corba). Communiation of pairs of the funtional polyglot modules was exeuted in the APROP system on OS of IBM-360. Suh produt differed from the traditional monolithi produt by the expressly modular onstrution. In funtion of interfae mediator entered: data ommuniation through the formal and atual parameters; verifiation of aordane of their types of data, quantity and order of their loation of parameters. If types of given parameters unreeving (for example, integer or real), diret and reverse their transformation entered in the mediator funtion. The generation module-mediator ontains the appeals to the elements of library of interfae funtions, whih are exeuted on transition m one module to other and bak. Great number of three from the aused and ausing modules in different PL and module-mediator united in the APROP system in aggregate-monolithi produt on ЕS OS-360, intended for the deision of lass of applied tasks. The refletion of formal and atual parameters entered in the mediator funtion, verifiation of aordane of passed parameters (quantity and loation order), and also their types of data. A model hart of ommuniation of modules in different PL is shown on the Figure 1. The program is led on hart with, in whih two alls are ontained Call ( ) and Call B ( ) with parameters. These alls pass through interfae modules-mediators A and B, whih arry out funtions of data onversion 297

3 Figure 1. Chart of alls of the modules and in through the А and B interfaes. and their transmission to the modules and В/After implementation of the modules and in results will be transformed bak to type of the program С. If types of given parameters not relevant (for example, is passed whole, and result material or vie versa), diret and reverse their transformation enters in the mediator funtion. The generative module-mediator ontains the appeals to the interfae library elements, whih are exeuted in the moment of transition of one module to other and bak APROP System Funtions Exeutes the APROP systems next funtions of union of the modules [1] [2]: treatment of the passport given modules in PL; analysis of parameter of the modules speifiation and drafting a task on treatment of irrelevant types of data, verifiation of rightness of the parameter passing on their quantity and on types of data in the PL lass; type of data onversion in by the PL (b-boolean, с-harater, і-integer, r-real, a-array, z-reord, et.) generator of types of data with the use of interfae library funtions; Generation of the modules-mediators and drafting table of ommuniation of pairs of omponents; Integration of pairs of the modules and their plaing in struture of program aggregate; Translation and ompiling the modules in PL as a prepared program struture; traing interfaes and debugging funtions of the modules in every pair of aggregate struture; testing a program aggregate on the whole; forming the programs of start of program aggregate and doument. In the omplement of the APROP system the next omponents enter: Systems of programming (PL/1, FORTRAN, Assembler, language-onstrutor graphs); Treatment elements (modules in PL, Bank of the modules, Library of funtions of data type onversion, language interpreter, intermodal interfae); Automation failities (treatment of the modules in PL, generation of the modules of ommuniations, assembling the interlingua modules, testing the modules, testing interfaes, testing a omplex aggregate from module); Forming an output result. In this system it is realized assembling, based on two types of interfaes (intermodal and interlinguas) for every pair of the modules in PL. An idea of realization of intermodal interfae in the APROP system is proteted in the andidate s dissertation Grihenko V.N. (1991), method of assembling in the dotoral dissertation of author and in monographs [1]-[3]. Thus, interfae of the modules as a ommuniation of different types of objets in PL mean the first home paradigm of interfae in programming is realized in the APROP system. Two types of interfae are realized in the system interfae of the modules and the PL pair, interfae between modules and interlingual interfaes. Interfae between modules of PS it omponent for the generation of the interfae modules-opulas of the 298

4 interative between itself modules. Interlingual system interfae it is a omponent, ontaining a set of funtions and maros in lass of types of data and strutures of the great number PL on their relevant transformation, desribed higher. Interfae of the modules, as a ommuniation of different linguisti objets in PL mean the first realization of interfae paradigm in programming ( ) [1]-[5]. The generation of the interfae modules-mediators for the two objets with operators of onverting passed data and ontrol transfers enters in task of interfae between different modules (there and bak). Assembling the prepared modules in the APROP system is based on aggregate of the modules in Bank of the modules, their passports and operators of assembling parts of the programs and omplex systems [1]: 1) Operator of the Link assembling, questioner assembling two objets or ount modules; 2) Link sag A (A2, A3 * A4) to link the A, A3 and A4 modules in the segment struture and, where A4 is aused dynamially; 3) Link Prig B ((B1, B2), C = X (C1), D = (Y, D1 = Y1)) to unite the B1 modules, B2, to them to add with and D with the C1 parameters. Y, D1. 4) Operator//The EXEC module А1//PL Trans А1 5) To generate an interfae mediator mod-interfae generation for А1 А2 and so on The rules of assembling determine ompatibility of united objets, whih ontain desription of funtions for the onordane of different desriptions, are presented in their passports. The proess of assembling modules an be onduted by the hand, automated and automati methods. As a rule, the last shift is impossible, is related to the not enough formal determination of the program reuses RC and their interfaes. A hand method is inadvisable, sine assembling ready omponents RC is a large volume of ations, whih arry rather onservative, by what reative nature. The most aeptable method it is the automated assembling, when on the set speifiations of the programs assembling by the standard rules of assembling heterogeneous objets is arried out. The failities whih support a given method of assemble name instrumental by failities of the assembling programming. The failities of ompletion belong to them (unions of omponents in the more omplex objet); interfae failities of desription and use of models of programming (aggregate of models of integration of different program elements). Neessary terms of appliation of this method of programming are: 1) Presene of generous amount of various RC, as objets of assembling; 2) Passport system of objets of assembling; 3) Presene enough s omplete set of standard rules of ommuniation of objets, algorithms of their realization and failities of automation of proess of assembling; 4) Tehnologies by line with sequene of operations of the gradual making and establishment of ommuniations between RC in ase of formation of the system or PS. The last ondition means that the definite forms of PS presentation must exist as knowledge s about the subjet domains, universal from point of planning and PS development. The main thing task of assembling exposure of ommuniation types, desription of them in interfae and realization as a mediator of interfaes between some modules and/or omponents, whih seure their doking or ommuniation in proess implementation in some environment. Assembly method. This method with interfae was developed abroad in the projets MIL, SAA, IBM, Sun, Овеrоn, Corba and so on. The idea of assembling presently beame model in lass of traditional and modern PL. She is realized like in the adopted systems and is based on theory of unreeving type of data onversion in PL and is desribed in guidane s on appliation. New approahes to assembling are published in a number of works, inluding at 1. Bay (Co-operation of the polyglot programs, 2005) and so on. The Corba system for the objetive elements realized a universal manager of mediator broker of objetive queries, whih links prepared objets-methods and omponents in any PL through mediators stub (there) and skeleton (bak). An interfae mediator of objets is desribed in the new language IDL (Interfae Definition Language). In him parameters of data ommuniation are marked in and out between the heterogeneous objets in any PL. Data of prepared objets and RC ontain the type of data delaration in orresponding PL and at their transmissions from one objet to other they are heked on aordane of desription in mediator of stub, them relevant parameters from skeleton. Thus, the result module paradigm is module on whih you an run method of assembly using the interfae. 299

5 3. Paradigm of Objet Programming At the turn of 1980s Grady Booh suggested objet-oriented approah that hanged the way of software development proess. At that point of time strutured programming approah had reahed the risis of omplexity. As suh, appearane of objet-oriented programming (OOP) approah was seen as a way out of the risis of the appliation omplexity. Many analysts and programmers were looking to this approah with skeptiism by seeing it as fashion and not as ompetitive advantage. The main thing that OOP gives is reduing the omplexity of software artifats, the ability to add and remove objets without any diffiulty, hereby solving some aspets of the risis of omplexity [4]-[10]. The objet-omponent theory was built on base of OOP formalisms, Frege triangle and Von Neumann- Bernays-Gödel set theory. This gives a hane to reate ommon mehanism to generalize the notion of objet with the appropriate properties and harateristis. The objet is defined on the objet level analysis involving logial and mathematial onepts of representation, funtion speifiation, Objet Model (OM). Every objet omes to a set О = (О 0, О 1,, О n ), where О 0 is the base objet of domain. An objet of domain O denotes a named part of the real world with a ertain level of abstration; it is desribed by Frege triangle (Denotation, Sign, Conept) (Figure 2). On this figure, eah objet O is presented as O i = O i (Na i, Den i, Con i ), where Na i, Den i, Con i are a sign (name), denotation and the onept of objet, respetively: The sign sets a name of a ertain essene in the real world; The denotation designates an essene by sign; The onept reflets semantis of the denotation, whih is speified at levels of design of objets, bringing in the mathematial apparatus Levels of Logial and Mathematial Modeling of Domain Design of domain model is performed at the four logial and mathematial levels of objet definition (Figure 3): 1) Generalized level is used to determine the basi onepts of the given domain exluding their properties; 2) Strutural level is used to determine the loation of objets in the struture of the model and establish relationships between these objets; 3) Charateristi level serves for setting the general onepts and speifi features of objets; 4) Behavioral level determines the behavior and modifiation of objets based on events that they reate in their interation with eah other. Axiom 2.1. Domain area that is modeled from objets is an objet itself. Axiom 2.2. Domain area that is modeled may be a part of another domain area. When modeling an objet from any given domain area, it has at least one property or harateristi, semantis and unique identifiation in a set of objets of that domain area and the set of properties (prediates) providing relationships between objets in the given domain area. The property of the objet is defined by a unary prediate that takes value of true for its external and internal features of the model. Feature is a olletion of properties (unary prediates), whih are a subset of the set of seleted system prediates whih returns true values if the objet implements suh funtionality. II Sign, Word Designate Express I Denotation, Subjet (reality) Determine Conept, Idea III Figure 2. Frege triangle. 300

6 I. Generalized Level Defines a set of objets O0 O1... On II. Strutural Level Defines hierarhy of objets O1 O0 O2 O3 O3 On III. Charateristi Level Defines a set of prediates for objets I01 I11,I12 O0 O1... In1,In2,In3 On IV. Behavioral Level Defines a objets behavior I11,I12 I01 O1 O0... In1,In2,In3 On Figure 3. Example of objet-interfae graph. At eah level of the design uses the logial-mathematial operations: (,, /,,, ). Relation is indiated by binary prediate over the set of objets and returns true on a given pair of objets. The main types of relationships are: the set to the set, the element from the set to an element of the set, an element of the set to the set, the set to an element of the set. These relation types orrespond to the following operations: generalization, speialization, aggregation, assoiation, details of lassifiation and instantiation. The type of relation 3 and 4 are IS-A and PART-OF. They are used for strutural ordering of pairs of objets. Designing of domain models. Set-theoreti onept lies at the foundation of model design. On the first design level, domain objets are deteted. Then these objets are struturally arranged on the base of binary relation. On the generalized level an objet is regarded as mathematial onept aording to Von Neumann- Bernays-Gödel set theory. On this level of design, the domain area as a set of basi funtions of objets is formed assoiated with deomposition or ompositional hanges in variable objets and omponents. It onsists of a number of funtions that over the transformation of denotations and onepts in the objet analysis and the objets whih inlude hanges assoiated with an inrease or derease in the number of objets. The result of the generalized level is a set of objets О = (О 0, О 1,, Оn), where О 0 orresponds to the modeled domain area. The following is true for the O set: ( ) ( ) I I > 0 & O i O 0 (3.1) On the strutural design level eah objet is presented as a set or a partiular element of the set. In this ase, the expression (1) is transformed into the following form: ( 0 ) &( 0 ) &( ) &( i j ) i j i > j i j O O Here, eah objet (exept О 0 ) is the set of elements or ertain elements of the sets, so set-theoreti algebra operations an be applied to them. This expression defines the PART-OF relation and instantiation. Thus, on this level lasses, lass instanes and so on are defined. The properties of objets and relations are defined for these objets, together with lassifiation, speifiation, et. On the harateristi level, eah objet orresponds to a onept. If О' = (О 1, О 2,, О n ) is the set of objets of domain, and P' = (P 1, P 2,, P r ) is a set of unary prediates related to the properties of objets in domain, then the onept of objet О i is the set of statements that are based on prediate P', assuming truth for the orresponding objet. This means onept Con i = {P ik } provided P k (О i ) = true, where P ik is a statement for the objet О i aording to the prediate P k. Aording to these rules, the properties and harateristis of objets are determined within a given abstration of IS-A for objet onepts. Expression А = (O', P') defines the algebrai system of objets onepts O' and prediates P', intended for objets analysis and identifying domain features. (3.2) 301

7 Axiom 2.3. Every objet of domain has at least one property or harateristi, whih defines the semantis and the unique identifiation of a plurality of domain objets. Prediates P' ontains following operations: 0-ary operations for onstants, unary operations for the objets properties, binary operations to provide relationships between pairs of objets. The behavioral level defines the sequene of objet states and their proesses of transition or refletion from one state to another. The relations between objets are formed on the basis of binary prediates that are assoiated with the objets properties, and the level of relation detailing between the lasses of objets. The main objetive of every level is to desribe the internal and external harateristis of objets, whih it is neessary for organization of onnetion between them. The onept of a lass is replaed by the notion of set. If the objet is part of another objet, it is determined by the set. However, not every objet is an element of any other objet (lass). For example, an objet that is responsible for the whole of a partiular OM is not a part of any other objet in this OM. The definition of the objet is formulated by: every objet is with neessity a set or an element of a set. The regular operations are exeuted over the set of objets: assoiation, intersetion, differene, ombining, symmetri differene, Cartesian produt. Speifiation of objet in a given onept are lass (a set of objets); an instane of a lass (an objet that is an element of a ertain set), onsolidated lass (a set whih is a diret sum of several other sets); rossing-lass (a set that is a ommon part of other sets), aggregated lass (a set whih is a subset of the Cartesian produt of several other sets). Establishment of a partiular domain model has an iterative nature and begins with the definition of domain as the start objet. At eah iteration, analyti funtions that approximate the struture and properties of domain objets are applied until the final model is built Objet Analysis of Domains The modeling of objets is performed in the following system: ( О, I, A, Р ) =, (3.3) where О' = (О 1, О 2,, О n ) is a set of objets, I is a set of interfaes of О'; A' = (A 1, A 2,, A n ) is a set of operations over elements of the set О; P = (P 1, P 2,, P r ) is a set of prediates to define the properties of the objet onepts (for example, Con i = (P i1 ) = true/false). Eah of the operations A' has a ertain priority, arity and assoiates with the appropriate valid desriptions (Na i, Den i, Con i ) of objet signs, denotations and onepts and the set of operations A' = {deds, dedn, omds, omdn, onexp, Conner}. In other words, deds, dedn are deomposition; omds, omdn are omposition and onexp, Conner are ontration. Theorem 2.1. The set of operations A' of objet algebra is a system of operations on the four-tiered representation of the model of the objet domain. The result of the strutural ordering of objet model OM is graph G = {O, I, R}, defined on the set of objets O, interfaes I and relations R between objets. Conditions of onstruting the graph G: The set of verties O displays all domain objets one-to-one; For eah vertex, there must be at least one interfae I k I and relation, owned by a set of relations R; There is at least one vertex that has the status of a set of objets and reflets the domain area in general with aordane to the axioms 2.1, 2.2. Built graph G is omplemented by interfae objets and struturally ordered to ontrol the ompleteness and redundany of graph elements and eliminate dupliate elements (Figure 4). The set of objets-funtions O is assoiated with a set of implementation methods on remote domain objets. During speifiation, the objets are linked through interfae objets from the set I. It means verties of the graph G belong to one of the two types funtional or loal O and interfaes I. In the graph, interfae objets orrespond to funtions desribing data exhanged between objets (Figure 5), methods of data transmission through RPC operators, RMI operations and onversion of some data not relevant in terms of their order of exeution platforms and formats. Graph G set of domain objets and interfaes form the OM. The objets of OM are represented by the general and individual properties or the external and internal harateristis. The hek of objet properties is performed by applying instantiation operations. Interfae objets an be input (In) and output (Out) from the set of interfaes I = (In (O k ), Out (O k )), i.e. the input interfaes In (O k ) and output interfaes Out (O k ). 302

8 O1 O2 O3 O4 O5 O6 O7 O8 Figure 4. The objet graph G. O1 Loal objet O2 O3 O4 Interfae objet Repozitory objet O25 O26 O47 O48 O5 O6 O7 O8 Figure 5. The objet-interfae graph GI. To define the semantis of the objet graph G, IDL interfae language is used (proposed by OMG). OMG was first implemented in CORBA system, oupled with methods for onstruting and developing shared objets [9]. To the aggregate of the set-theoreti operations inlude: Ω = (,, /,,, ). Algebrai system for struturally-ordered level is: Σ = (S, Ω). Objets defined at the synthesis level are provided as sets of elements or a speifi set of algebrai systems Σ = (O', Ω) strutural level. Input and output parameters, whih are exhanged between funtional objets, are desribed by myltilanguages (C, C++, C#, Pasal, Ruby and et.). On Figure 4, objets О 2 and О 5 yield an interfae objet О 2.5, whih seures data exhange for onduting alulations. If types of passed parameters in the interfae objet are irrelevant (e.g., input parameter is integer and output is real), generative funtions are reated for the transformation integer real [10]-[15]. In graph GI (Figure 5) you an build a program P 1 -P 6 using operation, funtion interfae In and the operator link: P О О link P = InO О О ; 1) =, 1 25 ( 2 5 ) =, link P InO ( О О ) 2) P2 О2 О6 3) P 3 ; 4) P4 О4 О7 = ; =, link P4 = InO 47 ( О4 О7 ) ; 5) P5 = О4 О8, link P4 = InO 48 ( О4 О8 ) ; 6) P0 ( P1 P2 P3 P4 P5) Results from the linkage of two objets of a graph (e.g., 2 ( 25 ) =. (3.4) link P O is an interfae objet InO 25. There are many input interfaes oinides with the set of interfaes of the target objet, and a plurality of soure interfaes with multiple input interfaes of the objet transmitter. Axiom 1.2. Advaned graph G with interfae objets that are struturally ordered (top), ontrolled ompleteness, redundany and bakup elements. Objets an have multiple interfaes that an inherit the interfaes of other objets in the ase when they provide the data to the multipliity of interfaes. Many of the objets and interfaes of the graph relates to ommon harateristis of objets in OM. They are 303

9 onsidered to be reliable if the following ondition holds: eah internal harateristi is equivalent to the external harateristis of the objet. If this ondition is not met, the element is removed from the set and from the graph respetively. Formal assoiation operations of objets and interfaes are as follows: O O, In O are a set of input (In) interfae objets; k ( k) ( ) Ok O, Out Ok are a set of output (Out) interfae objets. Classes of objets. When objets are ombined aording to the general harateristis of lasses in the OM, it has following form: OM = (Olass, GС), where Olass = {Olass i } is a set of objet lasses for funtions or methods with ommon properties; GС is an objet graph that reflets onnetions and relationships between lasses and instanes. Eah lass is represented as i i i i Olass ( ClassName, Meth, Field } where ClassName i is the name of the lass; i i Meth = { Meth j } is a set of its methods; i i Field { Field n } =, (3.5) = is a set of properties that determine the state of the lass instanes. i i i i Every Pfieldn Pfield has methods get Pfield n and set Pfield n for writing and reading values of the orresponding properties as attributes and interfaes of OM and omponent models in whih the objets methods are represented by software omponents. The set of methods provided as: { n } { n } i i i IMeth = IMeth get Pfield set Pfield, (3.6) whih orresponds to the interfae Ifun i onsisting from the methods from IMeth i Desription of Interfae Objets Formalism of desription of the IDL interfaes is presented in OMG CORBA. In it, the interfae mediators (stub, skeleton) ontain the passed data definition between PL-objets as stub for a lient and skeleton for the server and operations of data ommuniation between objets [10]. The desription of operations of data ommuniation inludes: Name of interfae operation; List of parameters (zero or more); Types of arguments and results, otherwise void; Handling parameter for desription of exeptional situation, et. IDL language is used for interfae speifiations (suh as stub or skeleton). Interfae options have the following desription: in input parameter, out output parameter, inout ompatible option. The interfae speifiation for one objet an be inherited by another objet and this desription then beomes the base. The interfae inheritane mehanism onsists of saving names of objets without resizing them. It onerns desription of operations, whih must have unique denotations. The names of operations an be used dynamially during implementation of skeleton interfae. A type is desribed in the TD lass, whih is passed through parameters of the RPC operators, RMI, as well as with WCF,.NET protools, et. TD is desribed in one of ООP languages (C#, VBasi, Pasal, and so on). Input and output interfaes for the Р 1 and Р 2 programs (Figure 6) have different semantis, but idential syntati desription in a ertain PL. Data ommuniation between these programs and Р 3 is arried out through the funtions F 1 (.), F 2 (.) and the In and Out interfaes, whih perform TD transformation of data passed between Р 1, Р 3, and Р 2, Р 3. The desribed formalism of interfae is presented not only in the CORBA system, but also in IBM ОS, Mirosoft and so on. It is based on libraries with data type onversion utilities, whih are used during integration of heterogeneous program resoures (objets, omponents, servies). Thus, the result objet paradigm is objet on whih you an run method of assembly using the interfae. 4. Paradigm of the Component Programming The omponent programming is based on Ready Components (RC) reuses. Creation of the new PS from RC is onsidered as a strategially way to the rise of produtivity labors in programming and providing his quality. He 304

10 Figure 6. Chart of funtion alls between objets. is development of the module and objet to the omponents at diretion of generalization of olletive tehnology and priniple of Reusability, as bases of modern industrial tehnologies and fatories of the programs. Indiated types of program elements are united by the general priniple of reusable, whih is used in muh spheres of ativity of different ategories of omputer speialists. But, without regard to that ready RC and omponents a generous amount is aumulated, the omponent programming of the new systems remains problemati, beause for a few years the generation of omputer failities hanges and it requires reengineering onsiderable part of the prepared programs that auses the onsiderable dupliation of funtions. Suh situation was folded as a result of absene of standardized approahes to onstrution of the programs from the prepared program elements, and also reation of elements, and related to absene of neessary theoretial and methodologial base for deision of tasks of reation of the PS from the prepared elements [15]-[17]. It large attention is spared and abroad. She is explored in the state programs of Japan, Great Britain, the USA and so on, and also in the peae orporations (IBM, Mirosoft, Intel, Hewlett-Pakard and et). Problem of reuses are onsidered at the international onferenes during deades. In reuses are laid large faility for the reeipt of inome in ase of development from them of omplex PS, as finanial produts. That is why development of theoretial, methodologial and engineering bases of omponent programming for the deision of this atual tasks, and also ontemporaneity tasks suh, as reation on the omponent basis of the PS, Web-appliations, modern information systems and tehnologies, is a very important and perspetive problem Basi Conepts of Component Programming Component is understood by us as a PL-independent self-relevant of software produt that provides exeution for a ertain set of appliation funtions and servies of applied domain, whih an be aessed with remote Calls [18]. RC as an element of typial repeated deision in PS is neessary typial arhiteture, desriptions and attributes, whih are given in the interfae part and are used at the exhange by data for o-operation of omponents in the different environments. That is given thus omponent, beomes an indivisible and enapsulation of objet, whih satisfies to the funtional requirements, and also requirements in relation to arhiteture of the system and implementation environment omponent programs. Basi operations of omponents are: speifying omponents and their interfaes (pre- and post-onditions, whih must be satisfied by aller them) in suh languages as IDL, API, WSDL et.; maintenane of omponents and reuses into the omponent repository for their future integration olletion RC into Appliations, Domain, PS et. Component program or PS from omponents it is an aggregate of omponents, that will realize the funtional and not funtional requirements to her, is built on rules of onfigurations of olletive type with providing o-operation. Model domain is built in objets whih an be transformed to the omponents with the use of mathematial vehile: models of omponent and interfae, omponent environment, external and internal omponent algebra and algebra system of transformation of types of given omponents for their o-operation [12]. Component onstrution PS from ready RC from the different libraries gives the onsiderable utbak of spending and improves PS quality [17]. 305

11 4.2. The Model Interfae and Component A model of omponent is investigation of generalization of typial deisions and has a kind [18]: ( CNa, CFa, Cln, CIm, CSe) C =, (4.1) where CNa unique identifier of omponent; CFa interfae of providing funtions of management by opies of omponent; CIn = {Cln 1,, Cln k } set of interfaes, related to the omponent; CIm = {CImj} a set of realization of omponent; CSe = {CSer} a set of general system servies. The set of the interfaes omponents CIn = {CInIn CInOut) onsists of entrane CInIn and the initial (output) CinOut initial (output) interfaes (realization is in other omponents) as parameters of interfae. That is the omponent has entrane interfaes at own realization, and initial interfaes of realization other omponent. Eah of them has the proper model CIn ( InNa, InFu, InSp ) = (4.2) i i i i where InNa i name of interfae, InFu i funtionality (aggregate of methods), InSp i interfae speifiation: type, onstants elements of signature of methods, desriptions and others like that delaration. The CFa funtion interfae determines the methods and appeal to the speimen of omponents (searh, hoie, elimination and others like that). Every realization CImj CIm is a set by model: ( ) j j j CIm = ImNa, ImFu, ImSj, (4.3) where ImNa j identifier or name realization, ImFu j funtionality, ImSp j desription speifiation implementation ondition, whih dependene from the definite platforms). A neessary requirement of existene of omponent is been by ondition of his integrity: ( ) CIn i CInI CIm j CIm Pr CIn i CIm j, (4.4) where Pr (CIn i ) means funtionality from realization of CIn i interfae methods. Axiom 2.2. For the union of two heterogeneous omponents C1 and C2 it is neessary the terms exist, if CIni1 CInO1 and CInk2 CInI2 suh, that S (CIni1) = S (CInk2) & Pr (CIni1) CImj2, where S (sign).) means signature of the proper interfae. Tne Model Component PS This model PS is idential to the model of program omponent with that partiulte that by its elements there an be the programs, as independent omponents. 1 {,, n }, 1 { i,, m }, {,, k } PS = PSLm Lm Lm R R R PSLn Ln Ln, where PSLm{Lm 1,, Lm n } a set of the omponent realisation RC, PS; R{R i,, R m } a set of prediates; PSLn{Ln 1,, Ln k } set of interfaes of omponents and programs. The operations of the set R an answer the union or RC onfiguration in some omplex strutures of the programs and PS from the set of omponents interfaes. Components or RC an hange, to be replaed new funtionally by similar, equivalent or idential RC with purpose of reeipt of new variants of the programs produt (PP) after axioms. Primary objetive PS this ommuniation (assembling) of omponents, and also hange some RC idential or equivalent in the PS struture. The ommuniation has it арність and an onsist of set of data, whih enter to the lass of interfaes of the marked lass RC. This operation is exeuted after model of omponent (3.1) and interfae (3.2), whih ontain the prediates, whih determine a ondition of data ommuniation to other omponents. Between omponents the relations an exist: inheritane enterharane, esempliration, ontrat, union (ommuniation). All relations are determined on interfaes and prediates after suh maintenane. Relation of esemplirationї. CInski j = (IInski j, InFu i, ImFu j ) desribes the definite exsemplar omponent C, where: IInski j unique identifier of exsemplar, InFu i interfae funtionality Cln l CIn, ImFu j element, that 306

12 seures implementation realization of CIm i CIm. Relation of ontrat. Between the C 1 and C 2 omponents the relation of ontrat exists ( ) Cont1 = CInO, CInI, IMap, m i m im 2i where CInO1 і CIn1 initial interfae of first omponent, CInI2 m CIn2 entrane interfae of seond, im IMap 12 mapping of aordane between methods, whih enter in the omplement of both interfaes taking into aount signature and passed types of data. If the C 2 omponent has realization of the CInI 2m interfae, implementation of funtionality of the InFu1 і interfae CInO1 і is seured. Relation of interonnetion. If between the C 1 and C 2 omponents the relation of the Cont 1 m 2i ontrat exists, between their opies CIns1kij = (IIns1ki j, InFu i, ImFu j ) but CIns2p mq = (IIns2p mq, InFu m, ImFu q ) the relation of ommuniation in regard to the Cont 1 m 2i ontrat, whih is desribed in kind exists ( 1 j, 2 mq, 12 im ) Bind IIns ki IIns p Cont. Relation of interoperability. If the PS omponents loated in the distributed environment and they enter to the set of omponents, RCs to repository PS, a model of o-operation, definite on the set of interfaes of ready RC and remote Calls is used [18] Model of Component Environment Definition 3.1. Component environment it is a definite set of omponents, whih o-operate between it through interfaes and servies, whih regulate ommuniation between omponents and interfaes, whih are saved in proper repositories. The model of omponent environment has next expression: ( CNa, InRep, ImRep, CSe, CSeIm) CE =, (4.5) where CNa = {CNa i } a set of names of omponents, whih enter in the omplement of environment; InRep = {InRep i } epository interfaes of environment omponents, ImRep = {ImRep j } repository realization, CSe = {CSe i } interfae of system servies, CSeIm = {CSeImr} a set of realization for the system servies. Every element from InRep it is two (CIn i, CNa j ), where CIn i interfae of omponents, CNa i omponent name for whih the interfae exists. Every element with ImRep is like desribed (CIm j, CNa i ), where CIm j realization, whih is desribed by expression (3.4), and CNa j name of omponent, to whih this realization belongs. A omponent environment is onsidered as a set of servers of PS, where omponents-ontainers, the exsempers of whih will realize funtionality of omponent are opened out. Container interommuniation with server is seured through the standardized interfaes (CFa). Interonnetion between different RC, whih are unfolded in the different servers, are seured by realization of the CSe interfae. The ondition of integrity of the omponent program onsists in existene for eah omponent C1 from the CE initial interfae CInO1і and omponent C2 with the proper entrane interfae CInI2m and ontrat Cont12im = (CInO1і, CInI2m, IMap12im), that enters in the omplement of the set Cont. Defenition 3.2. Program system (PS) it is a set RC, funtions (objets), interfaes and data. Will give the PS model with the use of omponents in suh kind: М = CSet, P, PC, M, M, M, M, (4.6) PS f s int d where CSet = {C 1,, C n } a set of omponents; P some prediate from the C i belonging to PS; PC speifi prediate, whih determines, that C i satisfies to the definite funtion from the great number M f ; M f = {F 1, F 2,, Fr} a set of funtions (methods) domens, also omes forward as a model of PS desriptions; Ms = {Ms in, Ms out, Ms inout } a set of servies from ommuniation with entrane Ms in by initial Ms out t and server data Ms inout of PS; M int model of interfaes of interonnetion of objets between itself; M d a set of data and metadata of the subjet domain PS. The sets M f, M s and M i are related to the interfae data (type of in, out, inout) and points of variants.the 307

13 ondition of integrity of the omponent program onsists in existene for eah omponent C 1 with CE, that the initial interfae CInO1і has, omponent C2 with the proper entrane interfae CInI2m and Cont12im ontrat = (CInO1і, CInI2m, IMap12im) enters in the omplement of the set Cont. For desription of funtionality of omponents in different PL with the proper types of data in them are used. In ase of union, integration of suh omponents the task of transformation of types of data passed by interfae for the relevant onverting of types of data aording to model of integrated environment makes up one's mind. Two approahes exist in ase of deision of RC integration problem: 1) Appliation of model of o-operation of pair of polyglot omponents in PL in environment of the distributed systems by their omposition through the module mediator (stub, skeleton) with the use of interlinguas and intermodal interfae [11]; 2) RC interfae desription in the IDL language after the In parameters, Out, Inout for the task of data at the data exhange between itself [9] [10] Transfer Objet Model to Component Model Component program or omponent appliation is a set of omponents that implement the funtional and non-funtional requirements and is built aording to the rules of omponent onfigurations within the omponent model framework. Aording to the formal definition of the domain model, it is a soure of transformative shift from objets to omponents using formal mathematial tools of modeling: models and omponent interfaes, omponent-based appliations, the omponent environment, internal and external omponent algebra onstrution [9]. This apparatus is used for formal development of omponent appliations using reusable assets from different libraries with signifiant redution in osts and improvement of the quality of future produts [2] [7]. Component model emerges from generalized solutions to the nature of objets. The methods of objets are onverted to the omponent arhiteture, struture, properties, and harateristis. There are two approahes to solving the problem of integration of reusable omponents: 1) Use of the interation model through the intermediary module (stub, skeleton) using ross-language and intermediate interfae [1] [2]; 2) Desription of the reusable omponent interfae in the IDL language with in, out, inout parameters to speify the data values. In the theoretial aspet, multilingual omponent integration is based on formal mappings (presented as a superposition of base mappings) Modifiation Appliations from Components The system is assembled from reusable omponents by modifying or adding their interfaes and/or implementations [2]-[5]. The general omponent algebra inludes external, internal and evolutional algebras: { ϕ, ϕ, ϕ } { CSet, CESet, } { CSet, CESet, } { CSet, CESet, } = = Ω Ω Ω, (4.7) where ϕ 1 is the external omponent algebra, ϕ 2 is the internal omponent algebra, ϕ 3 is the evolution omponent algebra. External omponent algebra ϕ 1 = {CSet, CESet, Ω 1 }, where CSet is a set of omponents C, CESet is the environment Е with set of omponents С and interfaes Int. Ω 1 = {CE 1, CE 2, CE 3, CE 4 } represents algebra operations: CE 1 operations of omponent proessing; CE 2 initialization operations; CE 3 = CE 1 CE 2 assembling operations; CE 4 = CE 1 \C operation for extrating omponent С from its environment; C 2 CE 2 = C 2 (CE 1 \C 1 ) substitution operation. Internal omponent algebra: ϕ 2 = {CSet, CESet, Ω 2 }, where CSet = {OldComp, NewComp} is a set of old omponents OldComp and a set of the new omponents NewComp. The set OldComp = (OldCName, OldInt, CFat, OldImp, CServ) inludes interfaes, implementations in the 308

14 server environment; The set NewComp = (NewCName, NewInt, CFat, NewImp, CServ) inludes interfaes, implementations for these omponents; Ω 2 = {addimp, addint, replint, replimp}, where addimp denotes the operation of adding an implementation; addint is the operation for adding an interfae; replimp is the operation of the substitution of a omponent implementation, replint is the substitution of a omponent interfae. Component Evolution Algebra. Reuse is the basis of the omponents evolution. Methods of transformation are divided into two types: methods that hange the funtionality and behavior of the omponents and methods that are assoiated with non-funtional hanges. The first type inludes hanges in the interfae (hanges in interfae signatures, adding a new interfae) and the implementation (hanging algorithms and logi, replaing and adding realizations) and others. The seond type inludes hanges related to non-funtional harateristis of the appliation (reliability, effiieny and mobility), languages and exeution platforms. Component evolution algebra is ϕ 3 = {CSet, CESet, Ω 3 }, where Ω 3 = {О refa, O Reing, O Rever } is a set of omponent evolution operations; О refa is the refatoring operation, O Reing is the reengineering operation, O Rever is the reverse engineering operation for a ertain omponent. Component refatoring model is as follows: Refa n { Refас, { { }}} М = О CSet = NewComp, (4.8) where О Refa = {AddImp, AddNImp, ReplImp, AddInt} is the refatoring operation, the pair (CSet, О Refa ) is an element of the evolution omponent algebra. Components of evolution algebras are built on base of the semantis terms and requirements on features refatoring implementation ORefa ( CSet, Ref ) =, where CSet = {C n } is a set of omponents, and Refa = {AddImp, AddInt, RelImp, AddInt} is a set of refatoring operations. AddImp adds a new implementation of the existing interfae; NewComp = AddImp (OldC, NewCIm, NewCInO) is the operation of adding a new omponent, NewCInt = OldCIn NewCInO s is the operation of adding output interfaes for a new implementation, NewCImp = OldCIm {NewCImp} is the operation of adding a new implementation. Theorem 3.2. Algebra omponent refatoring refa = (CSet, Refa) is omplete and onsistent. Model for omponent reengineering is as follows: Reing n { Reing,{ { }}} М = O CSet = NewComp, (4.9) where O Reing = {rewrite, restru, adop, onver} are reengineering operations, the pair (CSet, O Reing ) is an element of evolution omponent algebra. Reengineering algebra omponents Reing = (CSet, Reing) are used in ase of omponent integrity violation or hanges in their funtionality. Axiom 3.5. For OldInt OldInI there exists an adding operation of input interfaes and orresponding funtionality. This operation is assoiative and ommutative and observes integrity of the omponent. Operation AddImp denotes adding a new implementation of the input interfae, whih is not inluded in the set of omponent interfaes: (,, ) NewC = AdNIm OldC NewImp NewCInt. These operations are assoiative and ommutative. The integrity of the omponent is retained. Operation ReplIm is the replaement of an existing implementation by a new one without hanging the input interfae: NewC = ReplIm (OldC, NewCImp, NewCInt, OldCImp, OldCInt). Lemma 3.1. Operation of replaing the existing implementation with a new one given terms and semantis, mentioned above, preserves the integrity of the omponent. Operation AddInt is adding a new input interfae for an existing implementation. Lemma 3.2. Operation of adding a new input interfae for an existing implementation given terms and semantis, mentioned above, preserves the integrity of the omponent. 309

15 { { }} = =, (4.10) where O Rever = {restru, onver}, the pair (CSet, O Rеver ) is an element of evolution omponent algebra. Rever = (CSet, Rever). In reverse engineering, reengineering operations an be used: Reeng Reverse. The feature of the set Reverse is that its operations are not ompletely defined, but rather partially. It is beause the reverse engineering means omplete alteration of the program system using omponents. Overall, the omponent algebra Refae, Reign, River, as well as models R Refa, М Reing and М Rever onstitute the formal apparatus of evolution algebra from models, operations and methods for the evolution of the omponents. Thus, the result omponent paradigm is the omponent on whih you an run method of Assembly using the interfae. n Reverse engineering model: М Rever ORever, CSet { NewComp } 5. A Common Assembling Model and Methods for All Paradigms Multilingual RC assembling model. Let CSet = {C i } a set of omponents (or objet, module) written in multiple programming languages. During their interation, omponents C i are exhanging data. Eah pair of omponents C i and C j may be equivalent provided they have the same semanti struture and type, or non-equivalent otherwise. In the latter ase their onversion is required using funtions represented by mappings: FN : N > N, FT : T > T, FV : V > V (5.1) ij i j ij i j ij i j with FN ij establishing orrespondene between the names of variables, FT ij desribing the equivalent mapping of data types, FV ij implementing the neessary onversion of data values. Problem of variables replaement FN ij is solved by ordering variable names (for example, in the onfiguration desription for the omponents in question). Mapping between data types FT ij is based on the transformation of data types, eah of whih is represented by an abstrat algebra and algebrai system T = (X, Ω), where X is a set of values that an make a hange of this nature, and Ω is a set of operations over these variables. Refletion FV ij is applied in ase types T i and T j are not equivalent (e.g., the onversion of an integer value to real) [17] [18]. Conversion from the type T i = (X i, Ω i ) to the type T j = (X j, Ω j ) is meant as a onversion, in whih the semanti ontent of operations from Ω i is equivalent to ontent of operations from Ω j. These onversions are available for ommon data types in most programming languages as desribed by the ISO/IEC General Data Types (GDT) standard 11, ; it provides mehanisms for generating FDT from GDT [2]. The problem of omponent interonnetion ours when assembling them into ompound strutures. To solve this problem, the set of refletions is built for different types of method alls, in order to establish a orrespondene between the set of atual parameters V = {v 1, v 2,, v k } of the objet and set of formal parameters F = {f 1, f 2,, f l } for omponents. The problem of onstruting data types using algebrai systems for basi data types used in various PL and isomorphi mapping between algebrai systems are onsidered following [2] [3]. Implementation of interfaes. Interfae is based on transformation of irrelevant type of objets in different PLs, passed through mehanisms of formal and atual parameters. The data, related to general data types and fundamental data types an orrespond to the request parameters of other objets. They may be inompatible between themselves beause of the differing platforms, number of parameters sent, and varying ompiler implementations of data types; therefore, they require the proper transformation [15] [16]. Different programming languages do not have a ommon implementation of fundamental data types and general data types, whih are desribed in ISO/IEC 11,404 standard. Fundamental types are: Simple data types (real, integer, har, et.); Strutural data types (array, reord, vetor, et.); Complex data types (set, table, sequene, et.). They are used by all programming languages and are implemented by translators. General data types are: Primitive data types (harater, integer, real, omplex number, et.); Aggregate data types (enumeration, pointer, set, bag, sequene, et.); Generated data types (whih emerge as a produt of data type generator from one or several data types); Reusable omponents (reuse, artifat, objet, omponent, servie, et.) are desribed in a programming language using one of the standard WSDL, Grid or IDL interfaes. They are saved in the RC repository and interfae 310

16 repository. For data type transformation from one PL into other, three libraries are developed: GDT library; Library for refletion funtions GDT FDT; Library for funtions for data transformation PL і PL j ; Intermediate libraries for funtions and routines for transforming standard data types within a ertain environment (CTS, CRL, FCL) Theoretial integration of elements paradigm (module, objet, omponent, servie and so on) are based on the formal refletions, given as superposition of base refletions. Every omponent has passport data on the WSDL for interfae (Figure 7). In the given time problem of transformation of data it is offered in standard of general types of ISO/IEC GDT data. By us GDT generation to FDT and transformation of them by primitive funtions of the speial libraries of the VS system mahineries are offered.net (CLR, CTS and CLS and others like that). He is used for ertifiation of prepared omponents and saving them in repository of student fatory of the programs From the formal speifiation data, by whih are exhanged every pair of the C i and C j omponents, an be equivalent, if they have an idential semanti struture and type, otherwise not equivalent Theory and Method of Assembling Elements Paradigms in the PL The method of assembling inludes the mathematial theory determinations of ommuniations (from and on the management) between the different language modules and generation of the interfae modules-mediators for every pair of the modules. Communiation of the modules is desribed by operators of all of the CALL type with the great number of atual arguments (in, out, input), passed other, linked funtionally to the module. These data is desribed in the module and interfae [3] [5]. The main task of ommuniation of pair of the different language modules onsists of deision of task of their o-operation. The essene of this task onsists of onstrution mutually of univoal orrespondene between the great number of atual arguments of the {v 1, v 2,, e ve } defiant module and great number of the formal parameters F ={f 1, f 2,, f к1 } aused module and refletion of their data by the algebrai systems. Figure 7. Standard of omponent data definition in WSDL. 311