Lecture 8

chapter 30
software re-engineering

30.1 business process reengineering
30.2 software reengineering
30.3 reverse engineering
30.4 restructuring
30.5 forward engineering
30.6 the economics of reengineering
30. introduction
? in a seminal article written for the harvard business review, michael hammer laid the foundation for a revolution in management thinking about business processes and computing:
? it is time to stop paving the cow paths. instead of embedding outdated processes in silicon and software, we should obliterate them and start over. we should “reengineer” our businesses: use the power of modern information technology to radically redesign our business processes in order to achieve dramatic improvements in their performance.
? every company operates according to a great many unarticulated rules . . . reengineering strives to break away from the old rules about how we organize and conduct our business.
? like all revolutions, hammer’s call to arms resulted in both positive and negative changes. during the 1990s, some companies made a legitimate effort to reengineer, and the results led to improved competitiveness.
? others relied solely on downsizing and outsourcing (instead of reengineering) to improve their bottom line. “mean” organizations with little potential for future growth often resulted.
? during this first decade of the twenty-first century, the hype associated with reengineering has waned, but the process itself continues in companies large and small. the nexus between business reengineering and software engineering lies in a “system view.”
? software is often the realization of the business rules that hammer discusses. as these rules change, software must also change. today, major companies have tens of thousands of computer programs that support the “old business rules.” as managers work to modify the rules to achieve greater effectiveness and competitiveness, software must keep pace.
? in some cases, this means the creation of major new computer-based systems. but in many others, it means the modification or rebuilding of existing applications.
? in this chapter, we examine reengineering in a top-down manner, beginning with a brief overview of business process reengineering and proceeding to a more detailed discussion of the technical activities that occur when software is reengineered.
? what is it? consider any technology product that has served you well. you use it regularly, but it’s getting old. it breaks too often, takes longer to repair than you’d like, and no longer represents the newest technology.
? what to do? if the product is hardware, you’ll likely throw it away and buy a newer model. but if it’s custom-built software, that option may not be available. you’ll need to rebuild it. you’ll create a product with added functionality, better performance and reliability, and improved maintainability. that’s what we call reengineering.
? who does it? at a business level, reengineering is performed by business specialists (often consulting companies). at the software level, reengineering is performed by software engineers.
? why is it important? we live in a rapidly changing world. the demands on business functions and the information technology that supports them are changing at a pace that puts enormous competitive pressure on every commercial organization. both the business and the software that supports (or is) the business must be reengineered to keep pace.
? what are the steps? business process reengineering (bpr) defines business goals, identifies and evaluates existing business processes, and creates revised business processes that better meet current goals. the software reengineering process mate encompasses inventory analysis, document restructuring, reverse engineering, program and data restructuring, and forward engineering.
? the intent of these activities is to create versions of existing programs that exhibit higher quality and better maintainability.
? what is the work product? a variety of reengineering work products (e.g., analysis models, design models, test procedures) are produced.
? the final output is the reengineered business process and/or the reengineered software that supports it.
? how do i ensure that i’ve done it right? use the same sqa practices that are applied in every software engineering process - formal technical reviews assess the analysis and design models, specialized reviews consider business applicability and compatibility, testing is applied to uncover errors in content, functionality, and interoperability.
30.1 business process reengineering
? business process reengineering (bpr) extends far beyond the scope of information technologies and software engineering. among the many definitions (most somewhat abstract) that have been suggested for bpr is one published in fortune magazine: “the search for, and the implementation of, radical change in business process to achieve breakthrough results.”
? but how is the search conducted, and how is the implementation achieved? more important, how can we ensure that the “radical change” suggested will in fact lead to “breakthrough results” instead of organizational chaos?
30.1.1 business processes
? a business process is “a set of logically related tasks performed to achieve a defined business outcome”. within the business process, people, equipment, mate encompasses rial resources, and business procedures are combined to produce a specified result.
? examples of business processes include designing a new product, purchasing services and supplies, hiring a new employee, and paying suppliers. each demands a set of tasks and each draws on diverse resources within the business.
? every business process has a defined customer - a person or group that receives the outcome (e.g., an idea, a report, a design, a product). in addition, business processes cross organizational boundaries.
? they require that different organizational groups participate in the “logically related tasks” that define the process.
? previously, we noted that every system is actually a hierarchy of subsystems.
? a business is no exception. the overall business is segmented in the following manner:

the business
business systems
business process
business subprocesses

