Reproducible Hands

Reproducible Hands

Hand in Hand - Database and Code Refractoring for Quality and Low cost Enterprise Software

Hand in Hand - Database and Code Refractoring for Quality and Low cost Enterprise Software

                                                                                                                                                                  K.Ravi

Abstract

 

Any software project development is supported by a programming language code (Front End) and a Database (Back end).

 

Producing software is a very complex process that takes a considerable time to evolve. Poorly designed software systems are difficult to understand and maintain. Modifying code in one place could lead to unwanted repercussions elsewhere due to high coupling. Adding new features can cause further quality degradation to the code if proper design and architectural concerns were not implemented. Development in a large enterprise system with such attributes will, over time, lead to a myriad of concerns unless the system is periodically overhauled or refactored in some way.

 

Software maintenance can take up to 50% of the overall development costs of producing software. One of the main attributes to these high costs is poorly designed code, which makes it difficult for developers to understand the system even before considering implementing new code. In the context of software engineering process, Software Refactoring has a direct influence on reducing the cost of software maintenance through changing the internal structure of the code to increase the design which helps the present and future developers evolve and understand the system.

 

In this article we shall discuss mainly about database and code refractoring as these two are the major components of any software development

 

Key words: Software Refractoring, Database refractoring, Software maintenance

 

1.Database Refractoring

A database refactoring is a small change to a database schema which improves its design without changing, at a practical level, the semantics of the database. In other words, it is a simple database transformation which neither adds nor breaks anything. The process of database refactoring defines how to safely evolve a database schema in small steps. Database refactoring enables data professionals to work in an evolutionary manner, just as modern application developers do. It also provides a coherent strategy for organizations to dig their way out of the legacy database hole.

 

A database refactoring is a simple change to a database schema that improves its design while retaining both its behavioral and informational semantics.  For the sake of this discussion a database schema includes both structural aspects such as table and view definitions as well as functional aspects such as stored procedures and triggers.  An interesting thing to note is that a database refactoring is conceptually more difficult than a code refactoring; code refactorings only need to maintain behavioral semantics while database refactorings also must maintain informational semantics.

 

 

2. Why Database Refactoring?

There are two fundamental reasons why you want to adopt database refactoring:

1. To repair existing legacy databases. Database refactoring enables you to safely evolve your database design in small steps, making it an important technique for improving the legacy assets within your organization. This is clearly much less risky than a "big bang" approach where you rewrite all of your applications and rework your database schema and release them all into production at once. Furthermore, it is much better than the "let's try not to allow things to get any worse" strategy currently employed by the vast majority of data management groups which I've run into, a strategy which has no hope of success because all it takes is one development team to go around the data management group and do an imperfect database design.

The bottom line is that legacy databases aren't going to fix themselves, and that from a technical point of view database refactoring is a safe, simple way to improve data, and database, quality over time.   July 2006 survey into the current state of data management shows that 33% of organizations either are, or intend to take, an refactoring-based approach to addressing existing production data quality problems.

1. To support evolutionary software development. Modern software development processes, including the Rational Unified Process (RUP), Extreme Programming (XP), Agile Unified Process (AUP), Scrum, and Dynamic System Development Method (DSDM), are all evolutionary in nature. Craig Larman [4] summarizes the research evidence, as well as the overwhelming support among the thought leaders within the IT community, in support of evolutionary approaches. Unfortunately, most data-oriented techniques are serial in nature, relying on specialists performing relatively narrow tasks, such as logical data modeling or physical data modeling. Therein lies the rub - the two groups need to work together, but both want to do so in different manners. I believe that data professionals need to adopt evolutionary techniques, such as database refactoring, which enable them to be relevant to modern development teams. Luckily these techniques exist, and they work quite well, it is now up to data professionals to choose to adopt them.

3.The lifecycle of a database refactoring.

 

4.The process of database refactoring.

 

Database refactoring as a three-step process:

