Software Reengineering

Slides:



Advertisements
Similar presentations
Software Re-engineering
Advertisements

Software Re-engineering
CIS 376 Bruce R. Maxim UM-Dearborn
Database Planning, Design, and Administration
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
SWE 316: Software Design and Architecture Objectives Lecture # 23 Software Reengineering SWE 316: Software Design and Architecture  To describe the activities.
SOFTWARE MAINTENANCE 24 March 2013 William W. McMillan.
Prentice Hall, Database Systems Week 1 Introduction By Zekrullah Popal.
CMMI – Continuous as well as staged model CMMI capability levels – Incomplete, performed, managed, defined, quantitatively managed, optimized Example.
Dr Gordon Russell, Napier University Unit Data Dictionary 1 Data Dictionary Unit 5.3.
Unified theory of software evolution Reengineering – Business process reengineering and software reengineering BPR model – Business definition, process.
Lecture 12 Reengineering Computer-aided Software Engineering Cleanroom Software Engineering.
Managing Data Resources
Software Configuration Management
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Software Evolution Managing the processes of software system change
Software Reengineering
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
CSEM01 SE Evolution & Management Anne Comer Helen Edwards
Software evolution.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Lecture Nine Database Planning, Design, and Administration
Driss Kettani Sommerville, 6th edition Software Engineering II Software re-engineering l Reorganising and modifying existing software systems to make them.
Course Instructor: Aisha Azeem
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Chapter 1: The Database Environment
Software Reengineering 2003 년 12 월 2 일 최창익, 고광 원.
Chapter 29 Maintenance and Reengineering
Software Re-engineering
Chapter 9 – Software Evolution and Maintenance
The chapter will address the following questions:
Software Evolution Planning CIS 376 Bruce R. Maxim UM-Dearborn.
Problems with reuse – Increased maintenance costs; lack of tool support; not-invented- here syndrome; creating, maintaining, and using a component library.
Database Systems: Design, Implementation, and Management Ninth Edition
Chapter 1 Database Systems. Good decisions require good information derived from raw facts Data is managed most efficiently when stored in a database.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Overview of the Database Development Process
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management Dave Salisbury ( )
CS 425/625 Software Engineering Legacy Systems
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
 Chapter 6 Architecture 1. What is Architecture?  Overall Structure of system  First Stage in Design process 2.
1 Minggu 9, Pertemuan 17 Database Planning, Design, and Administration Matakuliah: T0206-Sistem Basisdata Tahun: 2005 Versi: 1.0/0.0.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
1/26/2004TCSS545A Isabelle Bichindaritz1 Database Management Systems Design Methodology.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28Slide 1 CO7206 System Reengineering 4.2 Software Reengineering Most slides are Slides.
Chapter 5: Software Re-Engineering Omar Meqdadi SE 3860 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
HNDIT23082 Lecture 06:Software Maintenance. Reasons for changes Errors in the existing system Changes in requirements Technological advances Legislation.
Next week Tuesday Report on the project Demo of the working model. Today at the conclusion of lecture, class get together to figure out how you will present.
1 Software Maintenance The process of changing the system after it has been delivered and in operation Software change is inevitable –New requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
© SERG Reverse Engineering (Software Maintenance & Reengineering) Software Maintenance Managing the processes of system change.
Managing Data Resources File Organization and databases for business information systems.
CS223: Software Engineering Lecture 33: Software Maintenance.
Tempus Software Maintenance and Evolution JMSE-SM&E Unit 6: Reengineering and Maintenance in software cycle Prof. Mohammad A. Mikki Gaza, Palestine,
CS223: Software Engineering Lecture 34: Software Maintenance.
Software Configuration Management
Software Maintenance.
Software Maintenance
Business Process Reengineering
Chapter 8 Software Evolution.
Unit 5 15SE202 Software engineering Principles
Lecture 06:Software Maintenance
System Reengineering Restructuring or rewriting part or all of a system without changing its functionality Applicable when some (but not all) subsystems.
Software Re-engineering and Reverse Engineering
For University Use Only
Presentation transcript:

Software Reengineering CIS 376 Bruce R. Maxim UM-Dearborn

System Reengineering Restructuring or rewriting part or all of a system without changing its functionality Applicable when some (but not all) subsystems of a larger system require frequent maintenance Reengineering involves putting in the effort to make it easier to maintain The reengineered system may also be restructured and should be redocumented

When do you decide to reengineer? When system changes are confined to one subsystem, the subsystem needs to be reengineered When hardware or software support becomes obsolete When tools to support restructuring are readily available

Business Process Reengineering Concerned with redesigning business processes to make them more responsive and more efficient Often relies on the introduction of new computer systems to support the revised processes May force software reengineering of legacy computer systems which designed to support existing processes

Business Process Reengineering Principles - part 1 Organize around outcomes, not tasks. Have the people who use the output of a process, perform the process. Incorporate information processing work into the work that produces the raw information. Treat geographically dispersed resources as though they were centralized.

Business Process Reengineering Principles - part 2 Link parallel activities instead of integrating their results. Put the decision point where the work is performed and build control into the process. Capture the data once, at its source.

Business Process Reengineering Model - part 1 Business redefinition business goals identified in the context of key drivers cost reduction time reduction quality improvement empowerment Process identification processes critical to achieving business goals are identified and prioritized

Business Process Reengineering Model - part 2 Process evaluation existing processes are analyzed and measured process costs and time are noted quality/performance problems are isolated Process specification and design use-cases are prepared for each process to be redesigned (these use-case scenarios deliver some outcome to a customer) new tasks are designed for each process

Business Process Reengineering Model - part 3 Prototyping used to test processes before integrating them into the business Refinement and instantiation based on feedback from the prototype, business processes are refined refined processes then instantiated within a business system

Reengineering Process from Sommerville

Software Reengineering Process Model - part 1 Inventory analysis sorting active software applications by business criticality, longevity, current maintainability, and other local criteria helps to identify reengineering candidates Document restructuring options live with weak documentation update poor documents if they are used fully rewrite the documentation for critical systems focusing on the "essential minimum"

Software Reengineering Process Model - part 2 Reverse engineering process of design recovery analyzing a program in an effort to create a representation of the program at some abstraction level higher than source code Code restructuring source code is analyzed and violations of structured programming practices are noted and repaired revised code needs to be reviewed and tested

Software Reengineering Process Model - part 3 Data restructuring usually requires full reverse engineering current data architecture is dissected data models are defined existing data structures are reviewed for quality Forward engineering sometimes called reclamation or renovation recovers design information from existing source code uses this design information to reconstitute the existing system to improve its overall quality or performance

Forward Engineering and Reengineering from Sommerville

Reverse Engineering Analyzing software with a view to understanding its design and specification May be part of the reengineering process May be used to specify a system for prior to reimplementation Program understanding tools may be useful (browsers, cross-reference generators, etc.)

Reverse Engineering Concepts part 1 Abstraction level ideally want to be able to derive design information at the highest level possible Completeness level of detail provided at a given abstraction level Interactivity degree to which humans are integrated with automated reverse engineering tools

Reverse Engineering Concepts part 2 Directionality one-way means the software engineer doing the maintenance activity is given all information extracted from source code two-way means the information is fed to a reengineering tool that attempts to regenerate the old program Extract abstractions meaningful specification of processing performed is derived from old source code

Reverse Engineering Process from Sommerville

Reverse Engineering Activities part 1 Understanding process source code is analyzed to at varying levels of detail system program component pattern statement to understand procedural abstractions and overall functionality

Reverse Engineering Activities part 2 Understanding data internal data structures database structure User interfaces what are the basic actions (e.g. key strokes or mouse operations) processed by the interface? what is a compact description of the system's behavioral response to these actions? what concept of equivalence of interfaces is relevant?

Reverse Engineering Applicability Reverse engineering often precedes reengineering Sometimes reverse engineering is preferred if the specification and design of a system needs to be defined prior using them as input to the requirements specification process for a replacement systems if the design and specification for a system is needed to support program maintenance activities

