Advance topics in SE

Re- Engineering
• Reorganising and modifying existing software
systems to make them more maintainable
• Reengineering is the fundamental rethinking
and redesign of business processes to achieve
dramatic improvements in critical,
contemporary measures of performance, such
as cost, quality, service and speed.
(Hammer & Champy, 1993)
• Re-structuring or re-writing part or all of a
legacy system without changing its
functionality
• Applicable where some but not all sub-systems
of a larger system require frequent
maintenance
• Re-engineering involves adding effort to make
them easier to maintain. The system may be re-
structured and re-documented
• Forward Engineering is different from
reengineering
 Why Re-engineering
• Customers
– Demanding
– Sophistication
– Changing Needs
• When system changes are mostly confined to
part of the system then re-engineer that part
• When hardware or software support becomes
obsolete
• When tools to support re-structuring are
available
• Competition
– Local
– Global
 Why resistance in re-engineering?
• Complacency

• Political Resistance

• New Developments

• Fear of Unknown and Failure

 advantages
• Reduced risk
– There is a high risk in new software development.
There may be development problems, staffing
problems and specification problems
• Reduced cost
– The cost of re-engineering is often significantly
less than the costs of developing new software
 Business process Re-engineering
• Concerned with re-designing business
A group of logically related tasks that use the firm's resources to provide customer-oriented
processes to make them more responsive and
results in support of the organization's objectives

more efficient
• Often reliant on the introduction of new
computer systems to support the revised
processes
• May force software re-engineering as the
legacy systems are designed to support
existing processes
 Program Modularised Original data
Original
documentation program
program

Reverse
engineering
Data
Source code Program reengineering
translation modularisation

Program
structure
improvement
Structured Reengineered
program data
 Reverse Engineering
• Analysing software with a view to understanding
its design and specification
• May be part of a re-engineering process but may
also be used to re-specify a system for re-
implementation
• Builds a program data base and generates
information from this
• Program understanding tools (browsers, cross-
reference generators, etc.) may be used in this
process
 Reverse Engineering
• “Reverse engineering” term derived from
hardware development
– the process of discovering of how competitor’s system
worked.
– in software engineering,
• it is the process of discovering how your own system works.

• Software systems become difficult to understand

and maintain since over time their size and
complexity has had a continuous evolution.

10
 Reverse Engineering

• Reverse engineering is usually applied to large

legacy systems:
– to make them easier to understand and maintain
– to increase the potential for continued evolution.

• Often, the most fundamental reverse engineering

reason is:
– structural re-documentation.
• the structure of the system is derived with some of the design
architecture recaptured.

11
 Reverse Engineering Terminology
• Design recovery
– is a subset of reverse engineering in which domain knowledge,
external information, and deduction or fuzzy reasoning are added to
the observations of the subject system to identify meaningful higher
level abstractions. Design recovery recreates design abstractions from
a combination of code, existing design documentation (if available),
personal experience, and general knowledge about problem and
application domains.

• Redocumentation
– is the creation or revision of a semantically equivalent representation
within the same relative abstraction level.. Redocumentation is the
simplest and oldest form of reverse engineering, and can be
considered to be an unintrusive, weak form of restructuring.

12
 Reverse Engineering
• forward and reverse engineering can be
illustrated as:
Specifications Specifications

Design Design

Code Code

Behavior Behavior

Forward Reverse
Engineering Engineering

13
 Reverse Engineering
Two distinct phases
1. identify the system’s components and any
dependencies among them

2. a discovery phase which tends to be highly

interactive and may involve:
• constructing the hierarchical subsystem components based
on cohesion and coupling principles,
• the reconstruction of design and requirements
specifications providing a ‘domain model’ and
• the matching of the model to the code.

14
 Reverse Engineering

• Reverse engineering tends to be influenced

heavily by the amount of domain
knowledge available:
– limits the degree of automation that is possible
– limits the level of abstraction obtained.

• The uncovering of entities allows them to

be classified and to determine shared
properties and relationship attributes.
15
 Reverse Engineering
• The concepts of aggregation can be applied to
determine the part-of relationship between a
composite and its constituents.

• Generalization and specialization allows an

element to be related to a more general or
specific element.

• Possible to apply grouping to form a set of

elements and their necessary relationships to
form a context.
16
 Reverse Engineering
• various activities are performed during
reverse engineering:

– gathering (identifying) the software artifacts

usually obtained from:
• specification/design documents,
• the code,
• any related documentation,
• application knowledge and
• syntactic pattern matching to identify program
(functional) ‘units’.

17
 Reverse Engineering

– creating the repository of information:

• filter out immaterial information while selecting
relevant information.

– construct the abstraction layers at:

• the structural,
• functional and
• application levels.
– May need to perform semantic and behavioral matching
during this process.

18
 Reverse Engineering
• the software system can be reasoned about in
may different views:

– structural view: the basis is from structure charts, call

graphs (unit interaction), module and subsystem
graphs, various metrics and organizational views [many
can be constructed with CASE tools].
– functional view: usually can be obtained from the
design, specification and requirements documents.
– behavioral views: conceptual, temporal, process,
domain and user interactive views.

19
 Web Engineering
• Web engineering is the application of systematic
and quantifiable approaches (concepts,
methods, techniques, tools) to cost-effective
requirements analysis, design, implementation,
testing, operation, and maintenance of high-
quality Web applications.
• Web engineering is also the scientific discipline
concerned with the study of these approaches
 Categories of Web applications
Document Centric
• Static Homepage
• Web-Radio
• Company Web Site
Interactive
• Virtual Exhibition
• News Site
• Travel Planning
Transactional
• Online Banking
• Online Shopping
• Booking System
Workflow-based (Service providers)
• E-Government
• B2B Solution
• Patient Workflow
Collaborativ
Collaborative
• Chatroom
• E-Learning Platform
• Virtual Shared Workspace
Portal-oriented
• Community Portal
• Online Shopping Mall
• Business Portal
Search Application
Web Application Quality Attributes
• Usability
• Functionality
– Searching
– Retrieving
– Navigating
– Browsing
– Domain Oriented Features
– Efficiency