**5. Conclusions**

92 Reverse Engineering – Recent Advances and Applications

engineered models. We believe that this is a good measure of quality of reverse engineered models. If the reverse engineered models are 'good enough' to be used as inputs to code generation (onto another platform) that means we have made progress toward model reusability. Therefore, for our experiments we chose to put the reverse engineered models to test. The results are consistent with our hypothesis and show 40-50% of savings in development effort. The two platforms investigated are IBM WebSphere and SAP NetWeaver platforms. We tried our approach on 5 different platform independent models – either modeled or derived. On an average, we have noted that by using our transformations we can reduce the develop effort by 40%-50% in a 6 month development project (Table 2).

**Phase Low Medium High Very** 

**Activity**

**Develop Back-end Data Objects** No Develop Data Dictionary Objects 4 578 No Develop Business Objects No **Develop Services** No **Develop Back-end Services (custom RFCs/BAPIs)** No Develop Custom RFC/BAPI(s) 8 16 32 40 No Expose RFC/BAPI(s) as Web Services using Web Service Creation Wizard 0.1 0.1 0.1 0.1 No Publish Web Services into Service Registry (UDDI Registry) 0.1 0.1 0.1 0.1 No Unit Testing of back-end Services 0.25 0.25 0.25 0.25 No

Development Local (CAF Layer) Business Objects with Attributes, Operations 0.5 0.75 1 1.5 Yes Development of Relationship amongst Business Objects 0.1 0.1 0.1 0.1 Yes Unit Testing of Local BOs 1 123 No

Import RFC/BAPI into CAF Core 0.1 0.1 0.1 0.1 Yes Import Enterprise Services into CAF Core 0.1 0.1 0.1 0.1 Yes Map External Services to Operations of Business Objects 1 111 No

Develop Application Services with Operations 1 246 Yes Map External Services to Operations of Application Services 1 122 Yes Implement Operations with Business Logic 8 16 24 36 No Expose Application Services as Web Services 0.1 0.1 0.1 0.1 Yes Publish Web Services into Service Registry (UDDI Registry) 0.1 0.1 0.1 0.1 No Unit Testing of Application Service Operations 0.5 1 2 4 No Deploy Entity Services into Web Application Server (WAS) No Deploy Application Services into Web Application Server (WAS) No Configure External Services after Deploying into Web Application Server (WAS) 1 122 No

Develop Visual Composer(VC) based User Interfaces 4 8 16 32 No Implement GP Callable Object Interface 8 12 20 24 No Develop WebDynpro (WD) Java based User Interfaces 16 32 48 64 Yes Develop Adobe Interactive Form (AIF) based User Interfaces 16 24 32 48 No

**With Model-driven Transformations** 18.9 36.15 55.4 73.9 **Total** 38.6 68.25 106.5 144 **Percentage Generated by Model-driven Transformations 48.96 52.97 52.02 51.32**

Table 2. Catalogs the development phase activities that our transformations help automate and the development effort reductions associated with them on SAP NetWeaver platform.

Our rationale for focusing on service abstractions in models is to keep the reverse transformations simple and practical. This allows developers to develop the forward and reverse transformations relatively quickly for new platforms and programming languages. In addition, one has to consider the capabilities of various vendor software middleware platforms as well in trying to decide how much of the modeling is to be done or to be extracted. For instance, software middleware platforms these days offer the capability to generate low level design using best-practice patterns and the corresponding code given a

**Develop & Deploy**

**Develop Entity Services (Local BOs)**

**Import External Services**

**Develop Application Services**

**SAP NetWeaver (Composite Core + Web DynPro)**

**Develop User Interfaces**

**Effort in hours**

0.1

**High**

**Model-driven Transformations** In this paper, we presented our approach to porting software solutions on multiple software middleware platforms. We propose the use of model-driven transformations to achieve cross-platform portability. We propose approaches for two scenarios. First, in cases where no software solution exists on any of the desired target middleware platforms, we advocate developing a platform independent model of the software solution in a formal modeling language such as UML and then applying model-driven transformations to generate implementation artifacts such as code and schemas from the models on the desired target platforms. Second, if a software solution already exists on one specific middleware platform, we propose applying reverse transformations to derive a platform independent model from the implementation artifacts and then applying forward transformations on the derived model to port that software solution on to a different target platform. We advance the traditional model-driven technique by presenting a service-oriented approach to deriving platform independent models from platform specific implementations.

The experiments we have conducted in deriving platform independent models from implementation artifacts have provided useful insights in a number of aspects and pointed us to future research topics in this area. The ability to leverage existing assets in a software environment depends significantly on the granularity of services modeled and exposed. Providing guidance on how granular the services should be for optimal reuse could be a topic for research. Rationalizing services that operate at different levels of granularity is another topic for further research.
