Software Re-Engineering for Real- XML Based Framework for Program Analysis Tool

Reference : 
An XML-Based Framework for Language Neutral Program Representation and Generic Analysis.By Raihan Al-Ekram and Kostas Kontogiannis

XML based tools are very useful in re- engineering era, because XML representation of source code gives the flexible way to analysis the high level information about the system using text based source code. XML is easy to understand, portable, open standard, extensible and interoperable. AST which is hierarchical representation of source code and tightly coupled with programming language's grammar. There are various XML based applications are available to represent the source code written in different languages. JavaML, CppML, srcML, PascalML XMLizer, Agile Parsing and GXL are some of them which produce complete or partial ASTs for specific programming languages. Moreover AST abstracts the program at a very fine level of granularity and hence not suitable to be used directly for higher level sophisticated program analysis. For a complete analysis of a source code, we need generic program analysing tool which support various languages and should give ability to analysis high level abstraction such as data flow and control flow among these blocks/components. Dataflow and control flows of a program can be represented using graphs in programming language independent way. Following graphs are some form of representations, used to represent high level abstractions.

Control Flow Graph (CFG) is used to represent the execution paths of program, widely used for code optimization, data flow analysis and testing. Program Dependence Graph (PDG) is used to represent both data and control dependencies, used for code optimization, parallelism and loop fusion. System Dependency Graph (SDG) is an extension of PDG, constructed by connecting individual PDGs using edges. Call Graphs are used to represent relationship between caller and callee in the program procedures for traditional inter-procedural analysis. Program Summary Graph (PSG) is an extension to Call Graph, considering global variables and reference parameters at individual call points.

The following figure shows architectures of “Generic Program Representation Framework” which is based on XML application developed for specific programming languages and concept such as object oriented programming, data flow diagram and control flow etc. It is consist three major abstracted layers. 

1. Source Code:[Layer 0]: Original source text of the program to be analysed.

2. AST Level Representation [Layer1]: First level of abstraction of program in terms of AST of program. [JavaML, CppML, CML, PascalML]. This layer also contains another sub layer which contains Object Oriented Mark-up Languages[OOML] and Procedural Mark-up Language[ProML] which are generic models for represent oriented languages and procedural languages respectively. These models are derived from generalising mark up language model for OO and Procedural languages respectively.

3. Higher Level Representation [Layer 2]: next level of abstractions in terms of intra- procedural and inter-procedural graphs. This layers has two sub layers Layer2.1 represent the basic fact of the program in FactML format, and Layer 2.2 is representation of intra-procedural and inter-procedural dependence and flow graphs of the program expressed as CFGML, PDGML,SDGML and CGML. Where;

FactML is used to represent the building blocks of programs such as classes, association among them using XML and corresponding DTD. These building blocks include Types, Variables, Statements, Functions and association classes. CFGML - CFG is a directed graph indicating basic blocks in program and possible flows of control from one to another. This is also represented using XML and corresponding DTDs. PDGML and CGML are XML representation of PDG and Call Graph. These XML based representations are derived from UML Class diagrams for each level.

Transformation tools are used to convert representation from one level to another level. Transformers may be source code transformer or XML to XML transformers. 

Thanks

TS

Software Re-Engineering for Real : Legacy Information Systems

Reference:  Legacy Information System

                  By George Bakehouse & Tony Wakefield

A legacy information system (LIS) represents a massive, long-term business  investment. Unfortunately, such systems are often brittle, slow, and non-extensible. Capturing legacy system data in a way that can support organizations into the future is an important but relatively very difficult and expensive. Generally the system which developed in 60’s, 70’s and 80’s are considered as legacy system but these systems are still running in businesses and more  reliable, secure and have lot of priceless information about the business. However owners of these systems are unable to compete in the market due to restricted characteristics.

Organization which are using legacy systems, are unable to invest money on new  project and  technologies, as they have to invest a lot in maintaining legacy  systems. In other hand replacement for legacy systems also very high risk and  high investment project, as they have hold valuable business information with  them. The decision to replace the existing legacy systems is derived by number of  factors such as lack of openness and non-extendable characteristics, they  doesn’t allow to integrate with new systems, and very difficult to adopt new  changes as they have been  deteriorated by continues changes and lack of documentation leads to maintenance programmers to spend more on understanding the system. To be an competitor in market, owners of these  systems should update their systems to meet the new challenges and demands, otherwise they will be affected negatively. Mergers and acquisition of organizations have also impacted on development of legacy system, M&As can result in the need to integrate two or more incompatible legacy systems or to upgrade the systems in the dominant partner to meet the requirements of the new acquisition which cause further replacement of legacy  systems. It is always better to replace the legacy systems when they are no longer productive or beneficial, replacement will give more benefit such as reduced   maintenance costs, improved productivity, and reduced number of staff dealing with system, reduced training time and ability to compete effectively.  Software re-engineering is the methodology to update / replace the legacy systems in more efficient way without lost of information data, document the system by understanding the code and then design and develop the new system with the data gathered. But still it costs a lot as; it is difficult and expensive to find people who are excellent in old technologies as well as newer.