? each business system (also called business function) is composed of one or more business processes, and each business process is defined by a set of subprocesses.
? bpr can be applied at any level of the hierarchy, but as the scope of bpr broadens (i.e., as we move upward in the hierarchy), the risks associated with bpr grow dramatically. for this reason, most bpr efforts focus on individual processes or subprocesses.
30.1.2 principles of business process reengineering
? in many ways, bpr is identical in focus and scope to business process engineering. in an ideal setting, bpr should occur in a top-down manner, beginning with the identification of major business objectives and goals and culminating with a much more detailed specification of the tasks that define a specific business process.
? hammer suggests a number of principles that guide bpr activities when they begin at the top (business) level:
1. organize around outcomes, not tasks. many companies have compartmentalized business activities so that no single person (or organization) has responsibility (or control) of a business outcome. it such cases, it is difficult to determine the status of work and even more difficult to debug process problems if they do occur. bpr should design processes that avoid this problem.
2. have those who use the output of the process perform the process. the intent of this recommendation is to allow those who need business output to control all of the variables that allow them to get the output in a timely manner. the fewer separate constituencies involved in a process, the smoother is the road to a rapid outcome.
3. incorporate information processing work into the real work that produces the raw information. as it becomes more distributed, it is possible to locate most information processing within the organization that produces the raw data. this localizes control, reduces communication time, and puts computing power in the hands of those that have a vested interest in the information that is produced.
4. treat geographically dispersed resources as though they were centralized. computer-based communications have become so sophisticated that geographically diverse groups can be placed in the same “virtual office.” for example, instead of running three engineering shifts at a single location, a global company can run one shift in europe, a second shift in north america, and a third shift in asia. in each case, engineers will work during daylight hours and communicate via high-bandwidth networks.
5. link parallel activities instead of integrating their results. when different constituencies perform work in parallel, it is essential to design a process that demands continuing communication and coordination. otherwise, integration problems are sure to result.
6. put the decision point where the work is performed, and build control into the process. using software design jargon, this principle suggests a flatter organizational architecture with reduced factoring.
7. capture data once, at its source. data should be stored on-line so that once collected it need never be re-entered. each of these principles represents a “big picture” view of bpr. guided by these principles, business planners and process designers must begin process redesign. in the next section, we examine the process of bpr in a bit more detail.
30.1.3 a bpr model
? like most engineering activities, business process reengineering is iterative. business goals and the processes that achieve them must be adapted to a changing business environment. for this reason, there is no start and end to bpr - it is an evolutionary process.
? a model for business process reengineering is depicted in figure 30.1. the model defines six activities:
1. business definition. business goals are identified within the context of four key drivers: cost reduction, time reduction, quality improvement, and personnel development and empowerment. goals may be defined at the business level or for a specific component of the business.
2. process identification. processes that are critical to achieving the goals defined in the business definition are identified. they may then be ranked by importance, by need for change, or in any other way that is appropriate for the reengineering activity.
3. process evaluation. the existing process is thoroughly analyzed and measured. process tasks are identified the costs and time consumed by process tasks are noted and quality/performance problems are isolated.
4. process specification and design. based on information obtained during the first three bpr activities, use-cases (chapter 11) are prepared for each process that is to be redesigned. within the context of bpr, use-cases identify a scenario that delivers some outcome to a customer. with the use-case as the specification of the process, a new set of tasks (which conform to the principles noted in section 30.2.1) are designed for the process.
5. prototyping. a redesigned business process must be prototyped before it is fully integrated into the business. this activity “tests” the process so that refinements can be made.
6. refinement and instantiation. based on feedback from the prototype, the business process is refined and then instantiated within a business system. these bpr activities are sometimes used in conjunction with workflow analysis tools. the intent of these tools is to build a model of existing workflow in an effort to better analyze existing processes. in addition, the modeling techniques commonly associated with business process engineering activities such as information strategy planning and business area analysis (chapter 10) can be used to implement the first four activities described in the process model.