1.Start in your development sandbox

2. Implement in your integration sandbox (es)

3.Install into production

 

 Step 1: Start In Your Development Sandbox

Your development sandbox is the technical environment where your software, including both your application code and database schema, is developed and unit tested.  The need to refactor your database schema is typically identified by an application developer who is trying to implement a new requirement or who is fixing a defect.  For example, a developer may need to extend their application to accept Canadian mailing addresses in addition to American addresses.  The main difference is that Canadian addresses have postal codes such as R2D 2C3 instead of zip codes such as 90210-1234.  Unfortunately the ZipCode column of the Surface Address table is numeric and therefore will not currently support Canadian postal codes.  The application developer describes the needed change to one of the Agile DBA(s) on their project and the database refactoring effort begins.

 

As depicted in Figure, the Agile DBA and application developer will typically work through some or all of the following steps to implement the refactoring:

•Verify that a database refactoring is required

•Choose the most appropriate database refactoring

•Deprecate the original schema

•Write unit tests

•Modify the database schema

•Migrate the source data

•Update external access programs

•Update your data migration script(s)

•Run your regression tests

•Announce the refactoring

•Version control your work

 

 

                                         

Fig.  Database refactoring process

 

Step 2: Implement In Your Integration Sandbox

After several days have passed you will be ready to implement your database refactoring within your project integration sandbox.  The reason why you need to wait to do so is to give your teammates time to refactor their own code to use the new schema. 

 

Teams that have chosen to encapsulate access to their database via the use of a persistence framework will find it easier to react to database schema changes and therefore may discover they can tighten up the period between implementing a database refactoring within a development sandbox and in their project integration sandbox.  This is due to the fact that the database schema is represented in meta data, therefore many database schema changes will only require updates to the meta data and not to the actual source code.

 

To deploy into each sandbox you will need to both build your application and run your database management scripts (tools such as Autopatch can help).  The next step is to rerun your regression tests to ensure that your system still works – if not you will need to fix it in your development environment, redeploy, and retest.  The goal in your project integration sandbox is to validate that the work of everyone on your team works together, whereas your goal in the Test/QA sandbox is to validate that your system works well with the other systems within your organization.

 

A critical part of deploying database refactorings into your Test/QA sandbox, I'm using the plural now because you typically introduce several database factors into this environment at once, is communication.  Long before you change your database schema you need to communicate and negotiate the changes with the owners of all of the other applications that access your database.  Your enterprise administrators will be involved in this negotiation, they may even facilitate the effort, to ensure that the overall needs of your organization are met.  Luckily the process that you followed in your development sandbox has made this aspect of database refactoring easier:

•           The Agile DBA only allowed database refactorings that can realistically be implemented – if another application team isn't going to be able to rework their code to access the new schema then you can't make the change. 

•           The documentation, even if it's only a brief description of each change, that the Agile DBA wrote is important because it provides an overview of the changes that are about to be deployed. 

•           The new version physical data model (PDM), which was updated as database refactorings were implemented, serves as a focal point for the negotiations with other teams.  Agile Modeling (AM) would consider the PDM to be a "contract model" that your team has with the other application teams, a model that they can count on to be accurate and that they can count on being actively involved in negotiating changes to it.

 

Step 3: Install Into Production

Installing into production is the hardest part of database refactoring, particularly in the complex situation of Figure .  You generally won't deploy database refactorings on their own, instead you will deploy them as part of the overall deployment of one or more systems.  Deployment is easiest when you have one application and one database to update, and this situation does occur in practice, but realistically we need to consider the situation where you are deploying several systems and several data sources at once.  Figure  overviews the steps of deploying your refactorings into production.

 

  

 

 

 

Fig.  Deploying database refactorings

 

5.A Simple customer database schema Example

 

 

 

 

 

 

 

 

 

The initial database schema.               The Transition period.                             The final database schema

 

 

 

 

 

 

 

 

 

 

 

 

