Modeling deployment and allocation in the Progress IDE

Full text

(1)Master of Science Thesis (D-level). Akademin för innovation, design och teknik. ˇ David Senkeˇ r´ık. Modeling deployment and allocation in the Progress IDE. Mälardalen Research and Technology Centre Thesis supervisors: Séverine Sentilles, Jan Carlson Thesis examiner: Ivica Crnkovic {severine.sentilles,jan.carlson,ivica.crnkovic}@mdh.se. 2009.

(2) I gratefully thank my supervisors, Séverine Sentilles and Jan Carlson, not only for their important comments and priceless remarks, but also for their help with technical and administrative support of the thesis. I also thank Tom´ aˇs Bureˇs for opening up the opportunity for me to write the thesis at Mälardalen University..

(3) Abstract This thesis investigates the deployment modeling in the scope of Progress, a research vision that aims to tackle the increasing complexity of embedded software systems by adopting a software-component approach. The first phase of the Progress deployment process, which is in the focus of this thesis, defines virtual nodes architecture as an abstraction of target platform devices where components are allocated. Based on the Progress development process analysis, the thesis identifies concerns that need to be addressed by the ProCom component model to support the concepts of virtual nodes and allocation, proposes the extension of the ProCom meta-model and the design of allocation in general. The thesis also provides an implementation of a tool support incorporated into the Eclipse application that forms the basis of the Progress IDE. The implementation, whose main goals are to prove the correctness of the ideas and alleviate the deployment in the IDE, integrates rich graphical editors that support the modeling of virtual platform and allocation of components..

(4) Contents 1 Introduction. 1. 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.2. Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 2 Background 2.1. 2.2. 2.3. 2.4. 4. Component Based Development (CBD) . . . . . . . . . . . . . . .. 4. 2.1.1. CBD in Embedded Systems Domain . . . . . . . . . . . . .. 5. 2.1.2. CBD in Real-Time Embedded Systems Domain . . . . . . .. 5. ProCom Component Model. . . . . . . . . . . . . . . . . . . . . .. 5. 2.2.1. ProSys Layer . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 2.2.2. ProSave Layer . . . . . . . . . . . . . . . . . . . . . . . . .. 7. Deployment Concepts in ProCom . . . . . . . . . . . . . . . . . . .. 8. 2.3.1. Virtual Nodes Abstraction . . . . . . . . . . . . . . . . . . .. 9. 2.3.2. Physical Nodes Abstraction . . . . . . . . . . . . . . . . . .. 9. 2.3.3. Deployment Example . . . . . . . . . . . . . . . . . . . . .. 10. Technologies Overview . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 2.4.1. Eclipse RCP . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 2.4.2. EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 12. 2.4.3. GEF and GMF . . . . . . . . . . . . . . . . . . . . . . . . .. 13. 3 Analysis. 15. 3.1. ProCom Development Process Analysis . . . . . . . . . . . . . . .. 15. 3.2. Users and Requirements . . . . . . . . . . . . . . . . . . . . . . . .. 17. 3.2.1. Virtual Platform Modeling . . . . . . . . . . . . . . . . . .. 17. 3.2.2. Allocation Modeling . . . . . . . . . . . . . . . . . . . . . .. 18. 3.2.3. Code Synthesis . . . . . . . . . . . . . . . . . . . . . . . . .. 19. i.

(5) 4 Design 4.1. 20. ProCom Extension . . . . . . . . . . . . . . . . . . . . . . . . . . .. 20. 4.1.1. Virtual Platform Extension . . . . . . . . . . . . . . . . . .. 20. 4.1.2. Deployed Subsystem Instance Extension . . . . . . . . . . .. 21. Synchronization of Model Changes . . . . . . . . . . . . . . . . . .. 23. 4.2.1. Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 4.2.2. Composite Realization . . . . . . . . . . . . . . . . . . . . .. 25. 4.2.3. Subsystem Instance . . . . . . . . . . . . . . . . . . . . . .. 26. 4.3. Allocation Design . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 4.4. Progress IDE Meta-model . . . . . . . . . . . . . . . . . . . . . .. 29. 4.5. Architecture of the Prototype . . . . . . . . . . . . . . . . . . . . .. 30. 4.5.1. Virtual Platform Support . . . . . . . . . . . . . . . . . . .. 31. 4.5.2. Allocation Support . . . . . . . . . . . . . . . . . . . . . . .. 32. 4.2. 5 Prototype Implementation. 37. 5.1. Source Code Structure . . . . . . . . . . . . . . . . . . . . . . . . .. 37. 5.2. Virtual Platform Editor . . . . . . . . . . . . . . . . . . . . . . . .. 39. 5.3. Allocation Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 5.4. Allocation View . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 42. 5.5. Synchronization of Model Changes . . . . . . . . . . . . . . . . . .. 44. 6 Conclusion. 45. Bibliography. 48. ii.

(6) Chapter 1. Introduction Electronic devices of various types have become an indispensable part of our everyday life. Devices as e.g. cellphones, watches, home devices, cars or planes are using special-purpose built-in computers called embedded systems which are involved in providing their functionality. During last years there has been an increasing trend towards the use of embedded systems in an effort to improve products by new functionality, increase in efficiency, precision and dependability. Embedded systems, in contrast to general-purpose computers, are usually dedicated for a special task, designed and manufactured for a particular domain and device type. Interoperability, predictability, dependability of critical devices are characteristics closely connected to the development of embedded systems, increase the complexity of embedded systems and thus also the time and price of their development. The growing demands and complexity in the domains of embedded systems focused attention on the Component Based Software Engineering (CBSE), a branch of software engineering which has been already successfully applied in many other software domains as enterprise systems, service-oriented and desktop domains [9]. In CBSE a system is constructed from independent software units implementing a well-defined part of functionality, called components. Components are usually developed with the strong emphasis on reusability. Reuse of already developed components instead of developing from scratch brings a potential to significantly increase reliability, shorten the development time and decrease the price of the system [5]. Components also provide a formal ground on which analyses of critical systems may be performed. Progress1 , a Swedish national research center for predictable embedded systems supported by the Swedish Foundation for Strategic Research2 , has the main goal to tackle the growing complexity and cost of embedded real-time systems by applying the component based approach. The target domains of Progress research are automotive, telecom and automation industries. 1 2. http://www.mrtc.mdh.se/ http://www.stratresearch.se/. 1.

