© keith vander linden, 2011 1 dilbert © united feature syndicate, inc

© Keith Vander Linden, 2011

2

Software Evolution

● The Transition Phase● The show hits the road:

– Deployment– Maintenance– Re-engineering

● A final word…

An airplane is nothing more than a collection of parts having an inherent tendency to fall to earth, and requiring constant effort and supervision to stave off that outcome. – K. Gorlen UNIX System V


3

The Transition Phase

● In the UP transition phase, the system is transferred to the user community.

● It’s activities include:– Deployment– Technical support and training– Maintenance

● Software Systems evolve over time.


4

Analysis7% Design

6%

Implementation13%

Testing7%Maintenance

67%

Relative Effort: Phases

data from Schach, 2002


5

System Deployment

● Deployment is not the end of the road.– Packaging/distribution– Installation

● Systems are deployed as an architecture of physical devices and software environments.


6

Deployment Diagrams

● Their physical architectures have the following elements:– Physical devices– Software execution environments– Software artifacts– Communication lines

● UML Deployment Diagrams can be used to communicate these architectures.


7

Example: Deployment Diagram

Example adapted from Fowler, 2003

GenericPC<<client>>

DatabaseServer<<server>>

Web Server<<server>>

apache<<webserver>>

tomcat<<container>>

geekServlet<<artifact>>

Postgres<<dbms>>

geekDB<<artifact>>

JDBC

Chrome<<browser>> HTTP


8

Outline

● Deployment Diagrams– Nodes– Artifacts– Associations

● Using Deployment Diagrams


9

Nodes

● Deployment diagram nodes can represent:– Physical devices– Software execution environments

● These stereotypes are helpful, but are not standardized. Web Server

<<server>>

apache<<webserver>>

tomcat<<container>>

geekServlet<<artifact>>


10

Artifacts

● Artifacts are the physical manifestations of software components.

● They are stored on/in nodes.

geekDB<<artifact>>


11

Assocations

● Associations represent communication paths and protocols.

apache<<webserver>>

Chrome<<browser>> HTTP


12

Using Deployment Diagrams

● Use deployment diagrams to show:– what is deployed where;– how the communication flows.

● Any non-trivial deployment can benefit from their use.


13

Legacy Systems

● Systems can eventually become legacy systems.

● Legacy systems:– are entrenched;– have ceased to evolve;– continue to be used because their

replacement cost is too high.


14

System Maintenance

● Maintenance sustains a software system throughout its life-cycle.

● Software deteriorates as it evolves.● Reasons for post-delivery modification:

– Corrective maintenance

– Perfective maintenance

– Adaptive maintenance


15

Relative Effort: Maintenance Types

data from: Schach et al, 2003

Corrective57%

Perfective39%

Adaptive2%

other2%


16

The Joy of Maintenance

● Maintenance is seen as– an after-the-fact activity– unrelated to the software development

● Problems:– Users are usually dissatisfied.

– Problems are frequently caused by someone else.

– You’re on the bottom rung of the life-cycle food-chain.

– There are limited support tools.


17

Change Management Tools

● Managing defects

● Fixing defects

● Testing fixes


18

Regression Testing

re·gres·sion (re -greh shun) n. Relapse to a less perfect or developed state.

● Changing software tends to break things.● Regression testing checks that the system

still operates properly after change.


19

Engineering for Evolution● Good software engineering should

anticipate evolution.● Silver bullets?

– “Heavy” software engineering?

– Object-Oriented design?

– Agile development?


20

Re-Engineering

● Re-implementing an existing system, with minimal analysis and design, e.g.:– Re-documenting a system– Re-structuring a system– Translating a system code to a newer

language– Porting a system to a new platform

● This can be cheaper than developing a new system or fixing an old one.


21

Reasons to Re-Engineer

● To support a more modern platform● To move to a better supported language● To improve efficiency● To make the system more understandable

in order to support maintenance


22

Types of Re-Engineering

Cheap Expensive

Automated Code conversion

Manual architectural restructuring

Automated Program restructuring

Manual program/data restructuring

from: Sommerville, 2001


23

Reverse Engineering

● The process of deriving abstract formal specifications from the source code of a legacy system

● This is used to support:– System re-engineering– System replacement


24

image from: http://www.unc.edu/

Fredrick P. Brooks (1931- )

The Mythical Man-Month

● Brooks considered evolution to be one of the essential characteristics of software systems.

● He gives the following advice to young managers:

Numquam incertus; semper apertus

What’s theBig Idea

© keith vander linden, 2011 1 dilbert © united feature syndicate, inc

Documents

keith vander linden

system deployment deployment

system maintenance maintenance

joy of maintenance maintenance

nodes deployment diagram

software environments

deployment diagram example

deployment technical