- Layering
- Layered Architecture
- Common Layering Schemes
- Layered Architecture Defined
- Other Considerations
- Summary and Preview
Other Considerations
Application Services
Developers must apply application responsibilities to all application development efforts. Implementing these activities consistently using a design that is extensible will facilitate reuse and minimize side effects when requirements change. Moreover, standardizing these services across all applications can yield efficiencies in determining and communicating new development and maintenance activities.
Obvious application responsibilities include error handling, status tracing, application start-up and shutdown, accessing externalized properties, and applying interface preferences. A design must allow developers to consistently apply error handling across all applications and also support the ability to install and to change these behaviors on an application basis. For example, application status is sometimes reported to a console, but what happens if the application is server based and a console does not exist? The design should allow tracing to be routed to a flat file or maybe to the console. For a discussion of design and implementation issues for application service layers, see Appendix B.
Test Scripts
The primary design intent of a layered architecture is decoupling a problem-space domain model from presentation and data source requirements. Reuse of the domain, at least across application boundaries, can be achieved if isolation is accomplished.
Creating test scripts that exercise domain model behavior helps to verify domain isolation and also to
Verify domain functionality
Support white box[2]–oriented regression testing
Document usage intent through implementation examples
Provide project plan milestones for domain implementation
Provide a convenient place to apply performance timings
Test scripts should be created to exercise retrieval and output of individual top-level domain classes. Because all domain objects will inherit persistent operations, these types of test scripts can be created without physical data sources. An example test script that retrieves and outputs project objects and displays their state to the console is given in Listing 3.1.
Listing 3.1 An example of a test script.
import com.wsbook.casestudy.domain.*;
import java.util.*;
public class RetrieveAndDisplayEmployees {
/**
* Retrieve and display Employees
* @param args an array of command-line arguments
*/
public static void main(java.lang.String[] args) {
// Retrieve Employees
Vector employees = new Employee().retrieveAllObjects();
// Enumerate over Employees
Enumeration elements = employees.elements();
while (elements.hasMoreElements()) {
Employee anEmployee = (Employee) elements.nextElement();
// Display anEmployee...
System.out.println(anEmployee);
}
}
}
No hard-and-fast rules dictate what type of test scripts to create. Test scripts can also be created to exercise and verify, create, read, and update requirements or to implement operations to satisfy a use case that came out of the design process. A domain design that performs an interesting operation can also be captured in a use case. Each test script should be defined using a descriptive class name, regardless of length. For example, some of the test script class names defined for this book's case study on time sheets are
CreateAndSaveTimeSheet
DisplayTimeSheets
DisplayPendingTimeSheets
ApplyPendingTimeSheet
Creating test scripts is a simple notion and exercise that if incorporated in the development process can result in many benefits during and throughout an application's life cycle.