CHARLES UNIVERSITY, PRAGUE FACULTY OF MATHEMATICS AND PHYSICS. Master Thesis. Michael Cífka Visual Development of Software Components

Transcription

1 CHARLES UNIVERSITY, PRAGUE FACULTY OF MATHEMATICS AND PHYSICS Master Thesis Michael Cífka Visual Development of Software Components Supervisor: Ing. Petr Tůma, Dr.

2 I would like to thank my supervisor, Ing. Petr Tůma, Dr., who provided me with very valuable advice and feedback, and without whom this work could not be have been finished. I declare that I wrote this work myself, using only the literature listed in the references. This work can be freely reproduced for educational purposes. Prague, August 2002 Michael Cífka Visual Development of Software Components Page 2

3 Abstract: The goal of this thesis is to design concepts of a visual development environment for a component model with support for the hierarchical composition, reusability, configuration, and distributed deployment. As a proof of the concepts, a prototype of the visual development environment for the SOFA project was implemented as a plug-in module for the NetBeans IDE. Visual Development of Software Components Page 3

4 Contents 1 Introduction Background, Motivations Software Components Hierarchical Composition Visual Development The Goal of This Thesis Background Software Components Component Development Process Design Stage Development Stage Assembly Stage Deployment Stage Existing Component Models CORBA Component Model Enterprise Java Beans COM / DCOM / COM NET Framework Project SOFA Existing Products Visual Basic Visual Studio.NET C++ Builder / Delphi NetBeans IDE Editor Module and Java Module Form Editor Module...24 Visual Development of Software Components Page 4

5 3.4.3 CORBA Module EJB Deploytool Solution Requirements Proposed Concepts Component Designer Assembly Tree View Property Sheets Component Description File Primitive Components Packaging Other Issues Prototype Implementation Underlying Framework Installation Guide User s Guide Component Template Component Node and the Assembly Tree Component Designer Property Sheets Type Manager Generating the.cdl and.dd files Programmer s Guide Types Layer Objects Layer Component Designer Loaders, Nodes, and Property Sheets Type Manager Future Path Conclusion...51 Visual Development of Software Components Page 5

6 1 Introduction The first chapter of this section will provide an introduction to the background of this thesis and a summary of motivations that led to starting this work. In the second chapter, the goal of this thesis will be proposed. 1.1 Background, Motivations Software Components In the last ten years, software components gained a significant role in the software development process. Although several different specifications (usually referred to as component models) of what a software component actually is were introduced, the basic idea behind the scene is more or less the same. The main idea of the component-oriented approach is splitting the code of an application into several, well-formed pieces (usually called components), with welldefined functionality (usually called specification) and with unified access points (usually called interfaces). The application development process naturally benefits from this approach in several different ways, which will be described in the next section in detail. The most important examples include reusability, interchangeability, and the possibility of distributed deployment of the software components Hierarchical Composition One of the main concepts that are intensively used by this work is the hierarchical composition of software components. Visual Development of Software Components Page 6

7 The basic idea behind the hierarchical composition is to apply the same process that leads to splitting an application into several components to the components itself, thus creating subcomponents of a component, and by repeating this step recursively. Although a significant amount of the traditional software components call multiple count of other software components in order to perform their functionality, it is usually done in a different way, on the source code level. In such cases, it seems to be more natural to see the multiple components used as subcomponents composed into a single composed component. Also, the component and its subcomponents should be interconnected by the component framework based on the interfaces and on the component description, rather than by performing functional calls from a custom source code inside the components. Using the concept of hierarchical composition, an application can be seen as a composed component. Each of the subcomponents of a composed component is either a composed component again, or a primitive component, i.e. component containing a source code. In contrast, the composed components do not contain any custom source code, the component framework generates them based on the component description. When the rule is applied recursively, the application becomes an assembly tree of software components. The source code is contained in the primitive components, leaves of this tree. The inner nodes of the assembly tree represent the composed components, defining the way in which the functionality of the primitive components will be combined Visual Development The term visual development is mostly used for a development process where some steps are performed in a different way than writing a textual code; graphical diagrams, property sheets, and dialogs are the most common examples of a visual environment offered for the development purposes. The main reason for using visual development tools is to simplify and speed-up the development process. The advantage of a visual development tool, over writing a Visual Development of Software Components Page 7

8 source code, is even more significant when dealing with a complicated code, when using a large count of reference to the other parts of the code, or when describing an entity that could be rather imagined or represented visually. As an example important for this thesis, the textual description of a composed component (e.g. using the Component Description Language) is usually quite complex and does not provide human-perceivable representation of the internal structure. However, the internal structure of a composed component can be represented as a lucid, easily understandable graphical diagram. 1.2 The Goal of This Thesis The goal of this thesis is to design the concepts of a visual development environment, satisfying the needs of a modern component model. The concepts should be designed on the abstract level, without focusing on a concrete component model. In order to achieve such a goal, various existing component models should be researched to analyze the individual needs, and find the common aspects. Also, a number of existing visual development environments should be studied to extract the best practices and concepts already used. As a proof of the proposed concepts, a prototype tool for a concrete component model should be implemented. For this purpose, the SOFA component model should be used. The prototype tool should be implemented as a plug-in module for the NetBeans IDE, with the focus on the features that are currently specified by the SOFA component model. Also, the tool should be open to the possible future extensions, as the SOFA project will evolve. Visual Development of Software Components Page 8

