Software Engineering and Architecture

Activity needed when trying to re-structure a legacy system. In other words, systems that are still valuable, but are difficult to maintain.

Aims at producing a new system that is more evolvable.

• Corrective - errors need to be fixed
• Preventive - prevent problems in the future
• Adaptive - something has changed in the future (fix design issues)
• Adaptive - something has changed in the environment
• Perfective - improve system qualities e.g. performance

"Programs, like people, get old. We can't prevent aging, but we can understand its causes, take steps to limit its effescts, temprarily reverse some of the damage it has caused, and prepare for the day then the software is no longer viable."

Thus changing software is inevitable!

• Lack of movement
  • Caused by the failure of the product's owners to modify it to meet changing needs
  • Unless software is frequently updated, its users will become dissatisfied and they will change to a new product as soon as the benefits outweigh the costs of retraining and converting
• Ignorant Surgery
  • Caused by the changes that are made to software
  • Changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade
  • Software that has been repeatedly modified in this way becomes very expensive to update

The symptoms of software aging mirror those of human aging:

• Owners of aging software find it incresingliy hard to keep up with the market and lose customers to newer products
• Aging software often degrades in its performance as a result of a gradually deteriorating structure
• Aging software often becomes 'buggy' becuase of errors introduced when changes are made

• Preventive medicine
  • What can we do to delay the decay and limit its effects?
  • Design for change
  • Code for change
  • Keep reors - documentation
  • Second opinion - reviews
• Software geriatrics
  • What can we do to treat software aging that has already occurred?
  • Stopping the deterioration (Verschlechterung)
  • Retroactive (rückwirkende) documentation
  • Retroactive invremental modularization
  • Amputation
  • Major surgery - restructuring

• Maintenance: The activities of changing the system after it has been delivered
• Evolution: The process of continuous software change from the very beginning
  • Development activites + Maintenance activities + Reengineeering activities

• Organizations have huge investments in their software systems - they are critical business assets
• to maintain the value of these assets to the business, they must be changed and updated
• The majority of the software udget in large companies is devoted to evolving existing software rather than developing new software
• Studies indicate that up to 75% of all software professionals are involved in some form of maintenance/evolution activity

• Proposes a theoretical model to reason aout software systems and their interaction with the socio-economic environment
• Maintenance is costly, but maintenance is not only about bug fixing!
• Propose a classification of software: S-Programs, P-Programs and E-Programs
• Condusts quantitative studies on large scale industial projects (collect metrics)
• Derives 'Laws of Evolution' that are generally applicable

• S-Programs: Programs that can be completely and formally specified
  • e.g. program that sorts an arry
• P-Programs: Programs that can be completely specified, but which makes an approximation of the real world
  • e.g. a program that plays chess against a human player
• E-Programs: Programs that mechanize a human or scietal activity. The program becomes a part of the world it models
  • e.g. an ERP system

1. Continuing Change
   A Program that is used and that  as an implementation of its specification reflects some other reality, undergoes continual change or becomes progressively less useful. The change or Decay process contunues until it is judged more coste effective to replace the system with a recreted version.
   1. Software systems have to evolve, otherwise they gradually become useless
2. Increasing Complexity
   As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it
   1. If you dont take specific actions, software will become more complex and more difficult to adapt.
3. The Fundamental Law of Program Evolution
   Program evolution is subject to a dynamics which makes the programming porcess, and hence measures of global project an system attributes, self-ragulating with statistically determinable trends and invariances
4. Conservations of Organizational Stability
   During the active life of a program the global activity rate in a programming project is statistically invariant
5. Conservation of Familiarity
   During the active life of a program the release content (changes, additions, deletions) of the successive releases of an evolving program is statistically invariant

• Research Challenge: Find ways of developing software, so that it can be changed more easily and reliably in subsequent phases
• Two key outcomes of this phase:
  • Architecture an
  • Team Knowledge