Figure depicts the best-case scenario for database refactoring – when it is only your application code that is coupled to your database schema. Figure depicts the worst-case scenario for database refactoring efforts where a wide variety of software systems are coupled to your database schema, a situation that is quite common with existing production databases.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

       Fig.Best case scenario

                                                                                     Fig.Worst Case Scenario

 

 

6.Database Refactoring Best Practices

1. Refactor to ease additions to your schema. 
2. Ensure the test suite is in place. 
3. Take small steps. 
4. Program for people. 
5. Don't publish data models prematurely. 
6. The need to document reflects a need to refactor. 
7. Test frequently. 

 

 

7.Categories of database refactoring:

 

Structural:  A change to the table structure of your database schema.

Data quality:  A change which improves and/or ensures the consistency and usage of the values stored within the database.

Referential integrity:  A change which ensures that a referenced row exists within another table and/or that ensures that a row which is no longer needed is removed appropriately. 

Architectural:  A change which improves the overall manner in which external programs interact with a database.

Method: A change which improves the quality of a stored procedure, stored function, or trigger. 

Non-refactoring transformations:  A change which changes the semantics of your database schema by adding new elements to it or by modifying existing elements. 

 

Table of Database Refractoring Catogories

Category 

Database Refactorings 

Structural Refactorings

• Drop Column
• Drop Table
• Drop View
• Introduce Calculated Column
• Introduce Surrogate Key
• Merge Columns
• Merge Tables
• Move Column
• Rename Column
• Rename Table
• Rename View
• Replace LOB With Table
• Replace Column
• Replace One-to-Many With Associative Table
• Replace Surrogate Key with Natural Key
• Split Column

• Split Table

Data Quality Refactorings

• Add Lookup Table
• Apply Standard Codes
• Apply Standard Type
• Consolidate Key Strategy
• Drop Column Constraint
• Drop Default Value
• Drop Non-Nullable Constraint
• Introduce Column Constraint
• Introduce Common Format
• Introduce Default Value
• Make Column Non-Nullable

• Move Data
• Replace Type Code With Property Flags

Referential Integrity

 Refactorings

• Add Foreign Key Constraint
• Add Trigger for Calculated Column
• Drop Foreign Key Constraint
• Introduce Cascading Delete
• Introduce Hard Delete
• Introduce Soft Delete

• Introduce Trigger for History

Architectural Refactorings

• Add CRUD Methods
• Add Mirror Table
• Add Read Method
• Encapsulate Table With View
• Introduce Calculation Method
• Introduce Index
• Introduce Read Only Table
• Migrate Method From Database
• Migrate Method to Database
• Replace Method(s) With View
• Replace View With Method(s)

• Use Official Data Source

Method Refactorings

• Add Parameter
• Consolidate Conditional Expression
• Decompose Conditional
• Extract Method
• Introduce Variable
• Parameterize Methods
• Remove Control Flag
• Remove Middleman
• Remove Parameter
• Rename Method
• Reorder Parameters
• Replace Literal With Table Lookup
• Replace Nested Expression With Guard Clauses
• Replace Parameter With Specific Methods
• Split Temporary Variable

• Substitute Algorithm

Non-Refactoring Transformations

• Insert Data
• Introduce New Column
• Introduce New Table
• Introduce View

• Update Data

 

 

8.Tools to Help

Doing this kind of thing requires a lot of repetitive tasks. The good news is that whenever you run into run into repetitive tasks in software development you are ideally placed to automate them. As a result we've developed a fair amount of often simple tools to help us.

One of the most valuable pieces of automation is a simple set of scripts for common database tasks.

