Blogs

Well, yes and no.

Among testing professionals [http://www.istqb.org], static testing techniques are treated as first class citizens just as any other (dynamic) technique.

In my previous post, I’ve dealt with the risk of primitives. In this post I will show a similar theme, the risk of applying generics repeatedly in too much depth.

In the following example, we have a software system which deals with the products of different companies, where the products are grouped into product families. One functionallity of the system is to give a purchase report, which has to be presented on the user interface in the following form:

Company1                 Average Sells By Day   Average Age Of Customer
-- Product Family A

The variable might not have been initialized

Each local variable and every blank final field must have a definitely assigned value when any access of its value occurs.
For this purpose the standard introduced the concepts of definitely assigned and definitely unassigned variables.
If a variable is definitely unassigned when it is used, a compiler error occurs.

In our following example the compiler says that the variable o might not have been initialized in the statement "if (o.equals(args))".

Since there are a lot of programing and script languages it is impossible to know all of them in detail and of course it isn't necessary. You can be a professional Java developer even if you don't know the C++ at all. But you can easily get into a situation where you would need to use a language in which you are not professional. Fortunately these object oriented languages are very similar to each other so you don't have to know the C++ language in detail to write C++ programs, but beside the similarities all the languages have their own speciality.

Several times a development team has relatively short time to implement certain functionality. In these cases, the major goal is to implement the desired functionality before the strict deadline, and because of that, the source code is not or poorly documented. Furthermore, developers are apt to code the required functionality as fast as possible, which causes decreased understandability of the code. In this post, I’ll show simple and easily applicable tips to make the code more understandable by introducing classes.

Earlier we've seen a model which estimates development costs and relates them to the maintainability of a system. We've also provided an alternative definition of maintainability (let's call it relative maintainability) which is not an absoulte value (contrary to most of the existing definitions), but it's value is particular at the beginning and it's change depends only on how the code has been changing.

I think many of us have met the situation while compiling Java sources that the code was not compileable, although its small modification, which had the same semantic, provided a compileable code. This is annoying, especially when we want to carry out some automatic refactorings on our code.

Last time we estimated the cost of code change, now we'll try to reveal the connection of costs and maintenance.

Let's first suppose that the company we consider does not care about improving the code, it just fulfills the customer feature requests.
Suppose that a new feature request arrives (let's denote the feature by ).

Have you ever been wondering what does software maintenance cost? And how these costs split between separate development phases. In this section we are trying to find answers to this question by formal methods and by deriving several models that describe the different software development phases. Most of the presented models are linear ones, which can in some cases be easily justified, but in other cases we rely on empirical reasoning.

Let's get into it!