figure 30.1: a bpr model
30.1.4 words of warning
? it is not uncommon that a new business approach - in this case, bpr - is at first hyped as a panacea, and then criticized so severely that it becomes a pariah. over the years, debate has raged about the efficacy of bpr.
? in an excellent discussion of the case for and against bpr, weisz summarizes the argument in the following way: it is tempting to bash bpr as another silver-bullet fad. from several points of view: systems thinking, peopleware, simple history - you’d have to predict high failure rates for the concept, rates which seem to be borne out by empirical evidence. for many companies, the silver bullet has apparently missed.
? for others, though, the reengineering effort has evidently been fruitful. bpr can work, if it is applied by motivated, trained people who recognize that process reengineering is a continuous activity.
? if bpr is conducted effectively, information systems are better integrated into the business process. reengineering older applications can be examined in the context of a broad-based business strategy, and priorities for software reengineering can be established intelligently.
? but even if business reengineering is a strategy that is rejected by a company, software reengineering is something that must be done. tens of thousands of legacy systems - applications that are crucial to the success of businesses large and small - are in dire need of refurbishing or rebuilding.
30.2 software reengineering
? the scenario is all too common: an application has served the business needs of a company for 10 or 15 years. during that time it has been corrected, adapted, and enhanced many times. people approached this work with the best intentions, but good software engineering practices were always shunted to the side (the press of other matters).
? now the application is unstable. it still works, but every time a change is attempted, unexpected and serious side effects occur. yet the application must continue to evolve. what to do?
? unmaintainable software is not a new problem. in fact, the broadening emphasis on software reengineering has been spawned by a software maintenance “iceberg” that has been building for more than three decades.
30.2.1 software maintenance
? thirty years ago, software maintenance was characterized as an "iceberg." we hope that what was immediately visible is all there is to it, but we know that an enormous mass of potential problems and cost lies under the surface.
? in the early 1970s, the maintenance iceberg was big enough to sink an aircraft carrier. today, it could easily sink the entire navy!
? the maintenance of existing software can account for over 60 percent of all effort expended by a development organization, and the percentage continues to rise as more software is produced. uninitiated readers may ask why so much maintenance is required and why so much effort is expended. osborne and chikofsky provide a partial answer:
? much of the software we depend on today is on average 10 to 15 years old. even when these programs were created using the best design and coding techniques known at the time [and most were not], they were created when program size and storage space were principle concerns. they were then migrated to new platforms, adjusted for changes in machine and operating system technology and enhanced to meet new user needs - all without enough regard to overall architecture.
? the result is the poorly designed structures, poor coding, poor logic, and poor documentation of the software systems we are now called on to keep running . . .
? the ubiquitous nature of change underlies all software work. change is inevitable when computer-based systems are built therefore, we must develop mechanisms for evaluating, controlling, and making modifications.
? upon reading the preceding paragraphs, a reader may protest: "but i don t spend 60 percent of my time fixing mistakes in the programs i develop." software maintenance is, of course, far more than "fixing mistakes." we may define maintenance by describing four activities that are undertaken after a program is released for use. we defined four different maintenance activities:
o corrective maintenance,
o adaptive maintenance,
o perfective maintenance or enhancement, and
o preventive maintenance or reengineering.
? only about 20 percent of all maintenance work is spent “fixing mistakes.” the remaining 80 percent is spent adapting existing systems to changes in their external environment, making enhancements requested by users, and reengineering an application for future use.
? when maintenance is considered to encompass all of these activities, it is relatively easy to see why it absorbs so much effort.
30.2.2 a software reengineering process model
? reengineering takes time it costs significant amounts of money and it absorbs resources that might be otherwise occupied on immediate concerns.
? for all of these reasons, reengineering is not accomplished in a few months or even a few years.
? reengineering of information systems is an activity that will absorb information technology resources for many years. that’s why every organization needs a pragmatic strategy for software reengineering.
? reengineering is a rebuilding activity, and we can better understand the reengineering of information systems if we consider an analogous activity: the rebuilding of a house. consider the following situation.
? you have purchased a house in another state. you’ve never actually seen the property, but you acquired it at an amazingly low price, with the warning that it might have to be completely rebuilt. how would you proceed?
• before you can start rebuilding, it would seem reasonable to inspect the house. to determine whether it is in need of rebuilding, you (or a professional inspector) would create a list of criteria so that your inspection would be systematic.
• before you tear down and rebuild the entire house, be sure that the structure is weak. if the house is structurally sound, it may be possible to “remodel” without rebuilding (at much lower cost and in much less time).
• before you start rebuilding be sure you understand how the original was built. take a peek behind the walls. understand the wiring, the plumbing, and the structural internals. even if you trash them all, the insight you’ll gain will serve you well when you start construction.
• if you begin to rebuild, use only the most modern, long-lasting materials. this may cost a bit more now, but it will help you to avoid expensive and time-consuming maintenance later.
• if you decide to rebuild, be disciplined about it. use practices that will result in high quality - today and in the future.
? although these principles focus on the rebuilding of a house, they apply equally well to the reengineering of computer-based systems and applications.
? to implement these principles, we apply software reengineering process model that defines six activities, shown in figure 30.2. in some cases, these activities occur in a linear sequence, but this is not always the case.
? for example, it may be that reverse engineering (understanding the internal workings of a program) may have to occur before document restructuring can commence.
? the reengineering paradigm shown in the figure is a cyclical model. this means that each of the activities presented as a part of the paradigm may be revisited. for any particular cycle, the process can terminate after any one of these activities.
? inventory analysis. every software organization should have an inventory of all applications. the inventory can be nothing more than a spreadsheet model containing information that provides a detailed description (e.g., size, age, business criticality) of every active application. by sorting this information according to business criticality, longevity, current maintainability, and other locally important criteria, candidates for reengineering appear. resources can then be allocated to candidate applications for reengineering work. it is important to note that the inventory should be revisited on a regular cycle.

