|
A Simple CASE-Tool for Creating and Managing couplings
between the RSCCs and each of the RSCC in an application |
|
| It is possible to invent tools to automatically create and manage communication dependencies of each of the RSCC and also communication couplings between the RSCCs in an application (i.e. a single executable such as
City_GIS application). Of course, author of this paper has been exploring other possible intelligent tools that are structurally different, which may be presented only after filing a patent application (if and when such tools are invented).
This web-page extends
trivial SoA (Service Oriented Architecture). FIG-1 shows a global Service Registration Object (SRO) or Directory. A simple SRO is presented in this web-page. The RSCCs are designed to be equivalent to the physical components (also referred to as Component-Parts or CPs in short). |
|
|
FIG-1: This Figure Illustrates, how a Simple SRO (or Directory Of Services) facilitate collaboration between any two components |
|
|
| A large application may contain many RSCCs (or CPs). Each RSCC (a) may provide one or more services for other RSCCs/parts, and (b) may consume one or more services of other RSCCs/parts. FIG-2 shows a global SRO (Service Registration Object). Each SP (Service provider) CP in an application registers each of its service-function along with unique pre-defined service-name with the SRO. An intelligent-SRO in FIG-3 can build a list of all the available services. Each SC (Service Consumer) CP in an application look-up for each of the services it requires by requesting SRO using respective service-name and stores reference of service function in a local variable. Now the SC-CP can use the reference stored in the local variable to call the service function for accessing required service. |
|
FIG-2: This Figure Illustrates, How a Simple SRO facilitate collaboration between multiple components in an application |
|
| |
Each of the CPs implements two virtual functions (the virtual factions are defined in the base class referred to as the RCCs): (i) the first virtual function registers each of the services provided by the CP using a predefined service-name and (ii) the second virtual function lookup for references of service-functions that provide required services and stores reference of the service-function in local variables to get each of the services when required. The listing-1 shows an example for the 2 virtual functions. One of the preferred methods for managing coupling interfaces between multiple CPs in an application requires registering each CP with a Global Service-Manager (GSM/SRO) object. For example:
|
|
- RepComp1 = new CP1_Class (params);
- GSM.add_CP (RepComp1,
CP_ID);
|
| The GSM calls the first virtual function of all the RSCCs/CPs in an application and builds a list of all available services. After building the list of all available services, the GSM calls the second virtual function of each of the RSCCs/CPs to couple service-providers and service-consumers. Please notice that container application (e.g. CityGIS) that using all the replaceable-CPs as sub-CPs is not implementing any communication code, since each RCC implements these two virtual functions. That is, communication code required to couple each CP is implemented inside the code of its RCC. So it is possible to remove each CP by removing the two lines of code, which makes each CP easily replaceable. |
|
|
Listing-1: Two virtual functions implemented in each RCC for creating coupling for the CP/RSCC
|
|
Code for each RCC comprises implementation of the virtual function that implements code for registering each of the services it provides with the global SRO. An example: |
public int register_all_services_provided (SRO_Class SRO)
{ // If this CP offers 3-services, it registers each of the 3-services using a pre-defined Lookup-name
SRO.RegisterService(CP_ID,Interface1a,ServiceName1, ServiceMethod1);
SRO.RegisterService(CP_ID,Interface2a,ServiceName2, ServiceMethod2);
SRO.RegisterService(CP_ID,Interface3a,ServiceName3, ServiceMethod3);
}// “Interface1a” may be a version object/string (e.g. 02.07.09) of the interface of ServiceMethod1 |
| Code for each
RCC comprises implementation of the virtual function that implements code for lookup with
for each of the services it requires in SRO by using respective
lookup-name: |
public int lookup_all_services_required
(SRO_Class SRO)
{ // If this CP needs 2-services, it looks-up for the 2-service-fucntions and saves them in local variables.
Reference1=SRO.Service_LookUp(CP_ID,Interface1, NameOfRequiredService1);
Reference2=SRO.Service_LookUp(CP_ID,Interface2, NameOfRequiredService2);
} //Each CP is designed to use pre-defined/agreed and published interfaces of other CPs. |
|
|
| The listing-1 shows 2 virtual functions implemented in each of the RCC. A Global Service-Manager (GSM) object is implemented (i) to call each of the RSCC/CP to register all of its services (e.g. see first function in above listing) and then (ii) to call each of the CP to lookup for all the services it requires (e.g. see second function in above listing). In this method, each RCC (implemented for a CP) also implements or encapsulates necessary communication code for the CP. This coupling may be performed only once at beginning, so it adds just one time little overhead at the beginning. |
|
|
Here each SP (Service provider) CP in an application registers each service-function along with unique pre-defined service-name with the SRO, where SRO is a pre-defined global ‘Service Registration Object’ that is accessible to every CP/RSCC in the application. The implementation of each CP/RSCC contains code to register services it provides with the SRO. For example:
|
- SRO.RegisterService(Version, ServiceName1, ServiceMethod1);
|
| For example, a shopping cart CP for shopping cart in a web application may offer a service for all the shopping items in the application to add the item to the shopping-cart and invoice table upon double-click on the item:
|
- SRO.RegisterService(Ver,“Shopping
Cart”, AddSelectedItemTo_InvoiceTable)
|
|
| The SRO builds a list of all the available services. Each SC (Service Consumer) CP in an application looks-up for each service it requires by requesting SRO using respective service-name (i.e. a lookup-key) and stores reference of service function in a local variable. For example:
|
- Reference1=SRO.Service_LookUp(Version, NameOfRequiredService1); // Or
- InvoiceFunc = SRO.Service_LookUp (Version, “Shopping Cart”);
|
|
| The objective is to minimize (or eliminate) need for creating any more communication code for coupling each of the RSCCs. If successful, each RSCC needs no more than 2 lines of code for including into its application. |
|
|
FIG-3: This Figure Illustrates, How an intelligent SRO creates and manages coupling interfaces of the components in an application |
|
|
| An intelligent implementation of SRO may build list of all the available services and all the required services. The SRO can be designed to analyze the lists to detect any broken couplings. For example, an unused service A, or a missing service B, or an incompatible service-interface between 2 CPs marked by C in FIG-5 (e.g. Either Service-provider-CP or Service-consumer-CP inadvertently ended up with slightly different interface-versions, so the CPs may not be able to collaborate properly using the interface C). This happens, if service of a CP is updated and not properly inform to developers of CPs that depend on the service. |
|
| Objective for these kinds of automation-tools is the help developers to redesign each RCC (of a CP) easily (e.g. for experimentation or rapid evolution of each CP) and use the automation-tools to detect any broken interfaces and help them resolve any coupling/collaboration issues. In other words, the objective is to minimize cost and complexity of making changes to the coupling interfaces of each of the RSCC and between the RSCCs in the application. |
|
| Since objective of each RCC of a CP is to sandbox and version the code-base of the CP, the RCC minimizes the cost and complexity of making changes to the internal functionality, as long as the coupling interfaces of the CP are not changed (that are used by other parts/CPs externally). So these kinds of tools are useful to minimize the cost and complexity of making changes to the external coupling interfaces. |
|
| The primary objective for the RCCs and such intelligent CASE-tools is to minimize cost and complexity of rapid evolution of each CP/RSCC. Designer of any CP (e.g. Car-battery) knows what service his CP needs and services the CP must provide. He doesn’t need to know any thing about internal design of other-CPs. If any two CPs collaborating with each other using an interface, the developer of each CP only need to know about the interface (e.g. number of parameter and type of parameters etc.). For example, it is possible to detect potential incompatible interfaces between two-CPs by including a parameter for versioning of the interface. |
|
FIG-4:
Component Dependency Map |
FIG-5:
Interfaces of a Component |
|
|
|
|
FIG-4: An intelligent SRO can be designed to present a global dependency map
of all the components in an application. Finding dependencies of any given
components and and each of its interfaces may be more useful than such global dependency map.
For example, if the coupling is a service-function, clicking on
the interface represented by a line connecting any two components
shows the number of parameters and types of the parameters. |
|
FIG-5: By clicking on a component in FIG-4 shows the
coupling interfaces of the component. By clicking on a
coupling-interfaces one can see (a) the detailed description of
the coupling-interface and (b) the list of other components that
are using the coupling interface. |
|
We can learn a lot from sophisticated software tools used by the
vendors of complex products (e.g. Boeing or Airbus) to maintain
dozens of models of airplanes around the world. Every one knows
potential disastrous
consequences, if a old part is replaced by wrong new part. |
|
|
The motives and future objectives for the intelligent CASE-tools
|
|
|
Kindly allow me to illustrate this using an example: If I joined a group that has built a complex software and as my first assignment I was asked to redesign a large SCC. I am sure, I don’t want to touch or even see code for any other part except code for the SCC. I can be immensely productive, if the SCC is encapsulated in a replaceable-modules
(e.g. as a RCC) to redesign the SCC little-by-little and test (for
making the SCC as best as it can be) individually.
|
|
After adding new features, functionality and making the SCC as best as it can be 
, I must know what kind of impact the changes would have on the other parts of the complex system. The motive for the intelligent CASE-tools is to help me and the other stake holders to efficiently and effectively communicate and collaborate for addressing the issues related to the communication between SCCs and to evolve or adapt the coupling interfaces of each SCC.
|
|
Since code-base for the SCC is sandboxed, I can’t touch code for any other part of the application to mess-up code for any other part. If I mess up the code-base of the SCC
 in the redesign,
