\documentclass{report}

\usepackage[hmargin=1in,vmargin=1in]{geometry}
\usepackage{natbib}
\usepackage{hyperref}
\usepackage{graphicx}
\usepackage{listings}

\begin{document}

\section*{Supplementary Notes for Software Reengineering - July 8, 2011}
Note that these add to the material presented in the lecture slides. \textbf{There will be exam question(s) on this topic!} \\

\noindent Most of our courses have focused on building new software. However, this is costly.

\subsection*{Importance of Software Change}
Another example:
\begin{itemize}
\item Change in environment
	\begin{itemize}
	\item There is an ongoing relationship with a customer. A customer may request a change. Such a change may be expected or unexpected (a change in requirement).
	\end{itemize}
\end{itemize}
\emph{As a software engineer, you have to be prepared for any types of change.}

 \subsection*{Interpreter\footnote{This is somebody's solution from last year. It is missing composition.}/Visitor Example}
If you want to make the Interpreter design printer friendly, you have to change \textbf{7} classes, and then recompile the code and run test cases.\\
For the Visitor design, not as many classes need to change. \\


\noindent\emph{The person who knows the code knows what parts need to change.}

\subsection*{The Problem of Fitness for Future}
A clear decision needs to be made about changes that will happen in the future.

\subsection*{Testing the Change}
After increasing functionality (or refactoring!!!), old functionality should not be broken.

\subsection*{Reasons for Software Change}
\begin{itemize}
\item Corrective
	\begin{itemize}
	\item Fix a bug (There is a change request in a bug repository!)
	\end{itemize}
\item Adaptive
	\begin{itemize}
	\item Due to new hardware or software requirements
	\item Internationalization and localization\footnote{\url{http://en.wikipedia.org/wiki/Internationalisation_and_localisation}}
	\item Need to port to another technology or platform
	\item Changing the user interface
	\end{itemize}
\item Perfective
	\begin{itemize}
	\item Perfecting the software
	\item Adding new features
	\item Addressing non-functional requirements, such as better response time
	\end{itemize}
\item Preventive
	\begin{itemize}
	\item To reduce the cost of changes in the future
	\end{itemize}
\end{itemize}
\emph{Sometimes you have to pay lots of money to fix a bug that you could have fixed earlier.}

\subsection*{Distribution of Maintanance Activities}
Ideally, in software engineering, if you increase preventive changes by a small amount, you will expect a lot of decrease in the other types of change that you need. Goal is to ultimately reduce all types of changes by making higher quality software.

\subsection*{How to Reduce Maintenance Changes}
\begin{itemize}
\item Make less bugs!
\item Anticipate future changes (Like we did with Interpreter/Visitor)
	\begin{itemize}
	\item There is always a trade-off between software that is ready to change and software that is robust, but difficult to change. Make the design a bit more complex, and it becomes harder to maintain.
	\end{itemize}
\item Better tuning to user needs
\item Regularly perform preventitive maintaince. You finish coding, check:
	\begin{itemize}
	\item Do the comments need updating?
	\item Does anything smell?
	\end{itemize}
\item Write less code!
	\begin{itemize}
	\item It is not always the case that less code means less maintanence. If you are trying to minimize code, you'll make it harder to read. There is less code in the end, but all the functionality is squished together. \textbf{This is especially difficult if it's someone else's code} and you have to maintain it. Lines of code is the best correlated metric for complexity, but this is for general software and not always true.
	\end{itemize}
\end{itemize}

\noindent\fbox{\parbox{6.5in}{\textbf{Derek's sidenote:} What was the case study that we did on this? seL4! Because it was small, it was portable. However, it does have issues of high coupling. There are only 10000 lines of code, but they are all interrelated. It is difficult to change one without worrying about the others.}}

\subsection*{Lehman\cite{lehman}}
Lemman is the father of software evolution and maintenance.
\begin{itemize}
\item Law 1: Software Change is inevitable
	\begin{itemize}
	\item Can't create software and say that you're not going to change it.
	\end{itemize}
\item Law 2: As software changes, it becomes more complex
\end{itemize}
\noindent\fbox{\parbox{6.5in}{\textbf{Derek's sidenote:} What would an agile programmer have to say to this? The agile programming movement takes the opposite direction. Normally, you start with a pristine design which then undergoes architectural drift and gets messy. In agile programming, you throw something together, then refactor. \\

From that point of view, software doesn't become more complex. It becomes cleaner, because you have active preventive maintenance.}}

\begin{itemize}
\item Law 3: Self-Regulation
	\begin{itemize}
	\item If you can model the change process in software, can you predict the changes? If you can, why is it good or bad? How can you take advantage of that?
	\item You should be able to do this because you can always see the trend of software development - what kinds of things people would want.
	\item \textbf{Mining Software Repositories} Go to a CVS/SVN repository and try to identify a thread of change and come up with predictions regarding whether there will be change. If a company wants to 
		release a software, they can use this prediction. Release sooner and take control of the market. Release later and have more stable code, but earn less money. Can you predict whether patches will have to be made soon? To do this, use
		\begin{itemize}
		\item Experience from developers
		\item Previous releases
		\item Users
		\end{itemize}
	\end{itemize}
\item Law 4: Conservation of Organizational Stability
	\begin{itemize}
	\item Regardless of the life time of the project, you will need the same amount of resources for the maintenance part.
	\end{itemize}
\item Law 5: Conservation of Familiarity
	\begin{itemize}
	\item The average complexity of a change stays the same throughout the course of a project.
	\item Without a familiarity of how and why the system was designed in the way it was, it becomes very difficult to implement changes to it without compromising the ability to understand it.
	\end{itemize}
\item Law 6: Continuing Growth
	\begin{itemize}
	\item Size is always increasing. (As an example, the size of the Linux kernel has grown exponentially.)
	\end{itemize}
\item Law 7: Declining Quality
	\begin{itemize}
	\item There is quality and feature set perceived by the user, and quality perceived by the developer (spaghetti-like).
	\end{itemize}
\end{itemize}
\noindent\fbox{\parbox{6.5in}{\textbf{Derek's sidenote:} At a PhD defence Derek went to, the guy analyzed vim, make, emacs, gcc and looked at global variable usage. At 6.0 and 7.0, use of globals goes down. Towards 6.5 and 7.5, it goes up due to bug fixes and hacking. At 7.0, it goes down again as new features are added and bugs are fixed.}}
\begin{itemize}
\item Law 8: Evolution processes are feedback systems
	\begin{itemize}
	\item Make a change, look at its behaviour, then look at the change again - Refining!
	\end{itemize}
\end{itemize}

\subsection*{Laws in a Nutshell}
\begin{itemize}
\item Code decay
	\begin{itemize}
	\item What's an exception to this? TeX. The version numbers of TeX approximate $\pi$. For any new improvement, a new digit is added. Developers of TeX have a clear vision. LaTeX evolves other packages on top of TeX. TeX stays the same as Knuth wrote it. metapost (font generation) does the same. Its version numbers approximate $e$.
	\end{itemize}
\item Code ageing
	\begin{itemize}
	\item The code becomes harder to change until you can't handle it. Then, you restart from scratch.
	\end{itemize}
\end{itemize}

\subsection*{What are the sources of complexity in software?}
\begin{itemize}
\item Coupling - communication complexity, channel complexity, interfaces. A piece of software may look easy, but it is communicating with many other modules, or works concurrently, or has real-time constraints.
\item If you want to reuse one piece of software, you will increase another type of complexity. There is a trade-off.
\end{itemize}

\subsection*{What makes code hard to maintain?}
\begin{itemize}
\item Insufficient Domain Knowledge
	\begin{itemize}
	\item For example, if the code is written using the visitor design pattern, but the maintainer isn't familiar with the pattern. He will break it and then won't know how to adjust it.
	\end{itemize}
\item Insufficient and out of sync documentation
	\begin{itemize}
	\item The worst thing is out of sync comments. This leads to difficulties finding bugs.
	\item Use precise namings. Lots of companies have audit testing to check a set of conventions. They don't accept code that breaks it.
	\end{itemize}
\end{itemize}

\emph{Everyone can write source code, but not everyone can make good software. The difference is quality - how maintainable it is.}

\subsection*{Which steps of reengineering are automated by software tools?}
\begin{itemize}
\item Forward Engineering (Design to Implementation)
	\begin{itemize}
	\item Model Driven Engineering tries to do this.
	\item Is source code a model? No! The model is more abstact, but one can argue that source code is more abstract. Which is it?
	\item In the early days, they tried to make machine code and come up with a language for it. Now they try to make things more abstract. Model is a relative term.
	\item There are tools to help with this process, including Eclipse, Visual Studio, testing tools, etc.
	\end{itemize}
\item Reengineering
	\begin{itemize}
	\item There are tools to do refactoring (i.e. Eclipse can quickly rename variables or methods)
	\item One of the hardest parts of reengineering is going from design to requirements. This is hard to generate, because you have to comprehend the software.
	\end{itemize}
\end{itemize}

\subsection*{Code Smells}
These are like a global variable. Global variables are usually bad. However, if one really helps you (like stdin in C), why not use it? In big companies, you need to justify your reasoning.
\begin{itemize}
\item Duplicate code
	\begin{itemize}
	\item As an example, you might do a lot of copying and pasting - code cloning. Finally, when you need to change the code that you copied, you have to change it everywhere you copied it.
	\end{itemize}
\item Long Method
	\begin{itemize}
	\item Example: An 800 LoC method named \emph{do\_it}
	\item Long methods are harder to read and understand, especially if not properly commented. Method names give meaning.
	\item More than one functionality in one method is bad. One reason is its harder to test it (control flow testing).
	\end{itemize}
\item Data Class
	\begin{itemize}
	\item A class that only has persistent data, but not methods.
	\item This is sometimes inevitable, but you should be aware that this may be bad.
	\end{itemize}
\item Solution Sprawl
	\begin{itemize}
	\item If you need to change something, you need to go to many parts of the code to do it.
	\end{itemize}
\item Long Parameter List
	\begin{itemize}
	\item Similar to long method - difficult to test.
	\end{itemize}
\item Data Clumps
	\begin{itemize}
	\item Data types that usually appear together to define a new data structure.
	\end{itemize}
\item Shotgun Surgery
	\begin{itemize}
	\item A shotgun bullet makes damage that is not localized. If you have a bug, you need to fix it in many places.
	\end{itemize}
\end{itemize}

\subsection*{Indicators of System Decay}
\begin{itemize}
\item Different Technologies
	\begin{itemize}
	\item This is when you glue different parts together. If they provide different features, that's fine. However, if you use Java and one part is in Swing and the other in SWT, that's not fine. To maintain this, you need people that are familiar with both. However, an example of where it is fine is a computer game that can be run in OpenGL and DirectX.
	\end{itemize}
\end{itemize}

\subsection*{Sample Exam Questions}

\begin{enumerate}
\item Your customer has asked you to make your chess playing software be able to play checkers. What type of maintenance does this change entail?
\item Operating System Y is becoming really popular. You decide that you need to port your software to Operating System Y. What type of maintenance does this change entail?
\item What is a good reason for doing preventive maintenance early?
\item You wish to predict whether you should release your software now, or wait until later. What would you look at?
	\begin{enumerate}
	\item Previous releases
	\item User opinion
	\item Developer opinion
	\item All of the above
	\end{enumerate}
\item Name all the things are wrong with the following code:
\begin{lstlisting}
/**
 * Method that does it all with just 3 variables.
 * @param a one variable that you need
 * @param b another variable that you need
 * @param z last variable that you need
 */
int do_it(int a, int b, int c, int d, int e, int f, int g, int h, int i) {
	someMethod(a, b);
	anotherMethod(a, b);
	int result = lastMethod(a + b);

	someMethod(c, d);
	anotherMethod(c, d);
	int result2 = lastMethod(c + d);

	someMethod(e, f);
	anotherMethod(e, f);
	int result3 = lastMethod(e + f);

	... CUT 100 more lines ...

	switch(someVariable) {
		case A:
			some code
			break;
		case B:
			some code
			break;
		case C:
			some code
			break;
		case D:
			some code
			break;
		case E:
			some code
			break;

	... CUT 100 more lines ...

		case CFZ:
			some code
			break;
		case CGA:
			some code
			break;
		case CGB:
			some code
			break;
	}

	... CUT 100 more lines ...

	if(aa) {
		if(bb) {
			if(cc && dd && !ee || ff) {
				do();
			} else if(ff && !cc) {
				if(hh) {
					doA();
				} else if(!ss) {
					doB();
				} else {
					doC();
				}
			} else {
				if(gg && cc) {
					doD();
				}
			}
		}
	} else if(!bb) {
		if(gg && cc) {
			doE();
		} else if(ff) {
			doF();
		}
	}

	... CUT 3000 more lines ...
	
	return result1000;
}
\end{lstlisting}

\item Name and explain 2 laws of software evolution.
\item Switch statement best belongs to which group of code smells?
	\begin{enumerate}
	\item The Bloaters
	\item The Object-Orientation Abusers
	\item The Change Preventers
	\item The Dispensables
	\item The Couplers
	\end{enumerate}
\item Data class best belongs to which group of code smells?
	\begin{enumerate}
	\item The Bloaters
	\item The Object-Orientation Abusers
	\item The Change Preventers
	\item The Dispensables
	\item The Couplers
	\end{enumerate}

\item Company X has been using a certain legacy software for 10 years straight. Numerous changes have been made to the software in order to encorporate changes to the environment and now the software is slower and has more bugs than 10 years ago. What is the name of this phenomena?

\item According to the "code ageing" concept, what is a good indication that you need to start from scratch and develope a new version of your software?

\item How can out of sync documentaion affect software maintenance?

\item A customer has asked you to implement a queue that can be simultaneously used by a number of users. What type of complexity are you expecting to be dealing with?

\item Below is a class diagram of a large application. What is a big problem with the design and why is it a problem? What can be done to resolve the issue? Draw a diagram which would resolve the issue.

\end{enumerate}

\includegraphics[width=6.5in]{scribe.png}

\clearpage
\subsection*{Sample Exam Question Solutions}
\begin{enumerate}
\item Perfective maintenance
\item Adaptive maintenance
\item To reduce all types of maintenance later.
\item (d) All of the above
\item Incorrect comments, duplicate code, long method, conditional complexity, switch statement, long parameter list.
\item Left as an exercise for the reader...
\item The Object-Orientation Abusers \footnote{Good link on the topic: \url{http://www.soberit.hut.fi/mmantyla/badcodesmellstaxonomy.htm}}
\item The Dispensables
\item Code decay
\item When the software has become so complex that is practically impossible (or very costly) to make any new changes.
\item It makes it hard to find bugs.
\item Communication complexity (which is type of coupling complexity) since synchronization is required among the processes that access the queue.
\item As the software grew, new functionality from System A used more classes from System B. As a result the two systems became very interleaved. There is very high coupling complexity. This makes it difficult to understand the design, difficult to find bugs, and also difficult to make changes. Since System A now depends on System B, it's not straight forward to change something in System B, because the change can break System A. One way to resolve the issue is to use the Facade design pattern. The following diagram shows how it should done:
\end{enumerate}
\begin{center}
\includegraphics[height=3in]{scribe_solution.png}
\end{center}

\bibliography{main}
\bibliographystyle{plain}

\end{document}