(7) 1.1 Goals. Chapter 1: Introduction. An interesting problem that has to be faced by component systems developers is how to transform a set of components and their formal models into a system in the operational state. This complex process encapsulating many activities is in general in the software engineering known as a system deployment. The deployment, containing configuration and optimization for the target hardware platform, influences essentially the performance of the running system, which makes it a key phase of the System Development Life Cycle (SDLC). One of the deployment process activities, called allocation, is to determine a target hardware resource where each component will be executed in the runtime. In an effort to reduce the cost of the hardware via reducing the number of execution units, several independent components usually have to share the same physical device, which leads to a resource concurrency and makes the components even more complex and difficult to design. As mentioned above, the component base approach can bring a lot of considerable benefits into the development of embedded systems. However, without a proper tool support the use of components and models can become a burden for system developers. The tool support, which aims to make the development process more efficient, is typically implemented as a part of an Integrated Development Environment (IDE). The IDE is simply a framework combining a programming environment, editors for various models and analysis tools together. To validate feasibility of the Progress approach an IDE for the component based development of embedded systems is currently being designed. The aim of the thesis is to focus on the modeling of deployment and allocation within the scope of Progress. The work includes also the design, development and integration of a prototype tool support, which will be used by the system developer to model target hardware platform, hardware requirements and allocation in the IDE.. 1.1. Goals. System development in Progress allows and supports interleaving of design and deployment activities [11]. ProCom, a new hierarchical component model designed within the scope of Progress, meanwhile mainly aims to the system design process, so that there are only conceptual thoughts concerning modeling of deployment. According to the Progress deployment concept, components are deployed in two phases, each of which contains a model of the target hardware platform on a different level of abstraction. First, components are allocated to virtual nodes, which contain basic requirements for hardware capabilities. The second phase is realized by mapping of virtual nodes to physical nodes, which describe more precisely the target hardware configuration. The ProCom deployment concepts are depicted in the section 2.3. The main goal of the thesis is to focus attention on the virtual layer abstraction. 2.

(8) 1.2 Structure of the Thesis. Chapter 1: Introduction. of the ProCom deployment concept, analyze requirements and give a concrete shape to conceptual thoughts concerning virtual layer nodes, modeling of hardware capabilities and allocation of components. The following step will be extending ProCom meta-model to support the modeling of virtual nodes and allocation of components. After the component model is extended, the thesis should provide a prototype implementation of a modeling tool in the Eclipse application that forms the basis of the Progress IDE. The tool should provide the functionality required by the system developer who designs virtual nodes and allocation models and incorporate it in the form of integrated graphical editors into the IDE. In an effort to clarify the solution, the thesis is simplified to tackle only single platform and single allocation scheme.. 1.2. Structure of the Thesis. The thesis consists of six chapters: A theoretical background to the thesis containing introduction to the component based development, ProCom as a Progress component model and the technology background required for prototyping the tools into the Progress IDE are described in the chapter 2. Chapter 3 analyzes component systems development process from the Progress perspective with an emphasis on the deployment. The process analysis results in a specification of users figuring in the deployment modeling and their concrete requirements concerning the IDE. Solution to the problem is designed in the chapter 4 and the prototype implementation of the tool support is presented in the chapter 5. Chapter 6 concludes the thesis, summarizes its contributions and presents suggestions for the future work.. 3.

(9) Chapter 2. Background This chapter provides a theoretical background assumed to be known while reading the thesis. First section discusses component based development as an approach used in domains envisaged by Progress, i.e. in distributed embedded and realtime embedded systems. After the general introduction to the component based development, the text describes briefly the Progress component model, called ProCom, and conceptual thoughts of deployment in this component model. The technology background needed to describe the prototype implementation of the IDE tool is depicted in the last section of this chapter.. 2.1. Component Based Development (CBD). Component based software engineering (CBSE) is a sub discipline of software engineering that is used in the development of complex software systems. Component based development (CBD) process places emphasis on the logical decomposition of a system into functional pieces called components. Szyperski [15] presents a following definition of the software component: “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party.” Components are usually designed with the strong tendency to achieve high level of reusability, i.e. a component is developed once and reused in construction of several systems. In the ideal case, the system implementation consists only of integration of already developed units, which brings a potential to alleviate the development, increase the reliability and shorten development time [5]. However, an effort put into the development of highly reusable component can increase the complexity of the code and therefore cuts down its practical usability. Furthermore, the gluing of prefabricated components that are not designed to fit and cooperate together can be more time and cost consuming than building the system from scratch. The risks associated with the CBD are closely described in [9].. 4.

(10) 2.2 ProCom Component Model. 2.1.1. Chapter 2: Background. CBD in Embedded Systems Domain. Recent trends towards ever-increasing demands and complexity focused attention on the component based approach also in the embedded systems [2] domain. In an effort to decrease the price of the device, embedded systems usually have to work with very limited resources as power, CPU or memory, which makes their development even more difficult [5]. Currently, embedded systems are developed as monolithic applications that are fully platform dependent; offering very limited or no possibilities of reusing the code or porting to another platform [9]. CBD in the embedded systems domain challenges close dependency of the system on the target platform, which can significantly reduce reusability chances. Platform abstraction leads to more complicated and complex code of the component, reduces thus the profit from the component based approach.. 2.1.2. CBD in Real-Time Embedded Systems Domain. A category of embedded systems domains are real-time embedded systems [9] [8] [6]. Real-time systems, guaranteeing the result being produced in an appropriate amount of time, are used in critical applications as cars or planes. Since the computation result does not depend only on the logical correctness but also on the operation time, system has to meet special timing requirements. To use the component based approach in development of real-time systems, the timing requirements have to be defined for each component, which is then responsible to produce the result in the time given to it. However, components meeting their deadlines do not guarantee the system result being in time. The time consumed by the components communication as well as the time consumed by the glue code of the component, have to be consider in the timing analysis of the system.. 2.2. ProCom Component Model. Building systems from reusable units of code called components is the main characteristic of the CBD. Since the CBD is used in many industry areas each of them having specific requirements and problems that need to be faced by the developers, projects using the CBD usually differ in the precise understanding of the term component. Components and their relations are described by a component model, which is simply a set of rules and constructs defining a component, it’s internal structure, behavior, communication, synchronization, etc. ProCom, described in detail in [4], is a component model that was designed in the scope of the Progress project to be used in the engineering of embedded systems. Progress identifies that requirements as well as expected behavior of the component depend on the granularity of system’s decomposition into components.. 5.

(11) 2.2 ProCom Component Model. Chapter 2: Background. A coarse-grained decomposition defines the component as a complex unit that can be executed in distributed environment, encapsulating certain functionality and communicating with other components to share its state. On the other side, at the fine-grained level, components are smaller non-distributed units, having smaller responsibility but usually much stronger synchronization requirements. To reflect the differences in requirements depending on the decomposition granularity, the ProCom component model consists of two layers, ProSys and ProSave. Components from both layers are stored in a component repository so that they can be easily reused in the development of systems. Within the scope of this thesis, deployment and allocation are modeled at the coarse-grained level of granularity, i.e. components are entities of the ProSys layer 1.. 2.2.1. ProSys Layer. ProSys, the upper layer of ProCom component model, provides a coarse-grained description of the system using large components with a complex functionality, called subsystems. Subsystems, having their own execution threads, usually actively perform some periodic action. Subsystems are meant to be executed in a distributed environment, the communication between subsystems is therefore realized by message passing. Externally, a subsystem is composed of a set of message ports ensuring the communication and interaction with other subsystems, and a set of various attributes describing subsystem’s characteristics, capabilities and requirements. The internal realization of the subsystem can be either composite or primitive. A composite realization contains a composition of subsystems at the more fined level of granularity. Finally, subsystems too small to be realized by a composition are primitive. A primitive subsystem is realized either directly by code in the case of legacy subsystem or by a ProSave component. Following the concept of reusability, ProSys strictly separates the definition of a subsystem from its instance. The definition of a subsystem is a collection of all important artifacts as various formal models, implementation and documentation, that were produced during its development life cycle. The subsystem definition is stored in the repository so that it can be reused in the same or other projects at a later stage [11]. A subsystem defined in the repository can be used in other subsystems to create their own composite realization, which is called subsystem instantiation (the entity is called subsystem instance). Subsystem instance can be understood as a simple reference to the subsystem, so that all instances pointing to the same subsystem have the same artifacts as the subsystem itself. However, to increase a reusability of a subsystem, several subsystem instances can differ in small details as property values, so that different requirements are precisely covered. 1. If the thesis uses a term component in the context of ProCom, we always mean ProSys subsystem.. 6.