figure 30.2 a software reengineering process model
? document restructuring. weak documentation is the trademark of many legacy systems. but what do we do about it? what are our options?
1. creating documentation is far too time consuming. if the system works, we’ll live with what we have. in some cases, this is the correct approach. it is not possible to re-create documentation for hundreds of computer programs. if a program is relatively static, is coming to the end of its useful life, and is unlikely to undergo significant change, let it be!
2. documentation must be updatingd, but we have limited resources. we’ll use a “document when touched” approach. it may not be necessary to fully redocument an application. rather, those portions of the system that are currently undergoing change are fully documented. over time, a collection of useful and relevant documentation will evolve.
3. the system is business critical and must be fully redocumented. even in this case, an intelligent approach is to pare documentation to an essential minimum. each of these options is viable. a software organization must choose the one that is most appropriate for each case.
? reverse engineering. the term reverse engineering has its origins in the hardware world. a company disassembles a competitive hardware product in an effort to understand its competitor s design and manufacturing "secrets." these secrets could be easily understood if the competitor s design and manufacturing specifications were obtained. but these documents are proprietary and unavailable to the company doing the reverse engineering. in essence, successful reverse engineering derives one or more design and manufacturing specifications for a product by examining actual specimens of the product.
? reverse engineering for software is quite similar. in most cases, however, the program to be reverse engineered is not a competitor s. rather, it is the company s own work (often done many years earlier). the "secrets" to be understood are obscure because no specification was ever developed.
? therefore, reverse engineering for software is the process of analyzing a program in an effort to create a representation of the program at a higher level of abstraction than source code.
? reverse engineering is a process of design recovery. reverse engineering tools extract data, architectural, and procedural design information from an existing program.
? code restructuring. the most common type of reengineering (actually, the use of the term reengineering is questionable in this case) is code restructuring. some legacy systems have a relatively solid program architecture, but individual modules were coded in a way that makes them difficult to understand, test, and maintain. in such cases, the code within the suspect modules can be restructured.
? to accomplish this activity, the source code is analyzed using a restructuring tool. violations of structured programming constructs are noted and code is then restructured (this can be done automatically). the resultant restructured code is reviewed and tested to ensure that no anomalies have been introduced. internal code documentation is updatingd.
? data restructuring. a program with weak data architecture will be difficult to adapt and enhance. in fact, for many applications, data architecture has more to do with the long-term viability of a program that the source code itself. unlike code restructuring, which occurs at a relatively low level of abstraction, data structuring is a full-scale reengineering activity. in most cases, data restructuring begins with a reverse engineering activity. current data architecture is dissected and necessary data models are defined (chapter 12). data objects and attributes are identified, and existing data structures are reviewed for quality.
? when data structure is weak (e.g., flat files are currently implemented, when a relational approach would greatly simplify processing), the data are reengineered.
? because data architecture has a strong influence on program architecture and the algorithms that populate it, changes to the data will invariably result in either architectural or code-level changes.
? forward engineering. in an ideal world, applications would be rebuilt using a automated “reengineering engine.” the old program would be fed into the engine, analyzed, restructured, and then regenerated in a form that exhibited the best aspects of software quality. in the short term, it is unlikely that such an “engine” will appear, but case vendors have introduced tools that provide a limited subset of these capabilities that addresses specific application domains (e.g., applications that are implemented using a specific database system). more important, these reengineering tools are becoming increasingly more sophisticated.
? forward engineering, also called renovation or reclamation, not only recovers design information from existing software, but uses this information to alter or reconstitute the existing system in an effort to improve its overall quality. in most cases, reengineered software reimplements the function of the existing system and also adds new functions and/or improves overall performance.
30.3 reverse engineering
? reverse engineering conjures an image of the "magic slot." we feed an unstructured, undocumented source listing into the slot and out the other end comes full documentation for the computer program.
? unfortunately, the magic slot doesn t exist. reverse engineering can extract design information from source code, but the abstraction level, the completeness of the documentation, the degree to which tools and a human analyst work together, and the directionality of the process are highly variable.
? the abstraction level of a reverse engineering process and the tools used to effect it refers to the sophistication of the design information that can be extracted from source code. ideally, the abstraction level should be as high as possible. that is, the reverse engineering process should be capable of deriving procedural design representations (a low-level abstraction), program and data structure information (a somewhat higher level of abstraction), data and control flow models (a relatively high level of abstraction), and entity relationship models (a high level of abstraction).
? as the abstraction level increases, the software engineer is provided with information that will allow easier understanding of the program.
? the completeness of a reverse engineering process refers to the level of detail that is provided at an abstraction level. in most cases, the completeness decreases as the abstraction level increases. for example, given a source code listing, it is relatively easy to develop a complete procedural design representation.
? simple data flow representations may also be derived, but it is far more difficult to develop a complete set of data flow diagrams or entity-relationship models.
? completeness improves in direct proportion to the amount of analysis performed by the person doing reverse engineering. interactivity refers to the degree to which the human is "integrated" with automated tools to create an effective reverse engineering process.
? in most cases, as the abstraction level increases, interactivity must increase or completeness will suffer.
? if the directionality of the reverse engineering process is one way, all information extracted from the source code is provided to the software engineer who can then use it during any maintenance activity.
? if directionality is two way, the information is fed to a reengineering tool that attempts to restructure or regenerate the old program.
? the reverse engineering process is represented in figure 30.3. before reverse engineering activities can commence, unstructured (“dirty”) source code is restructured (section 30.4.1) so that it contains only the structured programming constructs.
? this makes the source code easier to read and provides the basis for all the subsequent reverse engineering activities.
? the core of reverse engineering is an activity called extract abstractions. the engineer must evaluate the old program and from the (often undocumented) source code, extract a meaningful specification of the processing that is performed, the user interface that is applied, and the program data structures or database that is used.