9 2 Background The first chapter of this section will discover the common aspects of modern component models. The second chapter will explain the traditional development process of software components. In the third chapter, the most important existing component models will be described in detail, with focus on the development process. The last chapter will introduce and discus the SOFA project, focusing on its component model with the hierarchical composition used for the purpose of prototype implementation. 2.1 Software Components For the purpose of this thesis, we will understand a software component (or shorter, a component) to be an autonomous piece of software code with well-defined functionality, the specification, and well-defined access points, the interfaces. There can be two kinds of interfaces, provisions or requirements. Provisions represent access points designed for incoming functional calls, thus offering the possibility to provide the services implemented inside the component to the outside. In contrast, requirements represent access points designed for outgoing functional calls, thus offering the possibility to provide the component with services implemented in the outside of the component, either by the execution environment or by another component. Unfortunately, most of the component models available today do not offer this level of abstraction. The term interface is mostly used for the provisions only, while the support for defining requirements at the component description level is very limited or none at all. The satisfaction of the indispensable need for requirements is postponed to the custom source code level of the components where the services predefined by the component model (e.g. the event service, lookup service, etc.) are offered. Visual Development of Software Components Page 9

10 The main benefit of the component-oriented approach is called reusability. Thanks to the well-defined access points and functionality, a component that was originally built to be used in one application can be easily reused in another application. Since in most of the component models this is possible without providing the source code, the component can even be offered for sale and reused by another software development company later. Such activity is usually referred to as component trading. Depending on the sophistication level of a concrete component model, a number of additional features and benefits can take place. Here are some important examples: Distributed deployment: The component framework is able to run components on multiple count of remote machines, interconnecting them (transmitting the functional calls) over the network. Run-time updating: In the mission-critical applications, it is important to have an option to replace a selected component on runtime, without stopping the entire application. If the state of the replaced component is vital, this information has to be saved and restored as soon as the updated component is activated. Protocols: In the component description, some models allow to list the legal sequences in which the successive calls to the component should be performed. The component model is able to verify the sequences in run-time and warn the developer of any contradictions. Division of work: Since each component is an independent entity, the application may be created by multiple developers in parallel. Thanks to the well-defined functionality and access point, the developers are free of the inconvenient need to know the implementation details about the other parts of the application. Visual Development of Software Components Page 10

11 2.2 Component Development Process In the traditional component-oriented development process, as it is usually described, we can identify multiple distinct stages on the path from an idea to a running application. Depending on a concrete component model, some of these stages can be more or less extensive or missing Design Stage At first, in the design stage, the application is split into multiple components with well-described functionality in order to decrease the complexity. For each component, there are defined services that it will offer services that it will require from the surrounding environment. This approach is repeated recursively, until the designed components are either simple and therefore can be easily implemented using a programming language (primitive components), or are already existing elsewhere and therefore can be reused. The design usually made in a Unified Modeling Language (UML) tool. Based on the created model, the component description is written. For this purpose, a variety of different description languages are used. The most of them are mutations or extensions of the Interface Description Language (IDL). Using the description languages, interfaces are defined as sets of callable methods with parameters. Some of the description languages can also be used to define properties, constants, structures, and exceptions. The Component Description Language (CDL) can furthermore define frames and architectures. A frame is a group of multiple interfaces, where each of them is used either as a provision or as a requirement. An architecture is a gray-box description of a component, declaring either the fact that the component is primitive or defining how the component is composed of subcomponents at the first level, considering the subcomponents only as frames. Visual Development of Software Components Page 11

12 2.2.2 Development Stage The second stage is the development stage. In this stage, source codes for the primitive components are developed. Most of the component models can generate some source code from the component description to start-up with, either in the form of base classes that may be subclassed, or the a form of classes with empty method bodies. The compiled source code, along with a description file, constitutes a primitive component Assembly Stage In the assembly stage, the primitive and the reused components are assembled into an assembly tree. The root of the tree represents the entire component (application), while the children of each node represent subcomponents of a composed component represented by the parent node. The leaves of the tree represent either primitive components or existing components that are reused. The information that can be represented by the inner leaves is how to interconnect the interfaces of the component with the interfaces of the subcomponents. Depending on the component model, this information is created during the development stage using an architecture element, or it is created during the assembly stage. Also, the property values can be set during this stage to provide the component with default configuration data. The information created during the assembly stage has a form of an XML file, called the assembly descriptor Deployment Stage The last stage on the way to a running application is the deployment stage. In this stage, the configuration values in the assembly descriptor are customized according to the individual needs and the deployments units are configured. A deployment unit is a set of components with the same value of the location parameter, defining a reference to Visual Development of Software Components Page 12

13 a server where the component will be run. The information entered during the assembly stage is again written in a form of an XML file, called the deployment descriptor. 2.3 Existing Component Models CORBA Component Model The OMG s Common Object Request Broker Architecture (CORBA) is a widely accepted standard for middleware application servers, with focus on distributed computing. CORBA Object Model, a part of the specification, enables software applications to invoke operations on distributed objects without concern for object location, programming language, operating system, communication protocols, interconnections, or hardware platform. In order to provide the application developers with a higher level of reusability and with easy access to the frequently used features, OMG also specifies a wide set of CORBA Object Services (COS), such as naming, trading, event notification, transactions, security, and persistence. The CORBA Component Model is an extension of the CORBA Object Model, with a number of additional features and services that enable application developers to implement, manage, configure, and deploy components. An extension of Interface Definition Language (IDL) is used to describe components. Provisions and requirements are described as interfaces for synchronous invocation, called the facets and receptacles, or as interfaces for asynchronous invocation, called the event sources and event sinks. For the purpose of component configuration, a number of attributes may be specified. Next, the component description is compiled and the source code of the components is implemented. The compiled source code along with the generated component descriptor file and the default properties file are packaged into a component package, a single zip archive file. Visual Development of Software Components Page 13