• Bring a user up to date with the current master.
• Create a new user
• Copy a database schema, for example Sue finds a bug with her database, now Mike can copy Sue's database and try to debug the application
• Move a database, for example from a workstation to a different workstation, this is essentially Copy database and Delete database combined as one
• Drop a user
• Export a user so team members can make offine backups of the database that they are working with.
• Import a user, so if the team members have a backup copy of the database, they can import the backup and create a new schema.
• Export a baseline - make a backup copy of the master database. This is a specialized case of Export a User
• Create a difference report of any number of schemas, so that Mike can find out what is different structurally between his database and Sue's.
• Diff a schema against the master, so that developers can compare their local copy against the master.
• List all the users

 

To conclude, Database refactoring is a database implementation technique, just like code refactoring is an application implementation technique. You refactor your database schema to ease additions to it. You often find that you have to add a new feature to a database, such as a new column or stored procedure, but the existing design is not the best one possible to easily support that new feature. You start by refactoring your database schema to make it easier to add the feature, and after the refactoring has been successfully applied, you then add the feature. The advantage of this approach is that you are slowly, but constantly, improving the quality of your database design. This process not only makes your database easier to understand and use, it also makes it easier to evolve over time; in other words, you improve your overall development productivity.

 

 Experience is that data professionals can benefit from adopting modern evolutionary techniques similar to those of developers, and that database refactoring is one of several important skills that data professionals require. Evolutionary development has arguably become the norm within the IT community, and agile software development approaches extend evolutionary methods to become more effective. Data professionals take evolutionary and agile concepts and techniques seriously: they're real, they work, and they're here to stay.

 

 

9.Software (Code) Refractoring

 

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation called a 'refactoring' does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

 

10.Refactor to Improve Code Design

Refactoring restructures your code into a more simplified or efficient form in a disciplined way. Refactoring software code improves its internal structure without changing external functionality for more efficient execution, faster download speed, and easier updates.

 

Refactoring is the art of reworking your code into a more simplified or efficient form in a disciplined way. Refactoring improves internal code structure without altering its external functionality by transforming functions and rethinking algorithms. Consequently, refactoring is an iterative process. By refactoring your JavaScript, Flash, and Java you can streamline its size, simplify your code, and speed up download and execution speed.

 