versioning allows me to restore the previous clean version to start over
again.
These benefits are nothing new and have been taken for granted by designers of any
newly invented physical products, which for decades being designed as a CBD-structure. Since CBSD offers more flexibility, I am sure, software industry can invent highly sophisticated and intelligent-CASE-tools, which one day
make the designs of physical-products envy the designers of software products.
|
|
|
| The large physical components by inherent nature have remarkable property, which is: even the complex functional components by nature require simple interfaces, hence can be designed to have loosely coupled interfaces. It is essential for the components to have fewer and simpler coupling interfaces for increase the effectiveness of the
intelligent CASE-tools. |
|
| Let’s define replaceability factor as the ratio of (i) total internal complexity of the component and (ii) total complexity of all the interfaces. It is possible to leverage the inherent nature of the components to minimize the total complexity of all the interfaces, hence increasing the replaceability factor. Increasing the replaceability factor of a component reduces the cost of changes for satisfying the evolving needs. |
|
|
In the industrial design of physical products, this is popularly known as “Service Access” to the components, where motive is providing easy access to components that require frequent maintenance or replacement. Many designers are obsessed with maximizing ‘service access’ to most of the components. This reduction in cost of maintenance increases user satisfaction. Of course, motive there is to address wear and tear for cars, and in case of components allow upgrading parts such as memory or CPU to extend life. But in software, motive is to minimize cost and complexity of redesign to satisfy often unpredictable future needs. Although motives is different (e.g. for cars, computers or software), it is highly desirable for each large component to have excellent ‘service access’.
|
|
|
Many of the existing software component models try to standardize coupling interfaces, which make it much harder to change the coupling interfaces of the modules.
|
|
|
Rapidly adoptable to evolving needs is desirable for the components, which often require redesigning the coupling interfaces of each of the components and between the components.
|
|
|
Hence it is desirable to invent intelligent CASE-tools for creating and managing the coupling interfaces, and real components (i.e. SCCs) are by nature highly conducive for inventing such intelligent-tools for automating many tasks.
|
|