14 There are two possible ways of defining how the components should be instantiated and interconnected. One way is to create the assembly descriptor, an XML file where the information is provided. The second way is to do that in run-time, either from a custom source code, by performing calls to the Object Request Broker (ORB), or using the designated CORBA scripting tool, the IDLscript. To support such approach, a wide variety of introspective services is offered. The components are deployed into server containers, an execution environment that is built above the Object Request Broker and hides the complexity of most system services Enterprise Java Beans The Sun Microsystems Enterprise Java Beans (EJB) specification is another example of widely accepted standard for distributed computing. Unlike other component systems, EJB is strongly related to the relational databases. In EJB, two basic types of components are introduced. The first of them, called the entity beans, provide a component representation of a database record. It can be created from the real database record via the primary key, and all the operations performed on the component are transparently reflected back into the database record. On the other hand, session beans are components that do not contain any persistent data. This type of components is used for implementing services or performing calculations. The source code of the EJB components is limited to the Java programming language. Components are deployed based on a XML file, called the Deployment Descriptor, and executed in the environment of EJB server products. The components can only directly expose the provisions, while any requirements have to be obtained programmatically from the source code. The communication between the components is provided transparently, using the Java Remote Method Invocation (RMI). The EJB middleware servers also provide the components with a variety of services, including lookup, naming, and transaction processing. Most of them also offer a number of development tools, including Visual Development of Software Components Page 14

15 automated generation of entity beans, based on the structure of a database tables, as well as various configuration and deployment tools COM / DCOM / COM+ During the 90 s, we could notice a significant effort in Microsoft to enable wider cooperation and interaction between its desktop applications. Dynamic Data Exchange (DDA) and Object Linking and Embedding (OLE) were the first technologies to enable simultaneously running desktop applications to exchange data and perform in-place activation, editing the data placed in a document of one application using another application. In 1995, a successful component technology called the Component Object Model (COM) was introduced. The main goals of this technology were language independence and reusability. In 1996, the technology was extended with a possibility of Remote Procedure Calls (RPC). This distributed version is also known as the Distributed Component Object Model (DCOM). In COM / DCOM, components are Dynamically Linkable Libraries (DLL). They can be written in any language that is able to compile into a binary file with the internal structure (virtual tables, function calling conventions, return values) described by the COM specification. The source code can be either written from scratch, or pregenerated from the Microsoft IDL, a mutation of the standard IDL language. The components can specify only the provisions; requirements have to be obtained through system services from the component source code. To identify the components, they have to specify a 128-bit Globally Unique Identifier (GUID) and optionally a humanreadable identifier. There are two recommended methods of the hierarchical composition, called containment and aggregation, but these are just design patterns how to create a composed component on the source code level, rather than on the component description level. In the deployment stage, components have to be properly registered in a system database, the Windows Registry. This is easy for a local application, while for a Visual Development of Software Components Page 15

16 distributed application the process is very cumbersome. The component that should be used remotely has to be manually copied and registered on both the source and the target machine. Furthermore, the source machine has to be manually configured to run a remote version of the component, specifying the machine name, as well as a username and a password to access the remote machine. The limitations are obvious; the same type of component cannot be accessed on multiple machines simultaneously, and the references cannot be passed easily. The distribution is also limited to the local network. With the Microsoft Windows 2000 operating system which includes a middleware product formerly known as Microsoft Transaction Server (MTS), an extension of COM / DCOM called COM+, was introduced. This extension addresses various issues in the field of stability, scalability, security, and transaction processing. As a new feature, the components can have a set of configurable attributes. The configuration can be performed either manually, by the provided configuration tool, or programmatically. Although the distributed deployment can be already performed from one location, the other limitations mentioned in the previous paragraph still apply NET Framework The newest significant product in the area of distributed computing is the Microsoft s.net Framework. Although its concepts are far different from the traditional concepts of the component-oriented development, it can provide quite a flexible way to develop distributed applications. Basic building units in the.net Framework are classes, sometimes also called components. The source code of the classes can be implemented from scratch in variety of programming languages, including C++, C# and Basic. Once finished, it is compiled into the Microsoft Intermediate Language (MSIL). The structure of the resulting files is very similar to the structure Java class files. As a next product of the compilation process, a manifest file with description of published data types, dependencies, and digital signatures is created. All the resulting files are packaged into a single file called an assembly. Visual Development of Software Components Page 16

17 The assembly files must be manually deployed to the target machine and run with the support of the Common Language Runtime (CLR), an analogy of Java Virtual Machine. For the purpose of the remote procedure calls, methods of the classes can be declared to be a web service. The framework will make such methods accessible using the Simple Object Application Protocol (SOAP), an extension of HTTP. Also, a description of the exposed services is usually published, in form of the Web Service Description Language (WSDL). Existing web services can be found on the Internet using specialized search engines conforming to the Universal Description, Discovery and Integration (UDDI) or the SOAP Discovery (DISCO) specifications. Once a desired service is found, its WSDL description can be retrieved. Based on that description, a source code of a proxy class can be generated into a desired programming language. The proxy then forwards method calls to the remote service. 2.4 Project SOFA The SOFA (Software Appliances) is an academic project managed by the CORBA and Distributed Systems Research Group at the Charles University in Prague. The goal of this project is to develop a considerably complex component system with a number of sophisticated features, such as the hierarchical composition, component trading and licensing, on demand distribution across the global network, run-time updating, and both design time and run-time protocol checking. To develop a SOFA application, the components are described using the Component Description Language (CDL). Using this language, the developer can describe the interfaces, frames and architectures. A frame is a set of interfaces, each of them used as a requirement or as a provision. Note that a frame can be perceived as a component type. Therefore, multiple components can implement the same frame. Visual Development of Software Components Page 17