Martin Fowler, who wrote the book on refactoring, calls these changes "transformations." Individual transformations may make small improvements, but taken as a whole transformations can make a significant improvement to your code. Refactorings include reducing scope, replacing complex instructions with simpler or built-in instructions, and combining multiple statements into one statement. Here's a simple example that replaces an assignment with an initialization. So instead of this:

               function foo() {                        var i;                        // ...                        i = 5;}

Do this:

function foo() {    var i = 5;    // ...}

 

11.The Need Refactoring

Continuous design allows one to add more flexibility into the design, by adding to an initially simple design as the need arises, instead of having a big upfront design. Thus the design will evolve as the code grows. There is a shift from building software towards growing it. The process of refactoring can be used to contribute to these evolving states of the code.

• Refactoring improves the design of software

Without refactoring the design of the program will decay. Poorly designed code usually takes more to do the same things, often because the does the same thing in different places

• Refactoring makes the code easier to understand

In most software development environments, somebody else will eventually have to read the code so it becomes easy for others to comprehend.

• Refactoring helps to find bugs

It helps in finding the Bugs present in the program.

• Refactoring helps to program faster

It helps us to do the coding/programming faster as we have better understanding of the situation.

 

Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, duplicate code, and many other varieties of confusion and clutter. (Check out this list of such "design smells.")

Rot is what makes code difficult to maintain or extend. Every time we change code without refactoring it, rot worsens and spreads. Code rot frustrates us, costs us time, and unduly shortens the lifespan of useful systems.

Refactoring code ruthlessly prevents rot, by keeping code easy to maintain and extend. This extensibility is the reason to refactor and the measure of its success. This is what enables XP teams to embrace arbitrary and drastic change. Note that the XP practice of Test-driven Development (TDD) is essential to refactoring. The exhaustive tests produced by TDD are what make it safe and orderly to make changes of any kind. This is why Adaption always teaches TDD and refactoring together.

 

12.Code Hygiene

What does "refactor ruthlessly" mean? It means striving as a matter of routine to keep the code's design simple and crystal clear. It means knowing the design principles and patterns that are vital to keeping code extensible, and knowing when to "refactor toward" them. It means refactoring both production code and test code frequently during the day, eliminating all forms of the "code smells" that are precursors to true rot.

Mainly it means never going home at the end of the day with "code debts" that need paying tomorrow (smelly sections that need cleaning up). This level of code hygiene may at first seem like a lot of extra work, but it pays you such dividends so soon and so regularly that you soon become ddicted to it -- rather like TDD.

 

13.Specific "Refactorings"

Refactorings are the opposite of fiddling endlessly with code; they are precise and finite. Martin Fowler's definitive book on the subject describes 72 specific "refactorings" by name (e.g., "Extract Method," which extracts a block of code from one method, and creates a new method for it). Each refactoring converts a section of code (a block, a method, a class) from one of 22 well-understood "smelly" states to a more optimal state. It takes awhile to learn to recognize refactoring opportunities, and to implement refactorings properly. This is a practice at the heart of high software craft.

 

14.The Flow of Refactoring

In a TDD context, refactoring has the same flow as any other code change. You have your automated tests. You begin the refactoring by making the smallest discrete change you can that will compile, run, and function. Wherever possible, you make such changes by adding to the existing code, in parallel with it. You run the tests. You then make the next small discrete change, and run the tests again. When the refactoring is in place and the tests all run clean, you go back and remove the old smelly parallel code. Once the tests run clean after that, you are done. Badabing, badaboom: cleaner code, with no new bugs.

 

15.Refactoring Automation in IDEs

Fortunately, more and more Integrated Development Environments (IDEs) are building in automated refactoring support. For example, Adaption's favorite IDE for Java is eclipse, which includes more auto-refactorings all the time. Another favorite is IntelliJ IDEA.

To refactor code in eclipse or IDEA, you select the code you want to refactor, pull down the specific refactoring you need from a menu, and the IDE does the rest of the hard work. You are prompted appropriately for new names for things that need naming, and for similar input. You can then immediately rerun your tests to make sure that the change didn't break anything. If anything was broken, you can easily undo the refactoring and investigate.

16.Refactoring activities

The refactoring process consists of a number of different activities, each of which can be automated to a certain extent:

(1) Identify where the software should be refactored;

(2) Determine which refactorings should be applied to the identified places;

(3) Guarantee that the applied refactoring preserves behavior;

(4) Apply the refactoring;

(5) Assess the effect of refactoring on software quality characteristics;

(6) Maintain consistency between refactored program code and other software artifacts (or vice versa).

 

The steps taken when applying the refactoring should be small enough to oversee the consequences they have and reproduceable to allow others to understand them. Generalized refactoring steps in a way, are more a rule that can be applied to any structure.

 

Refactoring as proposed by Fowler not only covers the mechanics of restructuring, but also addresses the following issues:

• Refactoring emphasizes that, in absence of more formal guarantees, testing should be used to ensure that each restructuring is behavior preserving. A rich test suite should be built, which must be run before and after each test is applied.

• Refactorings are described in a catalog, using a template reminiscent of design patterns.

• Refactorings are applied in small steps, one by one, running the test suite after every step to make it into commercial development tools.

 

 

17.Refactoring techniques

A Few Refactoring Techniques

•  Add Parameter
•  Rename Method
•  Remove Parameter
•  Move Field
•  Extract method
•  Extract class
•  Extract Interface
•  Hide delegate
•  Pull up Method
•  Push down Method
•  Push down Field
•  Inline class
•  Inline Method
•  Encapsulate field
•  Collapse hierarchy etc

 

17.1Extract Method

A fragment of code that can be grouped together, turn it into a method with a name that explains the purpose of the method.

 

void printFormatted(string text)

{

System.out.println ("Refractoring the Code");

"System.out.println ("Author: Venkatesh");

printRest(text);

}

void printFormatted(string text) {

printHeader();

printRest(text);

}

printHeader()

{

System.out.println("Refractoring the Code");

System.out.println("Author: Venkatesh") ;}

 

 

 

18.Refactoring tool support

18.1Language Support

Support for restructuring has been provided in a variety of different programming languages and language paradigms: imperative or procedural languages (FORTRAN, Cobol, C); functional languages (Scheme, Lisp, Haskel); logic languages (e.g., Prolog); class-based object-oriented languages (Smalltalk, Java, C++); prototype-based object oriented languages (e.g., Self ); aspect-oriented languages (e.g., AspectJ).

 

18.2Tool Support

Refactoring tools are difficult to construct. They need to be correct but also highly usable, where "usable" in this context includes interactive, fast, user-friendly, integrated, and exploratory. After some experience on constructing refactoring tools is gained, the task of expanding to new programming languages may hopefully become easier.

 

 

Eclipse was among the first IDEs to help bring refactoring to the mainstream developer. Eclipse version 1.0 included several highly useful Java refactorings, which are nowadays staple tools in most Java developers' toolbox.

 

These included Rename, Move, and Extract Method. Eclipse 2.0 added a lot of statement-level refactorings such as Extract and Inline Local Variable, Change Method Signature, and Encapsulate Field. Some refactorings, such as Rename, offer great leverage because of the potential scale of the changes they perform automatically. Others, like Extract Method, are more local in scope, but relieve the developer from performing the analysis required to ensure that program behavior is unaffected. In both cases, the developer benefits from reduction of a complex and numerous changes to a single operation. This helps to maintain his focus on the big picture. Moreover, the ability to roll back the changes with a single gesture enables exploration of structural possibilities more easily, and without fear of irreparable damage to the code base.

 

19.Eclipse & Net beans - Java   refactoring

 

 

Refractoring using Net Beans

 

Finally Software Refactoring is an important area of research that promises substantial benefits to software maintenance. Refactoring is a process that improves the quality and allows developers to repair code that is becoming hard to maintain, without throwing away the existing source code and starting again. We can return with a well structured and well designed code after proper application of refactoring techniques. Refactoring naturally fits in an agile software development process. It forms even one of the cornerstones of the eXtreme Programming process; together with unit testing. The research in software engineering continues to be very active.

 

20.Conclusion:

Up to 75% of the costs associated with the development of software systems occur post-deployment during maintenance and evolution. Software refactoring is a process that can significantly reduce the costs associated with software evolution. Refactoring is defined as internal modification of source code to improve system quality, without change to observable behaviour. Tool support for software refactoring attempts to further reduce evolution costs by automating manual, error-prone and tedious tasks. Although the process of refactoring is well-defined, tools supporting refactoring do not support the full process. Existing tools suffer from issues associated with the level of automation, the stages of the refactoring process supported or automated, the subset of refactorings that can be applied, and complexity of the supported refactorings.

 

References

[1]               Fowler, M. (1999). Refactoring: Improving the Design of Existing Code.  

Menlo Park, California: Addison Wesley Longman, Inc.

[2]               Ambler, S.W. (2003). Agile Database Techniques: Effective Strategies for  

the Agile Software Developer. New York: John Wiley & Sons. www.ambysoft.com/books/agileDatabaseTechniques.html

[3]               Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases:  

Evolutionary Database Design. Boston: Addison Wesley. www.ambysoft.com/books/refactoringDatabases.html

[4]               Larman, C. (2004). Agile and Iterative Development: A Manager's Guide.

Boston: Addison-Wesley.

[5]               Astels D. (2003). Test Driven Development: A Practical Guide. Upper

Saddle River, NJ: Prentice Hall.

[6]               Beck, K. (2003). Test Driven Development: By Example. Boston, MA:

Addison Wesley.

[7]               Ambler, S.W. (2004). Introduction to Test Driven Development (TDD).  

www.agiledata.org/essays/tdd.html

[8]               Ambler, S.W. (2004). The Agile Data Home Page. www.agiledata.org.

[9]               Ambler, S.W. (2002). Agile Modeling: Best Practices for the Unified

Process and Extreme Programming. New York: John Wiley & Sons. www.ambysoft.com/books/agileModeling.html

[10]                       Ambler, S.W. Agile Model Driven Development (AMDD).

www.agilemodeling.com/essays/amdd.htm

[11]                       Java Refactorings in Eclipse-http://www.eclipse.org

[12]                       Martin Fowler, „Refactoring Home Page"-http://www.refactoring.com

[13]                       Fowler, martin: A list of refactoring tools for several languages,- 

http://www.refactoring.com/tools.html

[14]                       Discussion site on code smells -http://c2.com/cgi/wiki?CodeSmell

 

 

[1] V V N Kumar,email:naren6568@rediffmail.com,K.Rav,kolipakaravi@yahoo.co.in Faculty Department of Informatics,Alluri Institute of Management Sciences,Warangal,A.P.-506001(India)

About the Author

K.Ravi

Assist.professor

Dept. of Informatics

Alluri Institute of Management Sciences

Hunter Road, Warangal-506002

Evolution is a reproducible science?

I read an answer that said "Evolution is a reproducible science."
Please explain this to me. I understand that there is some merit to the idea of natural selection, but I don't recall any mention of direct observation of evolutionary mutation that didn't involve any assumption on the part of the observer. Besides, doesn't it take at least thousands of years to manage even a small mutation that can survive throughout future generations? If that's true, then no scientist can definitively claim that they've observed the process of evolution first hand.

Evolution is not a "science." It is history. It is what happened on earth for the past 4.5 billion years. Evolution is the most logical and reasonable explanation for the scientific facts that have been discovered by scientists. There are of course some other explanations for the same facts, such as special creation, but these explanations require faith to believe in them.

Since evolution is history, it is not directly observable. Besides, no human being has a life span long enough for him or her to have observed the history of life, since it is at least 3.5 billion years in duration and global in terms of geography. Human beings can only attempt to reconstruct what had happened using such indirect evidence as the incomplete fossil record and the diversity of living organisms, their anatomy, morphology, and biochemistry, as well as physics and geology, or whatever clues that we can possibly find which may help us explain what had happened.

What we observe is the product of evolution as well as the process of evolution. We observe for example that the rocks are full of fossils that are unlike living organisms and yet they are unquestionably related to living organisms. For example, there are a number of fossil hominids that are no longer living, and they have strange combinations of features. Some of them for example have a bipedal stance but small, ape-like brains and facial features. Other fossils are clearly related to these but they have bigger brains and less ape-like and more human-like facial features. The fossil record therefore tells us what had happened: i.e. small brained, quadrupedal apes had evolved into small brained, bipedal hominids, and from these larger brained bipedal hominids evolved. After about 5 million years, the transformation from ape to human is complete and preserved in the fossil record.

After we figured out what had happened, we need to figure out how. Charles Darwin proposes the theory of natural selection. He demonstrated through evidence that selective breeding can result in a change in the morphology of various dog breeds through time. He reasoned that the same process of selective breeding, called natural selection, because nature is doing the selection, is responsible for the appearance of new species in nature. Natural selection is the theory of how evolution could have taken place. Natural selection is a scientific theory and it is testable. And it has been tested ever since Darwin proposed it. So far, all attempts to falsify natural selection has failed. That is why the study of evolution history and how it occurred through the process of natural selection is considered a science, since this theory makes predictions and these predictions can be tested.

Hand, Wrist & Finger Safety Video Program -www.safetyissimple.com