Thanks
TS

Software Re-Engineering for Real : Software Aging

Software Aging

Reference :

Software Aging By By David Lorge Parnas

Software industry is like other industries, customer requirements are changing, technologies improves everyday and new technologies and products are introduced and users attracted towards new products with newer technologies and better performances. Older products are getting old and unable to compete with new. Software systems also get old with years when technology improves and changes made to meet the challenges and changing requirements. This is not new, but getting into more significant as demand for software system increases as with economic growth and software systems play major role in high-tech firms. So preventing software from early aging and keep up the existing legacy software systems, owners of this software have to take some actions.

Software aging is caused by two main factors, first is failure to modify the software to meet challenges other one is continuous changes made to the software by maintenance engineers without knowledge of actual design of the system, they do changes in code, it will degrade the quality of the software. Aging software are become hard to keep up with market, as there are lot of new competitive product with new technologies and with better performance and aging software often degrade it’s performance because of gradually deteriorating structure due the changes made that introduce new problems and bugs into the system.

Software aging is inevitable and un-avoidable, but still we need to take some preventive measures to decay or limit this issue. So software professionals should think in advance and enforce these preventive measures such as Design for Success / Design for Changes, Keep up better and updated documentation from beginning of the project, compulsory software reviews. As stated above, software aging is inevitable, design for changes is not an easy task as predicting the future changes is not easy, anyhow designers approximately predict the future changes and challenges that might slow down the software aging but cannot completely avoid it.

Even we do take preventive actions to slowdown aging of new software, but still we have got lots of legacy software which are being used and maintained without aware of this aging issue. Owners of such software have do take some immediate actions to keep up the system running and slowdown aging. Stopping more deterioration due to the changes made into the system in past, upgrade the documentation that can serve as good reference to future maintenance programmers, retroactive incremental modularization, amputation and restructuring the system with in appropriate way will help to decay the aging issue at least for some period.

It is always better consider software aging as a major problem and plan early to avoid or slowdown the aging issue. It is obviously important to deliver the first release of running software on date to the customer but deliver a running first release is not a only matter, delivering better quality software with imposing standards and documentation, plan for future changes by well documentations and reviews design before actual coding starts and document and review the changes made the software after release will help to avoid deterioration of system that will lead to limit aging issue. If software is not documented well then it is assumed that it is not done. Owners of software have to plan for future replacement both financially and technologically, like other products software is also has to be replaced with new design and technology to keep up the existing customer and attract new customers as well.

If we start act to prevent software aging there factors as barriers to the actions taken. Software crisis issue addressed long time ago, quick and easy solutions have never work in futures, it is lead software aging very quickly and software profession is not standardized like other professions like electrical engineers, aeronautical engineers...etc. Software profession has to be standardized by forming a professional body and software products should be checked for their quality by enforcing some industry standards.

Finally it is not true, if we assume that old software will not be running in future, if they don’t run, we need find out root cause of the problem, and try out something to sort out that. There are new ideas and techniques evolving to decay the software aging but they have to be put into real product to reach intended audience.

Thanks
TS

Software Re-Engineering for Real

Software Re-Engieering

"The examination and alteration of an existing subject system toreconstitute it in a new form. This process encompasses a combination of sub-processes such as reverse engineering, restructuring, redocumentation, forward engineering, and retargeting."

Aside: The new form of the subject system could be structured code - from "spaghetti" code; design information in graphical form - from input code; or the translation of the source code from one language to another while preserving the system's functionality."

As a Engineering student, I am really attracted to Software Re-engineering which we don't study in acadamic period , used to work when we get into industry. I recently started studying about software re-engineering techiques which involes migrating legacy systems which was developed ages ago but still in operations as well as refactoring and replacing new objected oriented legacy systems which developed using new, high level technologies but not with proper design and maintance.
In this blog, I am planned to write about software re-engineering , the main content of this articles are abstracted from some good research papers and journels about software re-engineering.
You can refer the main resources if you want to learn more about these technigues.

Thanks
TS