18 An architecture is a description of the internal structure of a component on the first level of the hierarchical composition. Referring to a frame, an architecture determines the type of the component. It can either declare that the component is primitive, i.e. not containing any other subcomponents, or describe a set of its subcomponents based on the frames. In the later case, the interconnections between the interfaces of the component and its subcomponents are described using the bindings elements. The resulting CDL file is compiled by the CDL compiler, which stores the information into a specialized global database, the Type Information Repository (TIR). The information is automatically assigned with a version and can be later referenced from future CDL files. Based on this information, a source code of the primitive components should be pre-generated, so the task that would be left to the developer is to fill in the implementation. This part of the project has been already implemented to support the C++ programming language, and a support for the Java programming language is pending. It is important to notice that the information contained in TIR is just a detailed information about type of interfaces, components and one-level internal structures, but does not contain any information about the way in which these elements should be combined together. This information has to be provided separately, using an assembly descriptor, an XML description of the assembly tree. The leaves of the tree contain references to either a compiled source code of the primitive components, or to the existing components to be reused. The inner nodes represent the composed components. They contain a reference to the architecture selected as the internal structure of the composed component, interconnecting the subcomponents represented by the branches of the node. Based on the selected architectures, a code for the composed components should be generated by the system. The code for both the primitive and composed components, along with the assembly descriptor, should be packaged and submitted into a global component database, the Template Repository (TR). This part of the SOFA project has not been specified or implemented yet. Visual Development of Software Components Page 18

19 Without a doubt, an important advantage of the SOFA component system is the possibility to perform the hierarchical composition of the software components in a declarative way, rather than programmatically. However, the information on how to assemble the primitive components into an application is unfortunately scattered across the project. One part of this information, the architecture elements, is described along with the types and stored in the TIR. Another part of that information is provided in the assembly descriptor, defining the hierarchical structure of a component (the assembly tree). Let us show how these two parts of the information are dependent, one on the other. The dependency is obvious in one direction. To each inner node of the assembly tree is assigned an architecture (implementing the composed component represented by the node). But also in the other direction, the dependency applies. To design the all the architecture elements to be used in the inner nodes of an assembly tree (possibly with multiple levels), the assembly tree must be already known. Because of this two-way dependency, the idea to create the architecture elements along with the description of types (as a part of the CDL) does not seem reasonable. My suggestion would be to remove the architecture element from the CDL. There is no need to compensate the information provided by the instance elements, since the information about the subcomponents is contained in the assembly descriptor anyhow. So all that would have to be done is to extend the assembly descriptor with tags defining the interface interconnections, currently described using the binding elements. Visual Development of Software Components Page 19

20 3 Existing Products This section will describe a number of existing software development products studied during the research phase of this thesis, and list the practices and concepts that might be useful in a visual development environment for software components. 3.1 Visual Basic The first visual development environment introduced is the Microsoft s Visual Basic. It offers a variety of visual controls, widgets that can be composed into an application. The application is developed by choosing the desired types of controls from the toolbox (fig. 2) and by placing them onto a form (fig. 1), the container of the designed application. The configuration and interconnection of the designed controls is performed using the property sheet (fig. 3), a set of available options for each designed control. When a control is double-clicked, the environment is switched into a source code editing mode, when a custom event-handling code for the selected control can be provided. During this mode, automatic completion and highlighting of the edited source code is offered. Except the useful concept of control composition, Visual Basic introduces several other concepts: References: If all available controls should be offered in the toolbox, and all available classes should be offered in the source code editing mode, the selections would always have to be made from a large amount of choices. Therefore, in the references dialog, the developer marks the libraries that should be used, and only the controls and classes from the selected libraries are offered. Object Browser: A tool that can be used to browse classes and methods contained in the libraries that were selected for use. Visual Development of Software Components Page 20

21 Fig. 1 Form Fig. 2 Toolbox Fig. 3 Property Sheet Visual Development of Software Components Page 21

22 Class Builder: A tool that can be used to compose classes visually, by creating new methods and adding parameters. Visual Component Manager: A visual interface that can be connected to a local or remote database and used to store and retrieve source code, documentation, libraries, images, components, or any other files needed in the development process. The stored resources can be assigned a keyword or a textual description, so that they could be looked up later and retrieved. 3.2 Visual Studio.NET Microsoft s newest development product, Visual Studio.NET, uses the identical concepts as Visual Basic, except it can now support multiple programming languages, including Basic, C++ and C#. It also contains a packaging tool and an ER-modeling tool for designing the structure of databases. 3.3 C++ Builder / Delphi Borland s C++ Builder and Delphi (its an analogy, for the Pascal programming language) are two examples of classical visual development products. They use very similar concepts as Visual Basic. Furthermore, these two products contain the Type Library Editor, a tool that supports the development of COM components and CORBA objects (do not confuse with CCM components) by helping the developer in the process of describing the type information. The editor displays the tree structure of an edited module, provides a toolbar with buttons for creating new elements (e.g. modules, interfaces, methods, structures, and exceptions), and offers a dialog for the customization of each these elements. The type information created can be exported in the form of the MIDL file (for the COM component model), or in the form of the IDL (for the CORBA component model). Visual Development of Software Components Page 22

