String matching is something crucial for database development and text processing software. Fortunately every modern programming language and library is full of functions for string processing that help us in our everyday work. However is great to understand their principles.

String algorithms can be mainly divided into several categories. One of these categories is string matching.

When we come to string matching the most basic approach is what is known as brute force, which means just to check every single character from the text to match against the pattern. In general we have a text and a pattern (most commonly shorter than the text). What we need to do is to answer the question whether this pattern appears into the text.

Overview

The principles of brute force string matching are quite simple. We must check for a match between the first characters of the pattern with the first character of the text as on the picture bellow.

In case they match we move forward the second character of the pattern comparing it with the “next” character of the text, as on the picture bellow.

Just because we have found a match between the first character from the pattern with some character of the text, doesn’t mean that the pattern appears in the text. We must move forward to see whether the full pattern is contained into the text.

Implementation

Implementation of brute force string matching is easy and here we can see a short PHP example. The bad news is that naturally this algorithm is quite slow.

function sub_string($pattern, $subject) 
{
	$n = strlen($subject);
	$m = strlen($pattern);
	
	for ($i = 0; i < $n-$m; $i++) {
		$j = 0;
		while ($j < $m && $subject[$i+$j] == $pattern[$j]) {
			$j++;
		}
		if ($j == $m) return $i;
	}
	return -1;
}

echo sub_string('o wo', 'hello world!');

Complexity

As I said this algorithm is slow. Actually every algorithm that contains “brute force” in its name is slow, but to show how slow is string matching I can say that its complexity is O(n.m). Here n is the length of the text, while m is the length of the pattern.

In case we fix the length of the text and test against variable length of the pattern, again we get rapidly growing function.

Application

Brute force string matching can be very ineffective, but it can also be very handy in some cases. Just like the sequential search.

It can be very useful ...

1. Doesn't require pre-processing of the text - Indeed if we search the text only once we don't need to pre-process it. Most of the algorithms for string matching need to build an index of the text in order to search quickly. This is great when you've to search more than once into a text, but if you do only once, perhaps (for short texts) brute force matching is great!
2. Doesn't require additional space - Because brute force matching doesn't need pre-processing it also doesn't require more space, which is one cool feature of this algorithm
3. Can be quite effective for short texts and patterns

It can be ineffective ...

1. If we search more than once the text - As I said in the previous section if you perform the search more than once it's perhaps better to use another string matching algorithm that builds an index and it's faster.
2. It's slow - In general brute force algorithms are slow and brute force matching isn't an exception.

Final Words

String matching is something very special in software development and it is used in various cases, so every developer must be familiar with this topic.

The stages of analysis and design are the main stages in the traditional approaches. Of course the focus of the whole project is there and therefore the effort at these stages is very important. They are methodology-centric – this means that the methodology is very extensive and the right application of the method is a warranty for a successful project.

It’s not far from the truth that the methodology is more important factor than the human factor.

All these traditional approaches are systematic methods of software development where the building phase always follows the stage of design. Most of the important decisions are made during the stage of design and once the product is well designed the project can be continued with the phase of building – which is supposed to be very predictable. Thus the stage of building the product only follows the “perfect” design of the system.

In that scenario we can see two main activities: design, which is highly creative activity, it is difficult to predict and needs high qualification, and build in other hand, which is simple to predict and doesn’t need high qualification [1].

All these facts can be summarized into the following conclusions:

• When building a software product – the stage of building is a small piece of the whole process.
• The stage of “design” remains the main part of the software construction process.
• It is very difficult to plan and predict processes with high level of creativity.

This is why the traditional methodologies of software development are very useful in some and unsuccessful in other types of projects. Because their main feature is the detailed planning and designing phase they are useful when the project is said to be very large and the level of risk is high. Some project that are estimated to last very long is often developed with some traditional methodology [2].

The traditional approaches, in general, can be described by their main features as follows:

1. They are relevant when the project is very large and the building team is also very large and not always geographically collocated;
2. The stage of planning is very detailed;
3. The documentation is very large and describes all the features of the system;
4. They are used for projects where the main requirements are defined early and doesn’t change often;
5. The phases of analysis, planning, design, build and deploy are consecutive;

[1] Fowler M. The New Methodology, 2005
[2] Wysocki R. K., McGary R., Effective Project Management, Third Edition, John Wiley & Sons © 2003

The agile methods are based on a set of new principals of design and build – different from the principals used before. However to understand the agile methodologies first of all we need to understand the reason of their appearance. Thus we’ve to first understand the traditional methods of software development – their features, their pros and cons, and nevertheless we’ve to understand their relevance.

Features of the Traditional Methods

The so called traditional approaches, also known as “engineering” approaches, are defined at the very beginning of the software sciences. Of course the software development process need to be controlled somehow. To do so the software engineers came along with the well known engineering methods of controlling the processes. These methods are applying a disciplined approach where the stages of design and build are well predictable. Detailed stages of analysis and design precede the stage of building the software.

These methodologies are well documented and thus are quite complex to apply. Of course this is the main reason when we talk about their disadvantages. One of the main disadvantages is that these traditional methodologies are very bureaucratic. In practice the high level of detail in a methodology leads to a high level of complexity. Actually the work of managing the methodology itself is more than the work on the software product.

to be continued …

Typically the software build processes are followed by the processes of controlling and managing software projects. In the very beginning of the software sciences these were methodologies that relied mainly on a detailed documentation, precise planning and higher degree of control. As it appears in many kind of projects this approach is simply ineffective. Most of those kind of projects are characterized as very dynamic, with many requirement changes that makes them difficult to predict and control with the traditional methods of software development.

To answer the necessity of managing such kind of project the software industry came up with some new and radical approaches of managing software projects. Thus in the mid 90’s appear some of nowadays well known agile methodologies. Developed during the years, many times corrected from their disadvantages and finally defined theoretically in the beginning of the new century now these methodologies are used in a vast majority of the software projects.

The agile methodologies differ from the traditional methods by their high adaptivity, low level of bureaucracy and in the same time high level of communication. The client is often involved into the process of software development. His ability to give quick feedback on the team is something very typical to the agile methodologies.

Finally all these features of the agile methodologies helped the industry to manage projects that are highly dynamical.

In a series of posts I decided to share my knowledge about the agile methods beginning with this one. However to understand the necessity of the agile methodologies you need to understand first the characteristics of the traditional, or so called “engineering” approaches.

Perhaps Master Yoda would say that, but it’s interesting to know what methodology do you use in your work. Any answers will be highly appreciated, so here are some basic questions:

1. Do you follow any software development methodology?
2. Do you use any agile methodology?
3. What is good and what’s bad?
4. Do you think agile is better than non-agile methodologies?

Thanks anybody in advance!