figure 30.3 the reverse engineering process

30.3.1 reverse engineering to understand processing
? the first real reverse engineering activity begins with an attempt to understand and then extract procedural abstractions represented by the source code.
? to understand procedural abstractions, the code is analyzed at varying levels of abstraction: system, program, component, pattern, and statement.
? the overall functionality of the entire application system must be understood before more detailed reverse engineering work occurs.
? this establishes a context for further analysis and provides insight into interoperability issues among applications within the system. each of the programs that make up the application system represents a functional abstraction at a high level of detail. a block diagram, representing the interaction between these functional abstractions, is created. each component performs some subfunction and represents a defined procedural abstraction. a processing narrative for each component is created.
? in some situations, system, program and component specifications already exist. when this is the case, the specifications are reviewed for conformance to existing code.
? things become more complex when the code inside a component is considered.
? the engineer looks for sections of code that represent generic procedural patterns.
? in almost every component, a section of code prepares data for processing (within the module), a different section of code does the processing, and another section of code prepares the results of processing for export from the component.
? within each of these sections, we can encounter smaller patterns for example, data validation and bounds checking often occur within the section of code that prepares data for processing.
? for large systems, reverse engineering is generally accomplished using a semiautomated approach. case tools are used to “parse” the semantics of existing code. the output of this process is then passed to restructuring and forward engineering tools to complete the reengineering process.
30.3.2 reverse engineering to understand data
? reverse engineering of data occurs at different levels of abstraction. at the program level, internal program data structures must often be reverse engineered as part of an overall reengineering effort.
? at the system level, global data structures (e.g., files, databases) are often reengineered to accommodate new database management paradigms (e.g., the move from flat file to relational or object-oriented database systems).
? reverse engineering of the current global data structures sets the stage for the introduction of a new systemwide database.
? internal data structures. reverse engineering techniques for internal program data focus on the definition of classes of objects. this is accomplished by examining the program code with the intent of grouping related program variables.
? in many cases, the data organization within the code identifies abstract data types. for example, record structures, files, lists, and other data structures often provide an initial indicator of classes.
? breuer and lano suggest the following approach for reverse engineering of classes:
1. identify flags and local data structures within the program that record important information about global data structures (e.g., a file or database).
2. define the relationship between flags and local data structures and the global data structures. for example, a flag may be set when a file is empty a local data structure may serve as a buffer that contains the last 100 records acquired from a central database.
3. for every variable (within the program) that represents an array or file, list all other variables that have a logical connection to it.
? these steps enable a software engineer to identify classes within the program that interact with the global data structures.
? database structure. regardless of its logical organization and physical structure, a database allows the definition of data objects and supports some method for establishing relationships among the objects. therefore, reengineering one database schema into another requires an understanding of existing objects and their relationships.
? the following steps may be used to define the existing data model as a precursor to reengineering a new database model:
1. build an initial object model. the classes defined as part of the model may be acquired by reviewing records in a flat file database or tables in a relational schema. the items contained in records or tables become attributes of a class.
2. determine candidate keys. the attributes are examined to determine whether they are used to point to another record or table. those that serve as pointers become candidate keys.
3. refine the tentative classes. determine whether similar classes can be combined into a single class.
4. define generalizations. examine classes that have many similar attributes to determine whether a class hierarchy should be constructed with a generalization class at its head.
5. discover associations. use techniques that are analogous to the crc approach (chapter 21) to establish associations among classes.
? once information defined in the preceding steps is known, a series of transformations can be applied to map the old database structure into a new database structure.
30.3.3 reverse engineering user interfaces
? sophisticated guis have become de rigueur for computer-based products and systems of every type. therefore, the redevelopment of user interfaces has become one of the most common types of reengineering activity.
? but before a user interface can be rebuilt, reverse engineering should occur.
? to fully understand an existing user interface (ui), the structure and behavior of the interface must be specified. merlo and his colleagues suggest three basic questions that must be answered as reverse engineering of the ui commences:
• what are the basic actions (e.g., keystrokes and mouse clicks) that the interface must process?
• what is a compact description of the behavioral response of the system to these actions?
• what is meant by a “replacement,” or more precisely, what concept of equivalence of interfaces is relevant here?
? behavioral modeling notation (chapter 12) can provide a means for developing answers to the first two questions. much of the information necessary to create a behavioral model can be obtained by observing the external manifestation of the existing interface. but additional information necessary to create the behavioral model must extracted from the code.
? it is important to note that a replacement gui may not mirror the old interface exactly (in fact, it may be radically different). it is often worthwhile to develop new interaction metaphors.
? for example, an old ui requests that a user provide a scale factor (ranging from 1 to 10) to shrink or magnify a graphical image. a reengineered gui might use a slide-bar and mouse to accomplish the same function.
30.4 restructuring
? software restructuring modifies source code and/or data in an effort to make it amenable to future changes. in general, restructuring does not modify the overall program architecture. it tends to focus on the design details of individual modules and on local data structures defined within modules.
? if the restructuring effort extends beyond module boundaries and encompasses the software architecture, restructuring becomes forward engineering (section 30.5).
? arnold defines a number of benefits that can be achieved when software is restructured:
• programs have higher quality - better documentation, less complexity, and conformance to modern software engineering practices and standards.
• frustration among software engineers who must work on the program is reduced, thereby improving productivity and making learning easier.
• effort required to perform maintenance activities is reduced.
• software is easier to test and debug.
? restructuring occurs when the basic architecture of an application is solid, even though technical internals need work. it is initiated when major parts of the software are serviceable and only a subset of all modules and data need extensive modification.
30.4.1 code restructuring
? code restructuring is performed to yield a design that produces the same function but with higher quality than the original program. in general, code restructuring techniques (e.g., warnier s logical simplification techniques( model program logic using boolean algebra and then apply a series of transformation rules that yield restructured logic.
? the objective is to take "spaghetti-bowl" code and derive a procedural design that conforms to the structured programming philosophy (chapter 16).
? other restructuring techniques have also been proposed for use with reengineering tools.
? a resource exchange diagram maps each program module and the resources (data types, procedures and variables) that are exchanged between it and other modules.
? by creating representations of resource flow, the program architecture can be restructured to achieve minimum coupling among modules.
30.4.2 data restructuring
? before data restructuring can begin, a reverse engineering activity called analysis of source code must be conducted. all programming language statements that contain data definitions, file descriptions, i/o, and interface descriptions are evaluated.
? the intent is to extract data items and objects, to get information on data flow, and to understand the existing data structures that have been implemented. this activity is sometimes called data analysis.
? once data analysis has been completed, data redesign commences. in its simplest form, a data record standardization step clarifies data definitions to achieve consistency among data item names or physical record formats within an existing data structure or file format.
? another form of redesign, called data name rationalization, ensures that all data naming conventions conform to local standards and that aliases are eliminated as data flow through the system.
? when restructuring moves beyond standardization and rationalization, physical modifications to existing data structures are made to make the data design more effective. this may mean a translation from one file format to another, or in some cases, translation from one type of database to another.
30.5 forward engineering
? a program with control flow that is the graphic equivalent of a bowl of spaghetti, with "modules" that are 2,000 statements long, with few meaningful comment lines in 290,000 source statements and no other documentation must be modified to accommodate changing user requirements. we have the following options:
1. we can struggle through modification after modification, fighting the implicit design and source code to implement the necessary changes.
2. we can attempt to understand the broader inner workings of the program in an effort to make modifications more effectively.
3. we can redesign, recode, and test those portions of the software that require modification, applying a software engineering approach to all revised segments.
4. we can completely redesign, recode, and test the program, using case (reengineering) tools to assist us in understanding the current design.
? there is no single "correct" option. circumstances may dictate the first option even if the others are more desirable.
? rather than waiting until a maintenance request is received, the development or support organization uses the results of inventory analysis to select a program that:
(1) will remain in use for a preselected number of years,
(2) is currently being used successfully, and
(3) is likely to undergo major modification or enhancement in the near future. then, option 2, 3, or 4 is applied.
? this preventative maintenance approach was pioneered by miller under the title structured retrofit. this concept is defined as "the application of today s methodologies to yesterday s systems to support tomorrow s requirements."
? at first glance, the suggestion that we redevelop a large program when a working version already exists may seem quite extravagant. before passing judgment, consider the following points:
1. the cost to maintain one line of source code may be 20 to 40 times the cost of initial development of that line.
2. redesign of the software architecture (program and/or data structure), using modern design concepts, can greatly facilitate future maintenance.
3. because a prototype of the software already exists, development productivity should be much higher than average.
4. the user now has experience with the software. therefore, new requirements and the direction of change can be ascertained with greater ease.
5. case tools for reengineering will automate some parts of the job.
6. a complete software configuration (documents, programs, and data) will exist upon completion of preventive maintenance.
? when a software development organization sells software as a product, preventive maintenance is seen in "new releases" of a program.
? a large in-house software developer (e.g., a business systems software development group for a large consumer products company) may have 500–2000 production programs within its domain of responsibility. these programs can be ranked by importance and then reviewed as candidates for preventive maintenance.
? the forward engineering process applies software engineering principles, concepts, and methods to re-create an existing application. in most cases, forward engineering does not simply create a modern equivalent of an older program.
? rather, new user and technology requirements are integrated into the reengineering effort. the redeveloped program extends the capabilities of the older application.


30.5.1 forward engineering for client/server architectures
? over the past decade many mainframe applications have been reengineered to accommodate client/server architectures. in essence, centralized computing resources (including software) are distributed among many client platforms.
? although a variety of different distributed environments can be designed, the typical mainframe application that is reengineered into a client/server architecture has the following features:
• application functionality migrates to each client computer.
• new gui interfaces are implemented at the client sites.
• database functions are allocated to the server.
• specialized functionality (e.g., compute-intensive analysis) may remain at the server site.
• new communications, security, archiving, and control requirements must be established at both the client and server sites.
? it is important to note that the migration from mainframe to c/s computing requires both business and software reengineering.
? in addition, an “enterprise network infrastructure” should be established.
? reengineering for c/s applications begins with a thorough analysis of the business environment that encompasses the existing mainframe. three layers of abstraction (figure 30.4) can be identified.
? the database sits at the foundation of a client/server architecture and manages transactions and queries from server applications. yet these transactions and queries must be controlled within the context of a set of business rules (defined by an existing or reengineered business process).
? client applications provide targeted functionality to the user community.
? the functions of the existing database management system and the data architecture of the existing database must be reverse engineered as a precursor to the redesign of the database foundation layer.
? in some cases a new data model (chapter 12) is created. in every case, the c/s database is reengineered to ensure that transactions are executed in a consistent manner, that all updatings are performed only by authorized users, that core business rules are enforced (e.g., before a vendor record is deletingd, the server ensures that no related accounts payable, contracts, or communications exist for that vendor), that queries can be accommodated efficiently, and that full archiving capability has been established.
? the business rules layer represents software resident at both the client and the server. this software performs control and coordination tasks to ensure that transactions and queries between the client application and the database conform to the the established business process.
? the client applications layer implements business functions that are required by specific groups of end-users. in many instances, a mainframe application is segmented into a number of smaller, reengineered desktop applications.
? communication among the desktop applications (when necessary) is controlled by the business rules layer.


figure 30.4: reengineering mainframe applications to client/server

30.5.2 forward engineering for object-oriented architectures
? object-oriented software engineering has become the development paradigm of choice for many software organizations. but what about existing applications that were developed using conventional methods?
? in some cases, the answer is to leave such applications “as is.” in others, older applications must be reengineered so that they can be easily integrated into large, object-oriented systems.
? reengineering conventional software into an object-oriented implementation uses many of the same techniques discussed in part four of this book.
? first, the existing software is reverse engineered so that appropriate data, functional, and behavioral models can be created. if the reengineered system extends the functionality or behavior of the original application, use-cases are created.
? the data models created during reverse engineering are then used in conjunction with crc modeling to establish the basis for the definition of classes.
? class hierarchies, object-relationship models, object-behavior models, and subsystems are defined, and object-oriented design commences.
? as object-oriented forward engineering progresses from analysis to design, a cbse process model can be invoked. if the existing application exists within a domain that is already populated by many object-oriented applications, it is likely that a robust component library exists and can be used during forward engineering.
? for those classes that must be engineered from scratch, it may be possible to reuse algorithms and data structures from the existing conventional application. however, these must be redesigned to conform to the object-oriented architecture.
30.5.3 forward engineering user interfaces
? as applications migrate from the mainframe to the desktop, users are no longer willing to tolerate arcane, character-based user interfaces. in fact, a significant portion of all effort expended in the transition from mainframe to client/server computing can be spent in the reengineering of client application user interfaces.
? merlo and his colleagues suggest the following model for reengineering user interfaces:
1. understand the original interface and the data that move between it and the remainder of the application. the intent is to understand how other elements of a program interact with existing code that implements the interface. if a new gui is to be developed, the data that flow between the gui and the remaining program must be consistent with the data that currently flow between the character-based interface and the program.
2. remodel the behavior implied by the existing interface into a series of abstractions that have meaning in the context of a gui. although the mode of interaction may be radically different, the business behavior exhibited by users of the old and new interfaces (when considered in terms of a usage scenario) must remain the same. a redesigned interface must still allow a user to exhibit the appropriate business behavior. for example, when a database query is to be made, the old interface may require a long series of text-based commands to specify the query. the reengineered gui may streamline the query to a small sequence of mouse picks, but the intent and content of the query remain unchanged.
3. introduce improvements that make the mode of interaction more efficient. the ergonomic failings of the existing interface are studied and corrected in the design of the new gui.
4. build and integrate the new gui. the existence of class libraries and fourth generation tools can reduce the effort required to build the gui significantly. however, integration with existing application software can be more time consuming. care must be taken to ensure that the gui does not propagate adverse side effects into the remainder of the application.
30.6 the economics of reengineering
? in a perfect world, every unmaintainable program would be retired immediately, to be replaced by high-quality, reengineered applications developed using modern software engineering practices. but we live in a world of limited resources.
? reengineering drains resources that can be used for other business purposes. therefore, before an organization attempts to reengineer an existing application, it should perform a cost/benefit analysis.
? a cost/benefit analysis model for reengineering has been proposed by sneed. nine parameters are defined:
p1 = current annual maintenance cost for an application.
p2 = current annual operation cost for an application.
p3 = current annual business value of an application.
p4 = predicted annual maintenance cost after reengineering.
p5 = predicted annual operations cost after reengineering.
p6 = predicted annual business value after reengineering.
p7 = estimated reengineering costs.
p8 = estimated reengineering calendar time.
p9 = reengineering risk factor (p9 = 1.0 is nominal).
l = expected life of the system.
? the cost associated with continuing maintenance of a candidate application (i.e., reengineering is not performed) can be defined as
cmaint = [p3 - (p1 + p2)] x l (30-1)
? the costs associated with reengineering are defined using the following relationship:
creeng = [p6 - (p4 + p5) x (l - p8) - (p7 x p9)] (30-2)
? using the costs presented in equations (30-1) and (30-2), the overall benefit of reengineering can be computed as
cost benefit = creeng - cmaint (30-3)
? the cost/benefit analysis presented in the equations can be performed for all high priority applications identified during inventory analysis (section 30.2.2).
? those applications that show the highest cost/benefit can be targeted for reengineering, while work on others can be postponed until resources are available.

references:
1.” software engineering practitioners approach “8th by pressman.