23 3.4 NetBeans IDE Sun Microsystems NetBeans IDE, also known as Forte for Java, is a platformindependent visual development environment. It is made up of a core that can be extended using several plug-in modules, provided by various vendors. More than ten modules are already present in the default distribution. The core by itself already provides several tree-views of a file system, a tree-view of the runtime nodes, and property sheets for performing various configurations of the selected node Editor Module and Java Module The Editor Module and the Java Module are two examples of modules included in the default distribution. The Editor Module provides a sophisticated source code editor with auto-completion and syntax highlighting for various languages, including the Java programming language. The Java Module has the ability to parse the Java source code partially, and display the internal structure of the source file in form of nodes, such as nodes for classes, methods, and attributes. These nodes can be added or removed and their properties can be modified using the property sheets. For example, for a currently selected method, properties such as the name, return value, parameters, and modifiers can be altered. All changes will immediately reflect in the source code. At this point, it is important to realize that typing the header of a method directly, using the source code editor, is in all cases much faster than choosing an add method command from a context menu and going through a series of dialogs where the developer is asked to select the access modifiers, type in the name of the method, add multiple parameters, and for each of them, type in the names and select the type. Such an approach might be useful to a developer that does not have any experience with the Java programming language, and therefore would not know the possible choices for access modifiers or return values. However, it does not generally benefit the source code development. Visual Development of Software Components Page 23

24 3.4.2 Form Editor Module The Form Editor Module, also included in the default distribution, provides a similar approach as Visual Basic to building the user interface classes. A variety of controls can be placed onto the form and configured using the property sheets. Furthermore, using the connection mode enables a number of properties and events to be interconnected visually. Unlike in Visual Basic, the generated code is not hidden from the user, but rather placed into the source code as a guarded section, a section prevented from being modified CORBA Module The CORBA Module is a part of Forte for Java, Internet Edition, a commercial distribution of the NetBeans IDE. This module was designed to support the development of distributed applications using the CORBA specification. When the CORBA Module is installed, an IDL file can be created using the CORBA Wizard that displays it as a tree-view of IDL elements. Command buttons and dialogs to add IDL elements such as modules, interfaces, and methods are provided (fig. 4). Once the CORBA Wizard is closed, the IDL file is generated and can be edited in the source code editor. The CORBA Module can also be configured to connect to various CORBA Services, such as the Naming Service and Interface Repository. Contents of these services are displayed as a runtime node. Interfaces stored in the Interface Repository can be acquired as an IDL file. For objects registered in the Naming Service, a client binding source code can be generated (fig. 5). 3.5 EJB Deploytool Deploytool, a part of Sun Microsystems Java 2 Software Development Kit, Enterprise Edition (J2SDK EE), is a utility for assembling, packaging, configuration, and deployment of the Enterprise Java Beans. Visual Development of Software Components Page 24

25 The tool (fig. 6) provides a tree-view of available applications and servers. Commands for creating new applications and for adding items into the existing ones are available via the toolbar and the menu bar. For each selected item, configuration sheets will appear. The developer can configure a number of properties, including the parameters explicitly exposed by the source code. When an application is assembled and configured, it can be saved as EJB Archive (EAR) file. In fact, it is a ZIP archive containing the assembled elements along with a deployment descriptor. Using the Deploy command, the selected EJB Archive can be deployed to a local or remote EJB server. Fig. 4 CORBA Wizard Visual Development of Software Components Page 25

26 Fig. 5 Tree-view of CORBA Naming Service Fig. 6 - Deploytool Visual Development of Software Components Page 26

27 4 Solution The first chapter of this section describes the requirements of the proposed solution on the underlying component framework. The second chapter describes the proposed solution itself, concepts of a visual development environment for software components with support for the hierarchical composition, reusability, configuration, and distributed deployment. 4.1 Requirements The proposed visual development environment requires an extensive support from the underlying framework, in which the designed components should be used. These requirements include: Components description language: To describe the components in a declarative way, a component description language should be provided. It should be able to describe component types, specifying the provisions and requirements in form of interfaces. Programming language mapping: The component framework should be able to generate classes representing the primitive components into one or more programming languages, so that the only task left to the developer would be to provide the implementation. Assembly descriptor with support for hierarchical composition: To assemble existing or newly created components into a single composed component, and to provide the initial configuration in a declarative way, an XML grammar should be specified. Visual Development of Software Components Page 27

28 Packaging tool: Based on the assembly descriptor, the component framework should be able to package all the files necessary to instantiate the component into a single file archive. Type repository: To store and retrieve the type information that is required to interconnect to or reuse the existing components, a type repository should be provided. Component repository: To store and retrieve the existing implementations of primitive components, as well as the existing assembly descriptors of composed components, a component repository should be provided. Distributed deployment: The framework should be able to deploy the components to a remote server, without the need to copy the component archive file to the target machine manually. Using a deployment descriptor, it should be possible to assign the deployment location for each of the subcomponents. Although not directly supporting hierarchical composition, the OMG s CORBA Component Model is a widely accepted component framework that is very close to realizing these requirements. 4.2 Proposed Concepts In the application (component) development process, as often described today, the application is split into several subcomponents in order to reduce the complexity. Provisions and requirements of each part are described in the form of interfaces, and the interconnections are specified. For each arisen subcomponent, it is revised if such component is already existing and can be reused, or if the component will be implemented directly, using a selected programming language. Although for simple projects, such design process can be often carried out on a piece of paper, for more complex projects it requires the help of a specialized modeling Visual Development of Software Components Page 28