Data Abstraction Recovery Many legacy systems make use of shared tables and global data structures to save space Results in tightly coupled systems that are very hard to change Shared data structures need to be transformed to objects or ADT’s

Creating ADT’s and Objects Analyze the data common areas to identify logical abstractions Create ADT’s or Objects for each abstraction Provide functions or methods to update each field in the data abstraction Use a program browser to find all references to these data structures and replace them with the new function or method calls

Sommerville’s Restructuring Approaches

Restructuring Benefits Improved program and documentation quality Makes programs easier to learn improves productivity reduces developer frustration Reduces effort required to maintain software Software is easier to test and debug

Types of Restructuring - part 1 Code restructuring program logic modeled using Boolean algebra and series of transformation rules are applied to yield restructured logic create resource exchange diagram showing data types procedures variables shared between modules restructure program architecture to minimize module coupling

Types of Restructuring - part 2 Data restructuring analysis of source code data redesign data record standardization data name rationalization file or database translation

Automatic Program Restructuring from Sommerville

Automatic Restructuring Problems Loss of source code comments Loss of documentation Heavy computational demands Will not help with poor modularization problems (e.g. related components widely dispersed throughout the source code) The understandability of data driven programs may not be improved by restructuring

Source Code Translation Involves converting the code from one language (or language version) to another May be necessary because of hardware platform updates staff skill shortages organizational policy changes May only be realistic (e.g. cost and time effective) if an automatic translator is available Manual fine tuning of new code is always required

Program Translation Process from Sommerville

Data Reengineering Involves analyzing and reorganizing data structures or data values used in a program Might be part of the process of migrating from a file-based system to a DBMS or changing from one DBMS to another DBMS The goal to create an environment where is managed not just used

Data Rengineering Approaches - part 1 Data cleanup data records and values are analyzed to improve quality duplicates removed redundant information is deleted consistent format applied to all records normally does not require and program changes

Data Reengineering Approaches - part 2 Data extension data and programs are reengineered to remove data processing limits (e.g. size or field widths) data itself may need to rewritten to reflect program changes Data migration data is moved to modern DBMS data might be stored in separate files or an older DBMS

Data Problems Data naming problems Field length problems names be hard to understand heavy use of aliasing by programmers Field length problems different field lengths used for same data item in different programs Record organization problems different field orderings used by different programs Hard-coded literals No data dictionary

Data Value Inconsistencies Inconsistent default values used in different programs (e.g. especially missing data codes) Inconsistent units used for same quantity (e.g. miles in one program kilometers in another) Inconsistent validation rules (e.g. different standards used to reject values as bad) Inconsistent representation semantics (e.g. multiple ways of using uppercase to convey meaning in text strings) Inconsistent handling of negative numbers (e.g. data validation and representation issues)

Data Reengineering Process from Sommerville

Forward Engineering Client/Server Architectures application functionality migrates to each client computer new GUI interfaces implemented at client sites database functions allocated to servers specialized functionality may remain at server site new communications, security, archiving, and control requirements must be established at both client and server sites

Forward Engineering Object-Oriented Architectures - part 1 existing software is reverse engineered so that appropriate data, functional, and behavioral models can be created use-cases are created if reengineered system extends functionality of application data models created during reverse engineering are used with CRC modeling as a basis to define classes

Forward Engineering Object-Oriented Architectures - part 2 create class hierarchies, object-relationship models, object-behavior models and begin object-oriented design a component-based process model may be used if a robust component library already exists where components must be built from scratch, it may be possible to reuse algorithms and data structures from the original application

Forward Engineering User Interfaces understand the original user interface and how the data moves between the user interface and the remainder of the application remodel the behavior implied by the existing user interface into a series of abstractions that have meaning in the context of a GUI introduce improvements that make the mode of interaction more efficient build and integrate the new GUI

Economics of Reengineering Cost of maintenance = cost annual of operation and maintenance over application lifetime Cost of reengineering = predicted return on investment reduced by cost of implementing changes and engineering risk factors Cost benefit = Cost of reengineering - Cost of maintenance