Flexible Software Development – Literature Review
This chapter represents the literature review that carried throughout this research area. That includes brief explanation of the current study over the software architecture followed by the problem layer of the architecture (domain logic). As well other patterns reviewed too that increase the flexibility of domain logic. Finally, a summary would conclude this chapter’s highlighting key points that have arisen throughout the literature review.
2.2. Software Layers
In the previous research it has been demonstrated that the overall software architecture has to be divided into various layers where each layer handles a particular part of the software and that can then minimize software complexity. In the software development the higher layer of the software uses different services defined by the lower layer, but the lower layer is not aware of the upper layer. For instance, most of the time each layer hides its lower layer from the layer above, such as layer 3 uses the services of the layer 2, which uses the services of the layer 1, but layer 3 is unaware of layer 1 (Prisacaru, 2007).
Corporation (2003) suggested there are several reasons why separating business logic from presentation logic is desired. Below are a couple of reasons why we do it.
- Separating the GUI Layer and Business Logic allows one to use the best tools for that particular part. For example if you are programming a user interface screen – the kinds of things you are concerned with are paging – e.g. how many records to show on a page, widths of forms, colours and etc. On the business side you are not so concerned about visuals – you need to get the data from somewhere and you need to control what data is loaded, and how that data is updated. If you change your programming languages next year, it is much easier to reuse old code when it is separated.
- The two parts – business logic and presentation logic – do not always occur at the same time. For example, often times you design the screens first and then cut in the business logic later. Separating the two minimizes time dependency and allows for concurrent development. You can work on each part independently and then integrate them later
In basic terms, a data source is a facility for storing data. It can be as sophisticated as a complex database for a large corporation or as simple as a file with rows and columns. Applications access a data source using a connection, and a
Data Source object can be thought of as a factory for connections to the particular data source that the
Data Source instance represents (Sun Microsystems, 2001).
2.3 Business Models
As it has been indicated above that business logic is the problem domain layer, therefore two domain layers were reviewed that each will have different level of flexibility and performance.
2.3.1 Table Module
Table Module organizes domain logic with one class per table in the database, and single instance of Table Module class contains various procedure that act on the data of the database table. Fowler also described that other business model which is called Domain Model contains interfacing problem with relational database. Domain Model is explained by Martin Fowler as:
“Domain Model is an object model of domain that incorporates both behaviour and data. Furthermore any object oriented design literature will talk about Domain Model and its pure object oriented development layer”.
The primary distinguish between Domain Model and Table Module is that, if you have many orders, a Domain Model will have one order object per order while a Table Module will have one object to handle all orders.
Each Table Module object represents a set of rows such as all the rows of the database table rather than a single row and therefore in order to operate on a single row, the methods of the table module must be passed in identifiers.
When a method of a Table Module is called, it performs its logic against a set of rows passed into it. In Framework applications this maps to a DataSet and is therefore a natural way to represent domain logic. (Dan Agonists 2004)
Figure 2.1: Domain Logic of Table Module Has One Class per Database Table
2.3.2 Transaction Script
This domain logic organizes all its logic primarily as a single procedure, making calls directly to the database or through a database wrapper such as Row Data Gateway. Each transaction of Transaction Script will have its own Transaction Script, even a common subtask can be broken into sub procedures. Also, for organizing Transaction Script Fowler suggested, you can organize Transaction Scripts into classes in two ways. The common one is to have several Transaction Scripts in one class, where each class defines a subject area of related scripts. The other way is to have each Transaction Scripts in its own class.
Figure 2.2: Transaction Script to calculate revenue recognition & tell how much it cost
Transaction Script organizes the business logic of the software by procedures where each procedure handles a single request from the presentation layer. The above example indicates that Calculation of revenue recognition for using Transaction Script works as: one method to calculate revenue recognition on contract and one to tell how much revenue on a contract has been recognized by a certain date. (Fowler, 2003)
2.3.3 Performance & Simplicity of Domain Logics
About the performance and simplicity of the above Domain Logics Fowler said, the beauty of Transaction Script is its simplicity. Organising subsystem of Transaction Script into sub-procedures is natural for applications with only a small amount of logic, and it contains little overhead either in performance or in understanding.
The simplicity and ease of Table Module is to use it with backing data structure that’s table oriented. The tabular data is normally the result of a SQL call and is held in Record Set.
“A Record Set is usually something that you won’t build yourself, provided by the vendor of the software platform you working with. Examples include the data set of ADO.NET and the row set of JDBC.” (Fowler, 2003, p. 508)
There is nothing useful said about the performance of the Table Module but that can be still examined in the chapter seven to find out the performance of the each individual domain logic. However for the simplicity of development described by Dan Agonists (2004), Table Module can also be used to abstract frequently used sets of data created by joining multiple tables together in a view or query. This makes dealing with more complicated data much easier to make a call to the Business Logic Components.
2.3.4 Disadvantage/s of Domain Logics
For the Transaction Script Fowler (2003) suggested, as the business logic gets more complicated such as adding further changes to the business logic or the initial system is very big. It gets progressively harder to keep it in a well-designed shape. One of the most revealed problems that developer will confront is its duplication between transactions. Since the whole point is to handle one transaction, any common code tends to be duplicated.
On the other hand, Fowler as well as Transaction Script illustrated some disadvantages of the Table Module as: table module doesn’t give you the full power of organizing complex logics. In Table Module there is no direct instance to instance relationship exist and polymorphism doesn’t work. For Table Module you cannot use some of the Object Oriented Patterns such as inheritance and etc.
2.4 Patterns That Increases Domain Logic Maintainability
For speeding up development time some other pattern has to be considered too. The first set of patterns comprises the architectural patterns, which drives the way in which domain logic communicate to the database. Data Source part of the software development process is a crucial point that most developers usually do not considerably take it seriously. So, it’s worth doing to separate SQL access from the domain logic and place it in separate classes. The best way is to base them on table structure of the database so that you have one class for each database table.
There are many data source gateways that each is designed to provide mapping to specific domain logic. The most appropriate and well designed for the above domain logics (Transaction Script & Table Module) indicated by Fowler (2003) are Table Data Gateway and Row Data Gateway. A data source layer that fits well with the Transaction Script is Row Data Gateway. It is a layer that you start with implementing it first and then add up domain logic to communicate with it, particularly, when you see repetitive code in multiple Transaction Scripts. Row Data Gateway is well used with the Transaction Script. It nicely factors out the database access code and allows it to be reused easily by different Transaction Scripts. If you use Transaction Script with Row Data Gateway, you may perceive that business logic is repetitively used across multiple scripts; logic that will make sense in the Row Data Gateway, which is often good as it reduces duplication in the business logic.
A data source layer that fits well with the Table Module is Table Data Gateway suggested by Fowler (2003): A Table Data Gateway holds all the SQL code for accessing a single table such as selects, inserts, deletes, updates. A Table Data Gateway thus goes well with the Table Module. If all your updates are done through the Table Data Gateway, the return data should be based on views rather than actual table that reduces coupling between your code and the database. Fowler also suggested that Table Module may include queries as factory methods. The alternative is Table Data Gateway, but the disadvantage of this is having an extra Table Data Gateway in the design. The advantage is that you can use a single Table Module on data from different data sources, since different Table Data Gateway is used for each data source.
The most important points of literature review carried for this project are presented in this chapter. Section one of the literature review explained the overall software architecture that would be required for this project to build a flexible software. Section two of the literature review pointed out various designing patterns that each would leads to different level of flexibility and maintainability. Two different domain logics explained that each would require different way of building it, such as Transaction Scripts and Table Module, and as well different data source layers that each is specified for particular domain logic.
CONTINUE reading -:)