29 tool. For the application design purposes, a Unified Modeling Language (UML) diagrams is the most common option. Based on the designed diagrams, a component description file for primitive components (i.e. the components that will be implemented directly) is written by hand or, in some modeling tools, generated automatically. Later, after the components are implemented, they can be composed into an application by adding an assembly descriptor or using an assembly tool. Notice that this step is redundant. This information is already known at that time, since the process of assembling an application (component) is reverse to the design process, where the application was split recursively into the subcomponents. It is beneficial to perform all stages of the development process in the same visual development environment, while keeping the assembly information created in the application design process. To provide the most lucid representation, the application (component) design should be displayed in a manner similar to the UML modeling tools. The implementation, assembly, configuration, and deployment should be performed in relation to this model. Such solution will be proposed in the following paragraphs, consisting of multiple visual development concepts: Component Designer A component that is being composed (the parent component) should be edited in a component designer (fig. 7). It should be displayed as a box containing sub-boxes representing the subcomponents. Interfaces of a component should be displayed as smaller shapes (boxes or circles) adjacent to the component. Different coloring or shaping can be used to distinguish provisions from requirements. The developer should be able to add and remove subcomponents and interfaces, move them around, adjust the size, and provide them with labels. Visual Development of Software Components Page 29

30 Fig. 7 Component Designer An interface of a subcomponent could be interconnected to an opposite interface belonging to another subcomponent, or postponed to a same interface belonging to the parent component. Note that only interfaces of the same type can be interconnected. Adding a subcomponent An existing subcomponent that is to be reused should be chosen from a component repository view where the components can be displayed or looked-up based on various criteria (i.e. package and name, provider, type, keyword description, etc.). Another possibility is to choose an existing component type first, by making a selection from the type repository. That way, the developer can later decide if the component will be implemented or if an existing component with the selected type will be reused. When creating a new subcomponent, an option to create a new type should be offered. As the subcomponent would be modified (i.e. interfaces will be added) the created type would change correspondingly. Adding an Interface It must be decided whether the interface should be a provision or a requirement. Visual Development of Software Components Page 30

31 The type of interface can be either chosen from the type repository, or a new type can be created Assembly Tree View To understand the internal structure of a designed component easily, and to navigate to the subcomponents quickly, a view of the assembly tree should be provided. Each node of the tree, representing the component, should be described by its name and type. It should also be obvious whether it is a composed component, primitive component, or reused component. When the developer double-clicks a node, the component designer should navigate to the represented component Property Sheets The same way as in Visual Basic, the properties of the selected item should be displayed in the property sheet. Custom choices and property dialogs for setting the values should be provided. Property dialog for choosing the type should offer the types contained in the type repository, as well as the types that were created in the project. Property dialog for choosing the implementation should offer the components contained in the component repository. For each component, it should be possible to pre-define the location (a reference to a server where the components will be executed). Of course, this location may be changed in the deployment stage, according to the specific needs. Also, for each primitive component (and for each composed component in some component models), it should be possible to specify the name of the implementation source code file that will be pre-generated. Visual Development of Software Components Page 31

32 4.2.4 Component Description File Based on the structure build using the component designer, a component description file should be generated. The environment should be able to display this file and provide syntax coloring. By editing this file, the user should enter the elements that are not suitable to be created visually, such as methods of the interfaces, structures, constants, exceptions, etc. To support the users without a detailed knowledge of the description language, an optional assistant box displaying the possible choices based on the current context could be provided. The elements generated based on the contents of the component designer (i.e. component types and interface types without methods) could be easily displayed as protected sections, prevented from being modified. Or even better, but with much more effort, they could be displayed as regular, modifiable source code that would, in case of modification, update the contents of the component designer. The later approach, often referred to as reverse engineering, requires an integrated compiler and can cause higher needs for hardware resources Primitive Components A primitive component is each component that does not contain any subcomponents, nor has set an implementation in the form of an existing component. Depending on the component framework, the primitive component can be implemented in one or more programming languages. Most frameworks have the ability to pregenerate the source files. In a visual development environment, there should be a command to pre-generate the source files. Since this operation can be dependent on a number of elements in the component description file, it is a better choice to pre-generate the source files for all primitive components at once, instead of generating them separately, one by one. Visual Development of Software Components Page 32

33 For each primitive component, a command should be provided (e.g. in the context menu of the representing node) to create (if not existing yet) and to open the implementation file. The implementation file of a primitive component should be a source file containing a class inherited from the pre-generated source file, not the original pregenerated source file itself. The reason for doing it this way is the possibility of updating. If the implementation were entered directly into the pre-generated files, a change in the component structure would cause the implementation to be overwritten. On the other hand, by keeping the implementation in a separate, inherited file, the custom source code will not be overwritten. Furthermore, using a synchronization command (offered by many visual development environments, including NetBeans), the methods and parameters in the inherited file can follow the update Packaging The visual development environment should contain a command for packaging the components (applications). Before starting the packaging process, the assembly descriptor file will be generated based on the contents of component designer and on the default configuration parameters entered in the property sheets. Most of the component frameworks already contain a packaging utility so this utility is to be started. Also, an option to publish the component should be offered. The publishing process should include creating a textual description and/or keyword description for the component, submitting the types used by the component into the type repository, and finally submitting the component package into the component repository Other Issues It is often important to have the possibility to redesign the layout of the component designer. Depending on the layout of the subcomponent, interfaces, and interconnections, the structure of a composed component may be easier or harder to Visual Development of Software Components Page 33

34 understand; therefore an algorithm that would find an optimal layout would be beneficial. Another important issue is the possibility to update the existing components. The concept of hierarchical composition enables an existing component to be repaired or updated effectively, by interchanging a subcomponent on an arbitrary level for a new subcomponent of the same type. Using a component framework with a sophisticated updating support, such action could even result into a real-time update, i.e. update without the need for stopping the whole application. To interchange the internal structure of an existing component, the contents of the component designer have to be recreated based on the imported assembly descriptor. Visual Development of Software Components Page 34

