Test automation framework: What is Test script modularity (definition and some details)

In the previous post (Test Automation Frameworks), I started out by doing a short definition of Test Automations Frameworks, some benefits, and also listed out the 5 different types of Test Automation Frameworks that are currently there (and based on the number of tools available, the combination can be much more since there are many high end and complex tools available for test automation). In this post, I will talk more about one of these, which is called "Test script modularity".
A simple definition for the Test Script Modularity Framework: This framework is the most basic of the various test automation frameworks, with the ideology being towards the creation of a number of small and independent test scripts that in turn represent the modules, sections and functions of the application that is under testing. Once these scripts are created, they are then added in a hierarchical fashion to create larger tests, with the aim of creating test cases.
What is the basic principle behind this ? It is a basic principle of design to create a layer (or to be more technical, an abstraction layer) for a component. This layer in turn ensures that the component is available to the rest of the application in a way that even when the component is modified, the rest of the application is not affected. This concept is one of the key concepts of the test script modularity framework.
One of the key advantages of this framework is that it results in a high degree of modularization, and ensures that the test suite is easily maintainable. By encapsulating all components, when a component changes, you don't have to change the other components or the test cases that call this component.