• Goal: Implement possibly major changes without being able a priori to predict how user requirements will evolve
• Research challenge: program comprehension: We need tools to understand the impact of changes, to display the program strucure, to do regression testing. We also need tools for configuration management and version control of large distributed systems
• Management issue: keep original architects and designers in the team - or risk to move into the servicing stage quickly

• Goal: implement tactical changes, at minimum cost
• Big change in terms of project management: only minor corrections/enhancements should be done, senior staff member are no longer required, accurate cost prediction is needed. It is possible to outsource the servicing (how do we define SLAs?)
• Reserach Challenge: program comprehension. we need tools to understand the impact of changes, to display the program structure, to do regression testing. We also need tools for configuration management and version control of large distributed systems.

• If we talk about software evolution, we also talk about legacy systems
• Legacy systems: Old computer-based systems, ehich are still in use by organizations
  • Many of them still business critical
  • Incorporate many changes made over the years
  • many people have been involved in these changes
  • Replacing legacy systems with new systems is resky, yet keeping them means new changes become more and more expensive

--> THEY HAVE TO BE MAINTAINED

Reverse engineering and

Reengineering

• Hardware - may be obsolete mainframe hardware
• Support software - may rely on support software from suppliers who are no longer in business
• Applicatoin software - may be written in obsolete programming languages
• Applicatoin data - often incomplete and inconsistent
• Business processes - may be contrained by software structure and functionality
• Business policies and rules - may be implicit and embedded in the system software

• Risks of replacing
  • Specification is difficult because ecisting documentation is typically incomplete
  • changing business processes may entail high costss
  • Undocumented, yet importand business rules may be embedded in the system; a new system may break these rules
  • The new system may be delivered late, may cost more than expected, and may not function properly

• In large systems, different parts were implemented by different teams, without consistent programming style
• It is difficult to find personnel who knows the obsolete programming languages used in old systems
• In many cases the only documentation is provided by the source code; even this may be missing
• It is difficult to understand the system given its ad hoc updating over the years
• Data used b the system is diffficult to understand and manipulate; it can also be obsolete and/or redundant

Traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical iimplementation of a system.

• Program comprehension: Understand the existing program in order to change it
• Change impact analysis: Identification of the parts of the system that will be affected by a proposed change
• Change propagation: Making sure that all affected parts are changed correctly
• Restructuring/Refactoring: Improving the software structure or architecture without changing the behavior
• Regression testing: Efficiently verifying that the change preserved the behavior of functionalities that should not be impacted
• Program transformation: One or multiple modifications applied to a program

• Typical Methods
  • Source code analysis
  • Metrics
  • Visualizatoin tools
  • Runtime analysis
  • Design and architecture analysis
• Tools
  • Sotograph
  • Metric
  • Checkstyle
  • CodeCrawler
  • Sonar

• Activity by which the programmers asses the extent of a change, i.e., the compnents that will be impacted by the change
• Change impact analysis indicates how costly the change is going to be and whether it is to be undertaken at all

• Translations
  • Where the source and target language are defferent
  • Program Migration, Reverse Engineering, ...
• Reprasings
  • Whre the source and target language are the same
  • Reengineering, Refactoring, ...

• Engineering
  • Constant control quality of on-going work
• Legacy Code / Re-Engineering
  • Determine quality of given work

Code

Design and

Architecture

• Provide concrete figures about software qualitiy
  • Metric Numbers
• Provide graphical view on software quality
  • Visualization

• Size Metrics
  • Lines of Code (LoC), Number of Classes, Number of Methods of Classes, Halstead-Metric
• Logical Structure Metrics
  • Cycomaltic Complexity McCabe
• Data Structure Metrics
  • Number of Variables, Duration
• Style Metrics
  • Naming Convention, Nesting
• Metrics fr Cohesion and Coupling -> High Cohesion can result in bad coupling
  • Fan-In, Fan-Out, Lack-of-Cohesion, Number of called methods

• Current (typically static) code analysis gives informatin about the current state
• Time analysis provides information about the system evolved over time