(12) 2.2 ProCom Component Model. Chapter 2: Background. From ProSys perspective, a system design consists from a modeling of subsystems and their instantiating in another subsystem’s composite realization, as illustrated in the figure 1. Subsystem B is instantiated twice in the realization of subsystem A, which as the upper-most composite component in the hierarchy represents the whole designed system.. Subsystem A <<composite>> Subsystem instance B1. Subsystem instance B2. Subsystem instance C1. Composing the hierarchy of subsystems. Subsystem B <<composite>>. Subsystem C <<primitive>>. Figure 1: ProSys hierarchical model example. 2.2.2. ProSave Layer. ProSave, the lower layer of ProCom component model, sees components as passive units communicating by pipes and filters. Instead of having their own execution thread, ProSave components are activated (triggered) only when their functionality is needed. The activation of a ProSave component is always initiated from a subsystem at the ProSys level. Externally, a component is seen as a black-box offering group of services, each of them having input and output ports. Input ports of the service are used simply to pass in input data. Each service have a single input trigger port which activates the service of the components. After the computation is finished, component fills output ports of the service with result data. To inform that the result is ready output trigger port of the service is activated. Then, component turns into the passive state again. Component’s internal realization is strictly hidden from the outside of the component. The realization consists either of code or of composition of ProSave components, which makes ProSave (the same as ProSys) a hierarchical component model. During deployment of the system, ProSave components are transformed into executable units, e.g. tasks, which represent the functionality of the component 7.

(13) 2.3 Deployment Concepts in ProCom. Chapter 2: Background. in the run-time. Thus, there is no need for run-time component framework, which could significantly decrease the efficiency of the system [4].. 2.3. Deployment Concepts in ProCom. Virtual nodes abstraction. Physical nodes abstraction. Abstraction level. Quantity and precision of information. A key phase of the CBD process is deployment, which aims to translate the software design into the executable format by using transformations, mappings and allocations to target resources [11]. The deployment process requires having a model of the execution environment, which usually includes the description of the target hardware architecture as well as the software platform. ProCom conceptually separates hardware requirements from the the real hardware platform description, each of which is depicted in a separate model. As illustrated in the figure 2, virtual nodes model describes the target platform at the higher level of abstraction. It identifies hardware capabilities that are required to execute the system elements. Virtual nodes model can be created even if the target platform is not known or as a general requirements model if the system is being developed for more similar devices. However, virtual nodes description usually does not exactly fit the target hardware platform. Precise hardware architecture as well as hardware capabilities and limitations are described by the physical nodes model. Figure 2 illustrates that the lower is the abstraction level, the more detailed and precise are the information contained in the target platform model.. Real hardware platform. Figure 2: Virtual and Physical abstraction of the target platform.. 8.

(14) 2.3 Deployment Concepts in ProCom. 2.3.1. Chapter 2: Background. Virtual Nodes Abstraction. Virtual nodes model describes at the high level of abstraction the target platform, identifies hardware capabilities required by the system. Virtual nodes are indivisible units representing abstract devices where components will be executed. The capabilities of a virtual node are described by a set of predefined properties such as CPU frequency, amount of memory, etc. Target hardware for complex embedded systems is usually composed of more devices that are connected together by buses, which should be modeled by interconnecting of virtual nodes. A connection represents a communication capability between connected nodes. Similarly as virtual nodes, connections can have a set of defined properties (such as connection speed, maximum packet size, communication protocol, etc.). As virtual nodes represent a target hardware architecture (at a higher abstraction level), it is used to determine where parts of the system will be executed in the run-time. The association of a ProSys subsystem with a virtual node is called allocation and comply with following rules. Each subsystem can be allocated to at most one virtual node, yet a composite realization of a subsystem can be split between several virtual nodes. One virtual node can associate many subsystems that will be executed concurrently and share its resources. Allocation of subsystems affects the code synthesis and thus also the final system code being executed. During the code synthesis, the code of all subsystems allocated to one virtual node is transformed to a set of tasks which forms the runtime structure of the virtual node. The structure is indivisible, i.e. all subsystems allocated to the same virtual node will be executed on the same physical device in the end. With this premise, code synthesis can use several optimization methods to create highly efficient code (e.g. by using local communication methods instead of remote ones).. 2.3.2. Physical Nodes Abstraction. At a lower level of abstraction, precisely defined hardware configuration and limitations are described by a physical nodes model. Because both the virtual and the physical layers describe the target platform at different levels of abstraction, they do not necessarily contain the same structure of nodes. To determine a physical node where each subsystem is executed, a mapping between virtual and physical nodes is needed. In this process, each virtual node is assigned to exactly one physical node. More virtual nodes can be placed at the same physical node sharing the resources of the device it represents.. 9.

(15) 2.3 Deployment Concepts in ProCom. 2.3.3. Chapter 2: Background. Deployment Example. To get a complex picture of all deployment concepts together, let assume a following example of a system. Let the system be created by one composite subsystem A, which contains instances of primitive subsystems B,C and D. The system and the model of its deployment is presented in figure 3..

(16)

(17) "

(18)

(19).

(20)