35 5 Prototype Implementation This section provides a detailed description of the prototype implementation, the proof of the proposed concepts of a visual development environment for software components. The implementation was created for the SOFA project as a plug-in module for the NetBeans IDE. 5.1 Underlying Framework Currently, the SOFA project offers a few tools and specifications that can be used as the foundation stones for the prototype tool. The Component Description Language (CDL) is a language for describing the SOFA components. A complete specification is available in a form of a grammar file. This language can describe component types (called frames), interface types, structures, constants, exceptions, etc. It can also describe architectures, the first level of the internal structure of a composed component. A compiler for this language is available, including the support for submitting the information into a type repository. The CDL grammar as proposed by the SOFA project is very complex, containing over 80 terminals, 140 non-terminals and 120 rules. It is very powerful in describing various types, structures, multi-dimensional arrays, and architectures containing complicated interconnections of such constructions. Therefore, the full CDL specification is too extensive for the purpose of the prototype implementation. For these reasons, only a reasonable subset of the CDL language was used. The subset was derived based on the examples provided as a part of the SOFA project. The Type Information Repository (TIR) is an implementation of a type repository. It provides an API that can be accessed by other applications via the Java RMI technology and used to submit and retrieve the type information. Each submitted type Visual Development of Software Components Page 35

36 information is automatically provided with a version. For the development purposes, a strong disadvantage of the TIR is the fact that once a type is submitted, it can be never changed or removed, only a new version can be created. Although an exact specification is not available, in several documents describing the SOFA project can be found that the assembly tree should be described in a form of an XML file called the assembly descriptor. A number of other proposed features are briefly described, though not implemented yet. Such features include the mapping of CDL to the Java source code, a packaging tool, and a component repository called the Template Repository (TR). 5.2 Installation Guide The prototype implementation is a plug-in module for NetBeans IDE, available from Sun Microsystems. Version is strongly recommended. It can be downloaded from To run NetBeans IDE, the Java 2 Software Development Kit, Standard Edition, version 1.3 or higher, is required. The newest version can be downloaded from Note that the hardware requirements of NetBeans IDE are quite demanding. Especially when dealing with insufficient memory, the operations are very slow. As the majority of Java applications, NetBeans IDE generally runs faster on the Microsoft Windows platform when compared to other available platforms (assuming the same hardware configuration). The prototype implementation, including the required parts of the SOFA project, can be downloaded from The provided ZIP archive contains: SOFA Developer plug-in module, including the source code and the generated documentation Several examples of components created in the SOFA Developer Visual Development of Software Components Page 36

37 Type Information Repository and CDL compiler To install the product, follow the instructions below: 1. Install the Java 2 SDK, SE and NetBeans IDE Unpack the downloaded ZIP archive 3. Run the NetBeans IDE 4. Use the Tools -> Update Center menu command 5. Check the second option (Install Manually Downloaded Modules) 6. Click Add and browse to the directory with the unpacked module 7. Confirm the SOFA Development module to be installed 8. Choose to restart the IDE immediately 9. Select the Filesystems tab and mount the directory with examples 5.3 User s Guide Component Template Select the mounted folder where a new component file should be created. To create a new SOFA component, select the File -> New menu command. In the next dialog, expand the SOFA folder and select the Component node. NetBeans note: The NetBeans IDE creates the tree-view nodes just in time, i.e. when the parent node is expanded. Therefore, especially on slow machines, the Component node may not be visible at first (the SOFA folder appears to be empty). If this happens, wait a few seconds after expanding the SOFA folder, until the Component node appears. In the next dialog, enter a name that will be used both as the filename for the component file and as the name for the component. Visual Development of Software Components Page 37

38 5.3.2 Component Node and the Assembly Tree In the Filesystems tab of the Explorer, you will see the component files as expandable nodes with a yellow rectangular icon. The label of each node is made up of the name and, in square braces, the type of the represented component. If you expand a node representing a composed component (e.g. the node of Project example) you will see one or more child nodes representing the subcomponents of the component represented by the parent node. Recursively, these nodes can be expanded to see the whole assembly tree of a component. Fig. 8 The Assembly Tree View When you select a node, the related information is displayed, and can be edited in the property sheets, usually placed below the Explorer. To open the component in the Component Designer, double-click its representing node Component Designer The Component Designer is a visual development tool that can be used to compose multiple subcomponents into a single composed component, to design the interfaces of both the parent component and the subcomponent, and to interconnect the interfaces. Visual Development of Software Components Page 38

39 The edited component is displayed as a frame, while the subcomponents are displayed as smaller frames placed inside the parent frame, displayed in slightly a lighter color. The hue of the frame colors can vary, while the same hue represents that the components belong to the same deployment unit (i.e. will be deployed to the same server). The interfaces are displayed as small squares adjacent to the edge of the frame. By the color of the interface, it can be distinguished if an interface represents a provision (displayed in white) or a requirement (displayed in cyan). The interconnections are displayed as arrows between the interfaces. The parent component and subcomponents are displayed with a label, indicating the name and type. Interfaces will display the label as a tool-tip when stopping the mouse above them for a while. Fig. 9 Component Designer The parent component, subcomponents, and interfaces can be selected using the mouse. The properties of a selected component are displayed, and can be edited in the property sheets. Toolbar commands also apply to the selection. Visual Development of Software Components Page 39