(21). /** .

(22)

(23). . . . %. %. &. !"#$. '($. && "#$. '( 0$. && "#$. ' . . )* ++ ,"#$. '( 0$. )* % ++ ,"#$. )* ' . - * )* . # ).. Figure 3: Deployment concepts in the example Let assume that the virtual abstraction model is composed of 3 virtual nodes with connections and properties as displayed in figure 3. When comparing the virtual platform model and the target platform, we can see that the virtual platform does not describe the hardware entirely accurate; as even the number of virtual nodes and hardware nodes differs. Under the rules of allocation, subsystem instances B,C and D are allocated to different virtual nodes, even though they are parts of the same composite realization. The physical nodes model contains more accurate description of the target hardware. In our case, each physical node represents exactly one node of the target platform with correct properties. Virtual nodes 1 and 2 are both mapped to the physical node 1, as it can satisfy both their requirements. Although subsystem instances B and C are allocated to different virtual nodes, they will be executed on the same physical device after all. This fact is out of the view of the code synthesizer, which sees only the allocation of subsystems to virtual nodes. Therefore, remote communication methods are used for components B and C in the synthesis of code. 10.

(24) 2.4 Technologies Overview. 2.4. Chapter 2: Background. Technologies Overview. In this text, a brief introduction to the technologies that are used in the implementation of the tool support is provided. The Progress IDE is built as an Eclipse RCP application, therefore mainly the Eclipse platform, its plug-in framework and extension points as extensibility mechanism for plug-ins are described. Besides, the text also focus on the Eclipse Graphical Editing Framework (GEF), which forms the base for rich graphical editors implemented in the scope of this thesis, the Eclipse Modeling Framework (EMF) and the Graphical Modeling Framework (GMF), which are two technologies both used to generate the core of editors from the domain meta-model.. 2.4.1. Eclipse RCP. Eclipse [7] is an extensible development platform containing runtime and application frameworks for building, deploying and managing Java applications across the entire software life cycle. Eclipse applications are based on a dynamic plug-in model, the functionality of an application is typically spread throughout many plug-ins. The minimal set of plug-ins needed to rapidly develop a rich client application is collectively known as the Rich Client Platform (RCP). Many plug-ins in Eclipse simply implement a new functionality in the form of a new editor or view, which are two basic ways to provide information to the end user of the Eclipse application. Fundamental differences between editors and views are discussed in [7]. Table 1 provides an overview of these differences, which have to be taken into consideration during the design of our IDE parts.. editing. Editor one resource. resource usage. open-modify-save paradigm. instantiating. more instances. appearance. one area of Eclipse. View one resource, more resources or resource independent immediately affects the state of workspace and underlying resource(s) one instance per workbench page around the outside of the editor area. Table 1: Differences between Eclipse editors and views The Eclipse plug-in framework offers a mechanism to extend a functionality of a plug-in in the scope of another plug-in (or more plug-ins). “One plug-in declares an extension point in its plug-in manifest, exposing a minimal set of interfaces and related classes for others to use; other plug-ins declare extensions to that extension point, implementing the appropriate interfaces and referencing or building on the. 11.

(25) 2.4 Technologies Overview. Chapter 2: Background. classes provided. [7]” Due to extension points mechanism Eclipse products become more flexible, easier extensible and customizable [7].. 2.4.2. EMF. Eclipse Modeling Framework (EMF) is a framework and code generation facility which transforms a structured data model into corresponding Java implementation classes. Further, EMF provides tools and other applications that simplify working with the model, including the persistence of the model, implementation of adapters for viewing and editing of the model as well as a simple editor application. EMF unifies three technologies: Java, XML and UML, each of which can be used to define and represent the data model (as a set of interfaces, as XML schema and as UML class diagram respectively) [3]. A common high-level representation of the model is called EMF model, which is described by Ecore meta-model. The ProCom meta-model uses UML class diagrams as its basic representation, which can be turned using EMF model in Ecore into a fully-fledged implementation of model classes and tools. EMF basically consists of three fundamental frameworks [10]: 1. EMF.Core, a framework which contains Ecore, persistence support and API for manipulating EMF objects, 2. EMF.Edit, a framework that implements generic classes needed to build editors, and 3. EMF.Codegen generation facility capable to generate the implementation of the model and its editor. Let imagine that the EMF code generator has been used to generate the implementation of the model classes and its simple editor. Usually, it is necessary to implement some more features directly into the generated code to extend it. The EMF code generator produces source files that are intended to combine generated and hand-written pieces of code and allows the editing of the generated code with preserving changes during a regeneration [3]. However, EMF code generator produces plenty of code, which is usually not so interesting for the future development or maintenance of the application, since it implements only standard functionality. Although EMF allows the hand-written functionality to be implemented directly in the generated code, it is sometimes desirable to avoid this. The separation of the hand-written code can be achieved through Eclipse extension points (see 2.4.1). The hand-written code can be implemented as an extension of the generated code and therefore fully separated in a different project.. 12.

(26) 2.4 Technologies Overview. 2.4.3. Chapter 2: Background. GEF and GMF. In the case of more complicated domain models, it is highly desirable to display and edit model graphically instead of a simple visualization that can be provided by EMF. Graphical Editing Framework (GEF) is a framework for developing graphical viewers based on the Model-View-Controller (MVC) 2 architecture. According to the MVC pattern, a GEF model contains a domain specific representation of information that are visualized in the editor (and the only editor data that are persisted), a view defines a suitable graphical representation of the model and controllers, in GEF called edit parts, bridge the model and the view by processing events typically triggered by a user that may invoke the change in the model. However, implementation of a graphical editor within Eclipse using GEF can be a time consuming job, which was the main motivation for creating a generative bridge between EMF and GEF. Graphical Modeling Framework (GMF) is a framework that uses EMF to simplify a development of GEF editors. The procedure required by the GMF (described also in the figure 4), from the very beginning when an EMF domain model is created till the generation of an editor plug-in, contains three major steps:. . . .

(27) . . .

(28). . . . . . . . Figure 4: GMF Overview [12] 1. In the first step, following three models have to be created (in arbitrary order): • a Domain model in Ecore, which contains a domain specific information for the editor, 2 MVC is an architectural pattern used in the software engineering to isolate business logic (model) from the user interface (view and controller).. 13.

(29) 2.4 Technologies Overview. Chapter 2: Background. • a Graphical Definition model, containing the view part of the MVC, and • a Tooling Definition model, specifying the tools support provided by the editor. 2. All three models designed in the step 1 are involved in the Mapping model, which contains a simple mapping between domain entities, graphical entities and tools (each domain entity has a graphical entity and a tool assigned). 3. The basic configuration of the code generator (including the name of generated packages, providers, etc.) are defined in the Generator model.. 14.

(30) Chapter 3. Analysis This chapter provides the analysis of the development process as envisaged by ProCom with a strong emphasis placed on the deployment phase of the development. The main goal of the analysis is to find crucial characteristics of ProCom development that essentially influence the design of the deployment modeling. After the key characteristics of the development process are found, the text analyzes more concretely requirements that should be met when extending the component meta-model and designing the IDE tool support. The requirements analysis provides the specification of users taking part in the deployment modeling process, the overview of their requirements and the list of use cases with their base description.. 3.1. ProCom Development Process Analysis. CBSE as one of the branches of the software engineering is characterized by specific requirements concerning the System Development Life Cycle (SDLC). SDLC is a process consisting of several phases as requirements specification, design, implementation or validation. The aim of the standardized development process is to increase the quality of the software product as well as the efficiency of its development. The SDLC of a component based system can be divided into two relatively separate processes: • component development, and • building a system from components, both of them described in detail in [9]. This text analyses only the process of developing a system from components, which is important in the context of the thesis. The main characteristic of the Progress system development is that components are intended to be used in all phases of SDLC [5]. The requirements analysis phase describes system requirements and basic decomposition of the system. 15.

(31) 3.1 ProCom Development Process Analysis. Chapter 3: Analysis. into components. The development process continues with selecting and evaluating suitable components from a components repository, which aims to find the most feasible components combination to satisfy all the requirements. The system is ideally implemented only by writing a glue code that integrates prefabricated components together. However, in the case that no suitable component is found in the repository, a new component has to be developed from scratch. During deployment, the code of components is synthesized into the executable units that are optimized for the target platform and prepared to run. Components figure also in the system maintenance, which usually replaces a component by its new version. As the system combines pre-developed components with those being developed from scratch, a key requirement for the CBD process is a coexistence of components on different levels of development stage during the whole SDLC. This requirement touches also the modeling of deployment, mainly allocation. In this respect, subsystems without realization should be treated as regular subsystems during allocation, i.e. it is allowed to assign them to virtual nodes. Semantically, allocation of the subsystem can be seen as a placing of the whole subsystem with all subcomponents to the same virtual node, which should be taken into the consideration, mainly in the case of subsystems without a realization. Development of predictable systems is characterized by performing many design time analysis, which provide estimates to guide the designer in making decisions [11]. Some analysis techniques (as for example detailed timing analysis) are deployment dependent, i.e. the result of the analysis depends on how the software components will be mapped onto the target system architecture [11]. To provide a required design estimate, analyses have to be performed even if a component figuring in the analysis is not fully implemented or its internal structure is not known. The same analysis can be performed again in the later state of the development, as its result can depend also on the accuracy of information captured in the models, which usually grows in time. Between several iterations of the same analysis, a model of the system is typically changed by the system designer. In this perspective, deployment modeling (mainly allocation) can not be seen as a one-time action in a certain phase of the development. Instead deployment modeling and system design are tightly coupled activities. There are basically two different approaches that can be applied when a virtual platform is designed. In the first approach, the virtual platform model with all its capabilities is designed firstly. Afterwards, components have to be allocated in the way that the capabilities of virtual nodes are not exceeded by it. In this approach, platform definition and components allocation are fully separated sequential processes. The virtual platform can be seen as a standalone entity that can be defined once, stored in the repository and reused in development of several systems. However, sometimes not all capabilities of virtual nodes are known before allocation is performed. The second approach defines virtual nodes as black boxes without exactly specifying their capabilities. The capabilities are created or modified during allocation, so that they could cover requirements of all allocated 16.

(32) 3.2 Users and Requirements. Chapter 3: Analysis. components. Since both approaches can be used by the system developer, the IDE should provide their full technical support. To summarized the previous text, the key characteristics of the development process in ProCom context that must be taken into the consideration are: • using of components on different levels of development stage, • tight connection between system design and allocation modeling, and • virtual platform separation.. 3.2. Users and Requirements. This section defines users taking part in the deployment modeling process in the Progress IDE, analyzes responsibilities of these users and describes their key requirements that should be met in the tool design. The users, each of them defined and analyzed in the separate subsection of the text, are described in the same order they usually participate in the development process.. 3.2.1. Virtual Platform Modeling. The first IDE user taking part in the deployment process is responsible for modeling of the virtual platform. As closely described in Section 2.3, the virtual platform model creates a high level abstraction of the target hardware platform, it is primarily focused on the modeling of requirements concerning hardware capabilities and software environment. The responsibility of the user is to decompose the requirements given by the system and create an abstract model of target platform, i.e. to design a virtual nodes architecture. Furthermore, the user is also responsible for assigning individual requirements to entities of the model. To satisfy the role of the user, IDE should integrate an editor of virtual platform that supports creating, editing, deleting and interconnecting of virtual nodes. Moreover, the editor should allow to model requirements by associating attributes with virtual nodes (e.g. required memory, CPU frequency, storage space). Since connections of virtual nodes represent abstraction of communication devices, the editor should also allow associating attributes with the nodes connections (e.g. maximum transfer time, packet size, protocol support, etc.). The user figures in the following list of use-cases: • Creating virtual nodes When designing the target virtual platform, user of the IDE can define a new virtual node. After the node is created, it is not connected to any other virtual node and no subsystems are allocated to it. • Editing values of virtual node attributes Virtual nodes contain a set of attributes defined in the scope of an attribute framework. Once a virtual 17.

(33) 3.2 Users and Requirements. Chapter 3: Analysis. node is created, it is possible to define values of these attributes that can be set, unset or changed. • Deleting virtual nodes Virtual platform editor can be used to delete a virtual node from the virtual platform model. All connections of the node being deleted are deleted as well. If there are subsystems allocated to the node being deleted, their allocation is canceled. • Connecting virtual nodes Virtual platform editor supports also interconnection of two communicating nodes. • Editing values of connection attributes The same as virtual nodes, connections contain a set of attributes, whose values can be set, unset or changed. • Deleting connections If the communication between nodes is not required, connection of virtual nodes can be deleted from the model.. 3.2.2. Allocation Modeling. In ProCom, allocation is seen as a process of distributing components between virtual nodes defined in the target virtual platform. However, allocation is not a mechanical process at all, as it requires precise informations about the system and platform architectures, including specific system requirements, cooperation between components, using of resources to avoid collisions, etc. The main responsibility of this IDE user is therefore to create the allocation scheme of the system, i.e. a model describing the mapping between ProSys subsystems and virtual nodes, that does not violate the ProCom allocation rules. Moreover, the allocation schema should fulfill additional extra conditions depending on the system architecture, as for example: • the communicating subsystems shall be allocated either to the same virtual node or to distinct interconnected nodes, • the capabilities of the nodes shall not be exceeded by the requirements of allocated subsystems. The validation of these extra conditions is outside of the scope of the thesis and is planned to be incorporated into the IDE as a part of the validation framework. Since allocation is a standalone process independent of the platform modeling, the IDE should contain the support for the process in the form of a specialized editor. For the purpose of allocation, the user of the IDE requires to have a visualization of the system including the hierarchy of all components and their allocation. Since the system contains simultaneously different subsystem types (primitive and. 18.

(34) 3.2 Users and Requirements. Chapter 3: Analysis. composite) and subsystems at different development stages (with and without realization), a part of the work is also to deal with the problem how to distinguish these elements in the system visualization. However, the visualization of the allocation from the perspective of the system is only one part of the required functionality. The list of all subsystems allocated to the same virtual node, i.e. the allocation displayed from the perspective of the virtual node, is also highly desirable. Following text contains the list of use-cases and their brief description: • Viewing allocation schema During system development in the Progress IDE user is allowed to see the current allocation schema of the system. Allocation is visualized in the context of the whole system, i.e. the whole system structure is displayed. • Allocating subsystems to virtual nodes User is allowed to allocate parts of the system to virtual nodes defined in the scope of the virtual platform model. Each subsystem can be allocated to at most one virtual node, whereas virtual node can contain an unlimited set of subsystems. • Viewing subsystems allocated to a virtual node Choosing a virtual node, IDE displays all subsystems allocated to the virtual node. • Viewing primitive subsystems allocated to a virtual node Choosing a virtual node, IDE displays primitive subsystems allocated to the virtual node.. 3.2.3. Code Synthesis. Virtual platform model and allocation scheme are used by Code Synthesizer, a tool being developed in the scope of the Progress IDE project. The main purpose of the tool is to synthesize the code of components allocated to one virtual node into the set of tasks, which represents the node in the runtime environment. From the code synthesis point of view, it is required to know only the allocation of primitive ProSys components, because only their code is being synthesized in the end. During the code synthesis several optimization methods are applied to enforce high efficiency of the code, e.g. an optimization of communication using local communication methods for subsystem placed on the same virtual node.. 19.

(35) Chapter 4. Design 4.1. ProCom Extension. ProCom, closely described in the Section 2.2, is a component model that is designed to be used to develop component systems in embedded and real-time embedded domains. Modeling is a process of describing the system in well defined terms. The terms used to create a model are usually described by the meta-model, which is a precisely defined set of rules and constructs saying how the domain-specific models should be built. The ProCom meta-model is defined in UML as a class model. This section discusses how the ProCom component model should be extended to support the modeling of virtual nodes and allocation. The extension of ProCom is then presented as an extension of its meta-model.. 4.1.1. Virtual Platform Extension. So far, virtual nodes have been only a concept in the deployment of systems. Neither virtual nodes nor their relationships were exactly defined in the metamodel of ProCom. The first goal of the thesis is therefore to provide a support for the concepts existing in the virtual nodes abstraction layer of ProCom. The design of virtual nodes and their relations is discussed here, the result is depicted in the figure 5 as an extension of the ProCom meta-model. For the purpose of the system deployment, a new abstract entity called deployment node is defined in ProCom component model. Deployment node represents in general a node used in the modeling of deployment, either at the virtual or at the physical level. The deployment node entity contains basic information identical for nodes at both abstraction layers (meanwhile a name and a documentation). At the virtual level of ProCom, deployment nodes are implemented by virtual nodes, whose are encapsulated in a virtual platform. Due to the encapsulation of virtual nodes in one entity more separated platforms can be defined in the scope of one system. The virtual platform can also form an artifact that can be stored in the repository and then easily reused in the future development. 20.

(36) 4.1 ProCom Extension. Chapter 4: Design. However, the virtual platform is not only a set of standalone virtual nodes but creates their whole infrastructure following the virtual nodes interconnection concept. Virtual nodes are designed to be connected to a virtual network, which represents a communication channel shared by N virtual nodes. Virtual networks, in comparison to a direct connection of two virtual nodes, can be used to model n-to-n communication, brings therefore more flexibility into the virtual platform modeling. Virtual network, as a standalone entity of the model, can be further extended to contain a predefined set of attributes (as required in the section 3.2.1). Virtual nodes are connected to a virtual network indirectly through an attachment, so that also attributes concerning the relationship (as direction of communication) can be add into the virtual platform model.. DeploymentNode. VirtualPlatform. name : String documentation : String. 1. 1. *. 1. *. *. VirtualNode. Attachment 1. VirtualNetwork name : String. *. *. 1. Figure 5: Virtual platform meta-model extension.. 4.1.2. Deployed Subsystem Instance Extension. ProSys is a hierarchical component model which describes a system as a nesting of subsystems (see 2.2). Although current hierarchical model is suitable for the design of the system, we will show that it is not fully sufficient for the modeling of deployment, which requires to extend the system representation. We will attempt to demonstrate this by the example illustrated in the figure 6, which describes the same system from two different perspectives. Let assume that the system is created by one subsystem A, which is composite and contains two instances of the subsystem B. The realization of B is also composite and contains an instance of the primitive subsystem C. Left part of the figure presents the system as it is created by the system designer, i.e. as a hierarchy of subsystems and their instances following exactly entities and their relations defined in ProSys. On the other hand, right part of the figure displays a model of the structure of the effective system instances which need to be known for the deployment modeling. Let us focus more attention to the subsystem C. Since C is referenced through two separate instances of the subsystem B, it should obviously have two standalone 21.

(37) 4.1 ProCom Extension. Chapter 4: Design. A <<composite>>. Instance B1. Instance B2. Deployed instance A. B <<composite>>. Deployed instance A.B1. Deployed instance A.B2. Instance C1. Deployed instance A.B1.C1. Deployed instance A.B2.C1. C <<primitive>> Components model. Deployed system model. Figure 6: Hierarchical subsystem model vs. deployed system structure. instances in the run-time model of the system. We can name these instances A.B1.C1 and A.B2.C11 . Both component instances are fully independent and can be allocated and executed separately. In the component hierarchy, C is represented only by one entity, since both B instances refer the same B definition. In general, this situation turns up when a composite subsystem is instantiated more than once. All the instances point to the same subsystem type, which is composite, i.e. contains an internal child instance of another subsystem in its realization. As explained in the previous example, the child instance cannot be represented by one entity for the purpose of allocation; each reference to the child instance must create a standalone entity. To support a run-time model of the system required by allocation and deployment in general, an entity called deployed subsystem instance, which represents a subsystem instance in the deployed system model, has been defined in ProCom. But as explained before, more deployed subsystem instances can refer to the same subsystem instance. The relation between both entities at the meta-model level is displayed in the figure 7. Each deployed subsystem instance contains the list of its child instances from the system hierarchy. Furthermore, child instances have also a reference to their parent, which is used to determine the virtual node where the subsystem is allocated, we will describe this closely in the section 4.3. The root of the tree, which represents the system itself, is formed by a deployed subsystem instance without a parent. As illustrated in the figure 8, allocation is due to this extension seen as a 1. Entities called A.B1.C1 and A.B2.C2 are referenced through the subsystem instances B1 and B2 respectively.. 22.

(38) 4.2 Synchronization of Model Changes. Chapter 4: Design. SubsystemInstance name : String 1 deployment * DeployedSubsystemInstance. 1. *. parent-children. Figure 7: Deployed subsystem instance extension. relationship between a virtual node and a deployed subsystem instance. Following the concept of allocation, each deployed subsystem instance can be allocated to one virtual node. The navigation in the relationship determines the allocation data to be stored only in deployed subsystem instances, virtual platform is therefore not connected with the system itself and can be reused in the development of several different systems.. DeployedSubsystemInstance. VirtualNode. allocation *. 1. Figure 8: Allocation meta-model extension.. 4.2. Synchronization of Model Changes. As described in the previous section, ProCom component model has been extended to support the model of the deployed system. As the deployed system model reflects exactly the hierarchy of components, it is meant to be generated automatically from the system design, instead of being unnecessarily developed directly by the user of the IDE. A system is designed as a hierarchy of subsystems (i.e. according to a system design in ProSys), which can be automatically transformed into the deployed system model. Both models are interconnected and can coexist in the same phases of the development. The analysis of ProCom development, presented in the section 3.1, identified that one of the key requirements is to allow coexistence of components on several 23.

(39) 4.2 Synchronization of Model Changes. Chapter 4: Design. development stages during the whole SDLC. According to this premise allocation can be provided even if some subsystems do not have a final realization. This situation occurs for example when a deployment dependent design time analysis needs to be performed. When the realization of the subsystem is defined, the same allocation schema can be used again, at this time to deploy the system. The change in the realization of the component can however cause that the deployed system structure does not match the new system design. Therefore, after each change performed in the system design, the deployed system model has to be updated to reflect the new structure of the system. But it is not feasible to recreate the whole deployed system model every time a subsystem or its realization is changed, because allocation schema would be irrecoverably lost. Instead of that, the changes in the system design are carefully synchronized into the deployed system model. The synchronization is designed so that it influences only that part of the deployed system model which is really affected by the change. The rest of the deployed system structure, including allocation data, persists the synchronization without a change. To track the changes in the design, deployed subsystem instances are designed to contain a reference to the subsystem instance (as described in section 4.1.2). The analysis of relationships in ProCom meta-model shows that there are following changes that can be done in the hierarchy of components when the system is being designed: 1. a realization of a subsystem is defined, 2. a subsystem instance is added to or deleted from a composite realization, 3. subsystem instance changes the subsystem it instantiates.2 . In the following sections, we will discuss carefully each one of these changes and analyze what consequences does it have for the deployed system model. We will also describe how the synchronization is designed to be realized.. 4.2.1. Subsystem. According to the ProCom component model, a ProSys subsystem and its realization (which can be either composite or primitive) are separated entities (see 2.2). Due to the separation, a subsystem can exist without a realization, mainly in the early phases of design when the realization is not implemented. A subsystem without a realization is a placeholder that can represent both, composite and primitive subsystems. After a subsystem is determined to be composite (or primitive), a realization is created and used to implement its internal structure. 2. A subsystem instance and a subsystem are entities connected by association in the metamodel.. 24.

(40) 4.2 Synchronization of Model Changes. Chapter 4: Design. As the creation of an empty realization does not influence the model of the deployed system, it does not have to be handled by the synchronization engine. However, after a composite realization, system designer usually adds new subsystem instances into the realization. The next section discusses how to handle the change in the composite realization.. 4.2.2. Composite Realization. A composite realization of the subsystem contains a set of subsystem instances, which can be connected by message channels for the purpose of their communication. An example of a composite realization is depicted in the figure 10 (c). When a composite realization is designed by the system designer, a new subsystem instances are typically added into the realization. Alternatively, a subsystem instance can be deleted from the realization. These changes evidently influence the deployed system model as they add/delete a component into/from the system. Therefore, the change in the composite realization triggers always a synchronization action. Since each deployed subsystem instance contains a reference to a subsystem instance, we can easily identify all deployed subsystem instances which refer to a changed subsystem (trough subsystem instance). In them, a child has to be add or deleted depending on the operation performed in the design. In the case a primitive subsystem instance is added into the realization, just a simple child deployed instance is created. On the other side, if the subsystem is composite, we have to recursively construct the whole subtree of deployed subsystem instances representing the composite structure of the subsystem. A <<composite>>. Instance B1. Instance B2. Deployed instance A. B <<composite>>. Deployed instance A.B1. Deployed instance A.B2. Instance C1. Deployed instance A.B1.C1. Deployed instance A.B2.C1. C <<primitive>> Components model. Deployed system model. Figure 9: Synchronization in the composite realization example.. 25.

(41) 4.2 Synchronization of Model Changes. Chapter 4: Design. An example of the synchronization is depicted in the figure 9. The synchronization is triggered by the change in the composite realization of subsystem A, where a second instance of the B subsystem called B2 is added. Subsystem A represents the topmost component of the system, it has therefore only one deployed subsystem instance, the root, in the model of the deployed system. As subsystem B has a composite realization, we have to create a deployed model of the whole component recursively, i.e. including a deployed subsystem instance A.B2.C1. Similar situation occurs when a subsystem instance is deleted from the composite realization. Let A be a deployed subsystem instances that refers the subsystem with changed realization. Then A contains a child, which references deleted subsystem instance. Since the subsystem instance does not exist any more, neither a deployed component should exist in the model. The allocation data of the deployed subsystem instance that is deleted are irrecoverably lost.. 4.2.3. Subsystem Instance. In ProCom component model, subsystems are not used directly in the realization of another subsystem but through the entity called subsystem instance, which can be seen as a simple reference to the subsystem (see 2.2). As subsystem and subsystem instance are two standalone entities of the meta-model connected with the asociation, we should analyze the situation when a subsystem instance changes the subsystem it references.. . . (a) Subsystem A. (b) Subsystem B.

(42) .

(43) . (c) Composite realization of subsystem C. Figure 10: An example of composite realization including subsystem instances. Subsystem instances in the same composite realization are connected through their message ports to explicit message channels which provide their communication (as depicted in the figure 10(c)). Message ports of a subsystem instance must 26.

(44) 4.3 Allocation Design. Chapter 4: Design. correspond one-to-one to the ports defined by the subsystem, as messages from the subsystem instance ports are pasted to subsystem ports and vice versa [4]. Because subsystem instance defines exactly the same ports group as the subsystem itself (as can be seen also in the figure 10 for subsystems A and B and their instances in the realization of C), it is not possible to take a subsystem instance and simply change its subsystem to another one, in which case a port set of the subsystem instance and a port set of the subsystem would not fit together. The change of the subsystem should be therefore prohibited in the IDE tools that provide the support of the system design. Instead of changing the subsystem directly, the old subsystem instance should be replaced by a new one referring to the proper subsystem. Synchronization of this change into the deployed system model is described in the section 4.2.2.. 4.3. Allocation Design. An important part of the deployment process in CBD is allocation, which is an activity when components executables are distributed between devices that form the target platform architecture. In ProCom deployment modeling, target platform devices are represented by virtual nodes, run-time components are represented by deployed subsystem instances. Modeling of allocation therefore means associating deployed subsystem instances with virtual nodes. Firstly, the allocation design that aims to fulfill corresponding requirements presented in the section 3.2 is described. The design places main emphasis on storing of allocation data and determining allocation from the deployed system model. After our design is presented, alternative solutions are briefly discussed and evaluated. In our design, two different types of allocation are distinguished: • explicit allocation and • implicit allocation. The situation when a deployed subsystem instance is assigned to a virtual node by the system developer explicitly is called the explicit allocation. In the case of composite deployed subsystem instance3 , all child instances are determined to be allocated to the same virtual node as their parent, unless they do not specify their allocation also explicitly. Hence, not each deployed subsystem instance has to be allocated explicitly to have a virtual node assigned. Determining a virtual node from parent deployed subsystem instance in the hierarchy is called the implicit allocation. The allocation is therefore a property which is implicitly inherited from the parent component in the hierarchy but can overload the value. 3. Deployed subsystem instance that refers to the subsystem instance with primitive (composite) realization will be called primitive (composite) deployed subsystem instance.. 27.

(45) 4.3 Allocation Design. Chapter 4: Design. The following set of rules based on recursion is defined to determine a target virtual node for a deployed subsystem instance A: 1. If A specifies explicit allocation to the virtual node V, the target virtual node is V. 2. If A does not specify explicit allocation and A have a parent in the deployed system hierarchy. Let P be a parent of A. The target virtual node of A is equal to the target virtual node of P. 3. If A does not specify explicit allocation and A is the root in the deployed system, the target virtual node of A is null. In our design, allocation data are stored only in deployed subsystem instances that are explicitly allocated. To determine an implicit allocation, algorithm has to go up in the tree hierarchy to find the first explicitly allocated ancestor. Searching stops at latest in the root of the tree, which is either allocated explicitly or not. If none of the deployed subsystem instances on the path to the root is explicitly allocated, the deployed subsystem instance is considered as not allocated. The key requirement identified during the analysis of SDLC is that components at different levels of development stage have to coexist during the development. In this respect, deployed subsystem instance referring to a subsystem with empty realization should be treated standardly during allocation. In our design, such entity can be allocated explicitly without precisely knowing its structure. When a realization is created, child deployed subsystem instances inherit the allocation from their parent. The result is the same as if the realization was known before allocation. Inheritance makes the allocation modeling much more flexible and comfortable also for the user of the IDE, who can allocate bigger pieces of system without the need for specifying it for each component separately. Our solutions meets also requirements given by the code synthesizer specified in the section 3.2.3. The code synthesizer needs to know the allocation of primitive deployed subsystem instances so that is can determine all the code that should be synthesize together. The primitive deployed subsystem instances contains allocation either directly (in the case of explicit allocation) or indirectly (obtained using inheritance). Figure 11 displays an example of a system allocated to 3 virtual nodes. Deployed subsystem instances A, C, and D have been allocated directly by the developer. The information about the allocation is stored only in them. Deployed subsystem instance B inherits the allocation from its parent; it is therefore dedicated also to the Virtual node 1. To determine the allocation of F, a target node for its parent C has to be obtained. Deployed subsystem instance C overloads with the Virtual node 2 the allocation of its parent A; therefore F is decided to be allocated also to Virtual node 2. D has no realization yet, but when a realization is created, child instances will inherit the allocation so that they will be dedicated 28.

(46) 4.4 Progress IDE Meta-model. Chapter 4: Design. . . . .

(47) . .

(48) . .

(49) .

(50) . Figure 11: Allocation example. to the Virtual node 3. Two alternative solutions to our design are briefly described and evaluated here: • Since only an allocation of primitive deployed subsystem instances is really used in the end for the code synthesis, one of the solutions would be to propagate and store allocation only in primitive instances. Although this solution is fully sufficient for the code synthesis, it does not support allocation of components with empty realization. • Another solution would be to store the allocation in the whole subtree of a deployed subsystem instance that was explicitly marked as allocated. In this case, each deployed subsystem instance stores the target virtual nodes. The redundant data make the determination of the target virtual node more efficient but also more complicated to update.. 4.4. Progress IDE Meta-model. Let us imagine that we would like to integrate a new editor of virtual nodes into the IDE. To easy distinguish two different virtual node instances in the editor, we would like to associate additional attribute with a virtual node entity, a color. The color can be set by the user of the IDE and is persisted as any other attribute. However, the color logically does not concern the virtual node itself, but is a part of its presentation in the user interface. In general, the data visualized in the editor composes of two logical layers: 1. core model entities, and 2. their presentation layer.. 29.

(51) 4.5 Architecture of the Prototype. Chapter 4: Design. The editors developed in the scope of our prototype solution are meta-model based, i.e. a meta-model is used to define the entities, relationships and attributes that can be modeled within the editor. The first proposal can be to base editors directly on the ProCom meta-model. However, ProCom meta-model alone is not sufficient for the purpose of the editor, as it contains only the core entities and cardinal relations of the component model, i.e. the core model entities layer as described before. The presentation layer of ProCom entities is designed to be defined in a separate meta-model, called Progress IDE meta-model, which forms a basis of IDE editors developed in the scope of the prototype implementation. Progress IDE meta-model references ProCom meta-model and extends it for new attributes and new entities. For each ProCom entity, Progress IDE metamodel defines a new special entity, which is used for its presentation. The entity can be distinguished by the suffix Presentation in its name. Figure 12 presents the extension of the VirtualNode entity (defined in ProCom) to support the storing of the color property. The property is defined outside the scope of the ProCom meta-model in the VirtualNodePresentation entity, which is a part of the Progress IDE meta-model. 9LUWXDO1RGH. 9LUWXDO1RGH3UHVHQWDWLRQ

(52) . Figure 12: Progress IDE Meta-model example. To ease the prototype design and implementation of IDE editors, presentation classes are inherited from ProCom meta-model entities. Due to inheritance, presentation classes contain the same relations as their ancestors, i.e. entities in ProCom component model. Presentation entities can be therefore easily used to create valid models. Alternatively, an association can be used to connect entities from both meta-models, which would bring a full separation of core classes from their presentation. However, this solution would bring more technical difficulties in using of GMF which would result in more hand-written code in the generated code of the editor and more complicated prototype solution with harder maintenance.. 4.5. Architecture of the Prototype. This section describes the architecture of the tools support integrated into the Progress IDE. The desired functionality is split into several parts, each of which. 30.

(53) 4.5 Architecture of the Prototype. Chapter 4: Design. is then incorporated into the IDE in the form of an Eclipse editor or view. As described in the section 2.4.1, there are conceptual differences in the use of editors and views in Eclipse, which have been carefully considered during the design of each IDE part. According to the requirements analysis presented in the chapter 3, the modeling of virtual platform and allocation are two separated processes, which can be realized in different phases of the SDLC and by different users of the IDE. A virtual platform is an artifact that can be designed independently on the rest of the system and can be reused in different applications. It is therefore reasonable to separate the functionality into two parts of the IDE, one of them providing modeling of virtual platform, second one modeling of allocation. The separation of functionality makes both editors less complex, easier to control and use.. 4.5.1. Virtual Platform Support. Virtual Platform Editor The support of the virtual platform modeling can be implemented by several types of editors. A tree editor, as an example of a simple editor, is ordinarily used to edit resources in Eclipse based applications. However, simple editors have limited possibilities to visualize significant aspects of complex models. In the case of component systems that are designed to be executed in a distributed environment, virtual platform can define tens of virtual nodes with several virtual networks. It is therefore useful to create a rich graphical editor, which has a bigger potential to clearly visualize an overview of the complex model as well as its important details. GMF, described more precisely in the section 2.4.3, allows developers to take an existing application model and relatively quickly create a core of the rich graphical editor, which contains a basic modeling functionality. Since all entities of the virtual platform are well defined in the Progress IDE meta-model, it can be used as a source for our editor. The using of a generated editor core instead of developing from scratch brings many benefits, especially a standard and unified control and behavior of the editor. Before the code of the GEF editor can be generated, each entity of the metamodel, which is used in the target editor, has to define its basic graphical representation. The entity can be represented in the editor either by a node or by a connection of two nodes. The basic representation can be then enriched by defining shapes and images. As virtual nodes and virtual networks form standalone entities, they are designed to be represented by nodes with different shape to easy distinguish them. For the representation of attachment, which always connects one virtual node with one virtual network, both the node and the connection can be used in the editor. The alternatives are presented in the figure 13. To partially hide the information complexity of the model by decreasing the number of nodes in the editor, it is more practical to use the connection representations.. 31.

(54) 4.5 Architecture of the Prototype.

(55). Chapter 4: Design.

(56) .

(57) . (a) Node.

(58).

(59) .

No results found