40 When selected, the parent component and subcomponents can be resized, while the subcomponents and interfaces can be moved. These actions are performed using the mouse in an intuitive way. For the requested operations, restrictions apply. An interface can be moved only along the edge of the frame where it belongs, subcomponents can not be moved outside the parent component, and neither the parent frame not a subcomponent can be resized so that the interfaces would fall outside. Component Designer can also be used to navigate inside the assembly tree. To edit a subcomponent, double-click it. To edit the component containing the subcomponent that is now displayed as the parent component, double-click inside the parent frame. NetBeans note: Currently, there is no recommended programmatic way to modify the selection inside the Explorer. Therefore, when navigating inside the assembly tree using the Component Designer, the original component node will remain selected. When the layout of a component is modified and the component is saved, the layout will be stored inside the component file. The layout will be restored the next time the component is loaded. A component that was never edited before, but contains subcomponents (i.e. is using a committed architecture), will be automatically laid out. The current layout algorithm can guarantee all subcomponents and interfaces to be visible, but does not guarantee the bindings to be well arranged Property Sheets To display and modify the properties of a selection, several property sets are provided. These sets are not limited to the properties in sense of variables defined by the component for the purpose of configuration. They extend to several other aspects. NetBeans note: The current releases of NetBeans IDE contain an annoying error directly related to the property sheets. When a window other than the Explorer (i.e. the Component Designer in this case) is selected and then a property is clicked to be edited, the property sheet will suddenly flash back to the properties of the node selected in the Visual Development of Software Components Page 40

41 Explorer window. To avoid this kind of error when working with the Component Designer and the property sheets, always click on the property sheet s tab (placed below the properties) before clicking on the property itself. The most important aspects which are accessible via the property are the names and types. The name and type has to be selected for each component and interface, while only a type is selected for the architectures. While the name is simply entered, you must click the symbol on the right side of the Type property and use the Type Manager (described in the next chapter in detail) to select the desired type. On the other hand, if you click the Type property and type a new name, the type will remain unchanged but will be renamed. For an interface, the mode can be set to either provision or requirement. Fig. 10 Property Sheets In the frame and architecture types, a number or configuration variables, coincidently called properties, can be defined. To manage the set of these variables, click on the symbol on the right side of the Properties property, on either the Frame or the Architecture property sheet. Only variables of either integer or string type are currently supported. The values of these variables can be entered using the Values property sheet. In the SOFA project, an array of components or interfaces of a fixed size can be defined instead of a single element. In case of a component array, the size is determined by a configuration variable defined in the parent frame or architecture. In case of an interface array, the size is determined by a configuration variable defined in the parent frame. To declare a component or an interface to be an array, click on the Array Visual Development of Software Components Page 41

42 property and select a configuration variable from the list. Only the integer variables are offered. Each component may, but does not have to specify the source file name and the deployment location. Source file name should be used by the component framework for the files generated based on the component description (the primitive components) and in some cases also for the composed components. However, if not specified, the framework should be able to create a default file name. Deployment location is a reference to a server where the component should be deployed. The set of all components with the same value of this property makes up a deployment unit. If not specified, the same deployment location as for the parent component will be assumed. Using the Source Code property of an interface, you can enter method declarations. Similarly, you can use the Protocol property of a frame or of an interface to enter the protocol specification. A text editing window is provided for these purposes, after clicking the symbol on the right side of the property. The Project property sheet groups the global properties, valid for the whole component file. Using the Custom Code property, a custom source code can be added to the component description. The Default Module and Default Provider properties specify the module and the architecture module where the types that are created automatically (when designing a component using the Component Designer) will be placed Type Manager The selection and management tool for the type information is the Type Manager dialog. It is invoked when a type is to be selected, as a reaction to clicking a property in the property sheets. The tree-view of the Type Manager shows the types as nodes, placed into folders representing the packages. Note that the interface and frame types can be placed in the top-level module or its submodules. On the other hand, the architecture types have to be placed in a special type of modules called the providers, or in their submodules called the architecture modules. Visual Development of Software Components Page 42

43 Type nodes always represent the most recent version of a type, called the default version. To see the full history of its versions, expand the node. Since versions in the SOFA project are assigned by the Type Information Repository, the types that have not been committed yet do not have a version assigned. The types nodes and folders representing types that have been committed are displayed with a red dot on the icon. Fig. 11 Type Manager To manage the types, either the right-click activated context menu or the toolbar can be used. On the toolbar, there are two command buttons that deserve a special attention: The Synchronize ( ) command will try to connect to the Type Information Repository and download all of its contents. The repository is accessible via Java RMI, so if running on the same machine, no special settings are required. During the synchronization process, a message window is displayed. The Duplicate ( ) command will create a new version of a type as its exact copy, allowing the developer to perform modifications. If applied to an uncommitted type, the exact copy will be created as a new type with a similar name. Visual Development of Software Components Page 43

44 5.3.6 Generating the.cdl and.dd files Once a component is designed, the Component Description Language (CDL) description and the Deployment Descriptor can be generated. This is done using the commands in the right-click activated context menu of the component file node. Since the committed types are in the Type Information Repository already present, only the uncommitted types are written to the CDL file. The Deployment Descriptor is an XML file representing the assembly tree of the component. Note that for component arrays, the requested count of the component elements is generated, allowing setting each configuration variable to a different value (e.g. in an XML editor). 5.4 Programmer s Guide From the programmer s point of view, the prototype implementation can be seen as an application composed of three layers, where each layer is independent of the layers above. Fig. 12 Prototype Implementation The Types Layer represents the type information, the Objects Layer represents the internal structure of the component, while the OpenIDE Layer provides visual means to display and modify the contents of the two below layers in the NetBeans IDE. Visual Development of Software Components Page 44