Abstract—Layering is a concept widely used in computer and software modeling. Many modern information systemsare designed and built using a layered model where the function of each layer is specified and well defined. In this paper we will be discussing the layer whose responsibilities include data extraction, manipulation and provision of data to the rest of the application. Common design problems that designers face while designing object oriented system can be resolved by using design patterns. These patterns are reusable solutions used heavily in application framework design. Formal methods are mathematical techniques used to construct models that can be proved for consistency, completeness and correctness of computerized systems. We have applied formal methods to data access layer patterns which has resulted a verifiable recipes for solving data access layer design problems. Our formal models are described using VDM++ specification language and are analyzed and validated using the VDM++ Toolbox.

Keywords—Enterprise applications, Reusable components,Formal methods, Design patterns, VDM++, Validation

I. INTRODUCTION

During the early days of commercial software development, the processes and practices were not mature enough to cater for the huge demand of high quality software which was to run on better and faster hardware. The term “software crisis” was coined to describe this phenomenon. In the following decades, various subdivisions of software engineering have surfaced that try to address issues related to rapid, reusable software design thus making it easier to build complex software quickly. Software architecture is one such sub division of software engineering that deals with the design of software components and modules and the interactions between them. Software architects strive to produce simple, consistent, reusable and repeatable design for their

applications. These characteristics are what differentiate well designed software from a poorly designed one.

Software design patterns are abstract solutions to problems related to software structure, software components and the interactions between these. These patterns provide a wire-frame structure on top of which an implementer builds an implementation, avoiding any implementation level detail which would violate the structure provided by the pattern. Because software design patterns are abstract and are not specific to any domain, hence are reusable.

In this paper, we model two data access layer design patterns using formal methods. Formal methods are a mathematical modeling methods based on the principles of set theory and predicate logic which are used to build verifiable models of software systems. With the modeling of these patterns by describing their formal specifications, we expect to produce structures that are reusable and mathematically verifiable thus retaining the properties of both patterns and formal methods.

The use of formal methods in the field of software architecture has been explored extensively by researchers. Some researchers have proposed the use of domain specific Architecture Description Languages that are based on formal specifications to model software architecture [1]. Alencar etal., have introduced a formal approach to model design patterns at many different architectural levels including pipes-and-filters design pattern, layered system and others[2]. A lot of work has been done to formally model object oriented “gang of four” design patterns [3], [4] and object oriented frameworks [5]. In [6], we see an example of a formal modeling language specifically used for modelingdesign patterns. In this paper, we have modeled data access layer design patterns using VDM++ that are used extensively in building data access components in modern information and software systems.

Formal model of data access object and the transfer object assembler design pattern are described in this paper. The data access object pattern deals with accessing multiple data sources whereas the transfer object assembler deals with the conversion of objects retrieved from the data source into

Designing Verifiable and Reusable Data Access Layer Using Formal Methods and Design Patterns

Faheem Sohail, Farooq Zubairi, Nabeel Sabir and Nazir Ahmad Zafar

Faculty of Information Technology, University of Central PunjabPlot No. 31-A, Main Gulberg, Lahore, PAKISTAN

Tele: +92-42-5755314-7; Fax: +92-42-5710881Emails: {faheem.sohail, farooq.zubairi, nabeel.bloch, dr.zafar}@ucp.edu.pk

International Conference on Computer Modeling and Simulation

978-0-7695-3562-3/09 $25.00 © 2009 IEEE

DOI 10.1109/ICCMS.2009.83

167

a form required by the rest of the application. Rest of the paper is structured as given below.

In sections II, we discuss the significance of software design patterns. In section III, the use of design patterns in enterprise applications, specifically at the data access layer is argued. The identification of a link between formal methods and design patterns is discussed in section IV. In section V, we present the formal models of design patterns in the scope of this paper. Finally, conclusion and future work are discussed in section VI.

II. IMPORTANCE OF DESIGN PATTERNS IN SOFTWARE

DESIGN

The level of human understanding in any knowledge area can be determined by the use of pattern in that area [7]. Software design patterns are an instrument for expressing repeated design organization [4] and can be repetitively used to address comparable design problems in analogous architectures. Patterns are a key to good software architecture because patterns can be used to arrive at architectures just as a mathematical theorem can be proved from a set of axioms [8]. Identifying design patterns requires experience of designing multiple applications or components that share some common characteristic. When these common characteristics are extracted and made abstract and generic, they can be applied and reused. Various design patterns are identified by practioners of diverse sub domains such as software architecture [9], general object oriented designs[10], web applications development, enterprise application development [11], enterprise application integration [12],software implementation [13], software development for portable devices [14], embedded and complex systems [15]and many more.

Design patterns are used to solve design problems. A design problem deals with the organization, creation and interaction of software components and modules as opposed to the algorithmic or computational aspects. Software design patterns are frequently published in the form of catalogs. Each catalog serves as a grouping of similar patterns. For example, structural patterns define ways to compose objects to obtain new functionality of a system. Similarly, creational patterns address issues related to object construction. The behavioral patterns are specifically concerned with the communication between the objects of a system [16].Patterns can also be classified based on the nature of applications, components or modules where they will eventually be implemented. For example, data access layer patterns will be used to model modules or components related to data access. Integration patterns are used for defining relationships between two or more applications. Some other properties of the software design patterns can be listed as: (i) are abstract, (ii) cannot be coded but have their implementations, (iii) are well documented and their use improves the readability of the code which in turn increases

maintainability, (iv) promote reusability, and (v) increase compliance to the object oriented principles.

III. DESIGN PATTERNS IN ENTERPRISE APPLICATIONS AND

INFORMATION SYSTEMS

Information systems are software systems that are used to provide quick access to relevant information primarily in a business setting. These systems are usually data intensive.Because of this reason, information systems frequently rely on multiple data sources. Also, data transformation from one format to another may also be frequently required. To divide functionality between various components or modules, information systems are divided into layers. Each layer performs a well defined role. Usually, the data access layer is the closest layer to the database. This layer extracts data, transforms it and passes it on to the business layer. The business layer applies business rules to the data. This processed data is provided to the presentation layer for display or transmission purposes.

The layering mechanism has a lot of benefits. It includesincreased modularity, removes unnecessary coupling between components, increases cohesion and promotes reusability, resulting in a maintainable and well structured system. Merits of a layered approach in designing an Enterprise Application and how this architecture evolved are discussed in detail by Fowler [11]. Patterns that specifically relate to building data intensive applications are known as enterprise design patterns. The patterns that belong to the enterprise suite are always limited to a layer of the application. In this paper, we present the formal model of two most useful data access layer design patterns, the “data access object” and the “transfer object assembler”. These patterns are a part of the enterprise pattern catalog published by Sun Microsystems [17].

IV. FORMAL METHODS AND DESIGN PATTERNS

Formal methods are more related to the field of software engineering that uses mathematics, specifically, discrete mathematics, for the modeling of software systems. The traditional use of formal methods has been for the modeling of critical systems. Bowen, who is a renowned researcher in the field of formal methods, describes the importance of formal methods in the following way. “Just because a system has passed unit and system testing, it does not follow that the system will be bug free. That is where formal methods offer considerable advantageous over more traditional methods when developing systems where high integrity is required. Formal methods allow us to propose properties of the system and to demonstrate that they hold. They allow us to examine the system behavior and convince ourselves that all possibilities have been anticipated [18].”

Due to the massive growth in hardware performance, more complex computer systems have been developed [19]. These systems run for nuclear power plants, trains systems, and

168

financials infrastructure among countless other things. The impact of failure of such systems has drastically increased. Critical systems can be categorized in three ways. Safety critical systems are those whose failure results in human injury or loss of life. Business critical systems impact the financial well being of an enterprise or an individual. Finally, mission critical systems are those whose failure impairs the goal of a given mission [20].

“If formal modeling is applied at the level of style, analyses can be extended to any system that conforms to the style [1]”. We use this statement as our primary motivation to formalize design patterns. In a traditional software development lifecycle, the “level of style” is the design of the system which is translated into executable code during implementation phase. Design patterns are utilized during thedesign phase. Our objective is to formalize patterns so that formalism in ingrained into the building blocks of systems. This will allow any design implementation to conform to the principles of the pattern.

Even though patterns are of numerous types, we arefocusing on enterprise applications patterns. If categorized, enterprise applications are business critical in nature. This is because most enterprise applications handle huge amounts of critical data on which complex processes and rules operate on [11]. If an enterprise application fails to provide reliable and accurate services to the stakeholders, irreversible damage may occur not only to the financial status or the well being of the enterprise but to its reputation and its customers. Enterprise application design patterns, that are the basic design construct of such applications, are a perfect candidate for formalism. Traditionally, formal methods are considered feasible for control systems. From our research, we propose its use in business systems as well.

As general design rules, uniformity and consistency of modeling approaches are desired. Consider an enterprise application which we model using a combination of formal techniques and informal techniques. During implementation, it is highly likely that our application will be composed of large number of open source and commercial components and frameworks. This will result in a combination of formal and informal approaches in our overall implementation methodology. We believe that our critical system may collapse due to the failure of even a single open source or off the shelf component used in our system that was not formalized. In such a scenario, a good approach would be for framework developers to use formal design patterns to model their wares resulting in an all encompassing formalism based software development methodology.

This idea can be put across in another way through the well known English idiom, “a chain is only as strong as its weakest link”. In our claim, the chain is our system modeled by mix of modeling techniques whereas the weakest link or entity is a component which has not been modeled using any mathematical or formal technique.

V. FORMALIZING DESIGN PATTERNS

The structure of any design pattern can be thought of as a sequence of relationships between participating classes. This sequence can be determined from the UML sequence diagram of that pattern. These relationships are usually well defined. We want to prove the compliance of any implementation of a pattern with the original pattern. The essence of the abstract pattern should be retained in its implementation. Our formalization methodology works on the concept discussed above. VDM++, which is an object oriented formal language is used to model our base object orientation model and patterns.

A. Formal Specification of Object Orientation

Our efforts to formalize design patterns would be flawed and incomplete if we do not formalize object orientation first. Following this approach is mandatory because the architectural basis of software system design is design patterns whereas the base of design patterns is object orientation. This approach has been adopted by several others who have formalized patterns [4], [3]. As we proceed with our research, our object orientation formal model will get mature and robust catering to the needs of all patterns.For all patterns, the object orientation model will serve as a common basis on top of which patterns and their structures will be verified. The formal class definitions of method signatures, interfaces, class definition, variable definitions, relations between classes and patterns are given in the following using VDM++.

Method Signatureclass MethodSignature

typesparameter :: token

instance variablesaccessModifier : Visibility; name : Global’mSignature;parameters : set of parameter;

returnType : token;end MethodSignature

Interface: An interface can be considered as a set of method signatures. We ensure as part of the pre condition that the same signature is not repeated in a given interface.class Interface

instance variables public signatures : set of signature;

public name : Global’interfaceName; operationsaddMethodSignature(sig : Signature)ext rd signaturespre sig not in set signaturespost signature = signature union {sig};end Interface

Class Definition: An object oriented class can be considered as a set of interfaces which the class implements and a set of signatures that are part of the class definition.class ClassDef

instance variablesname : seq of char;

169

interfaces : set of Interface;signatures : set of Signature;

operationscontainSignature()b : boolext rd signatures : set of Signaturepre sig <> null and len signatures>0post true;end ClassDef

Variables Definition: A class consists of different type of variables. Name, visibility showing either public or private, it is static or not, final mentioning that the variable cannot be override, type, and default initialization are some of the characteristics of it. In our model we have created Attributesclass represents the attributes in our specifications as below. class Attributes

instance variablesvisibility : token;isStatic : bool;isFinal : bool;varType : token;

name : seq of char;initilization : token;

end Attributes

Relation: A relationship class describes the type of relationship that could exist between two given classes. Patterns discussed in this paper can be modeled by defining association relationships between the participating classes. These relationships are dictated by the pattern structure. class Relationtypes

relations = Association | Aggregation | Composition;instance variables

relationship : (ClassDef-> ClassDef)-> relationsend Relation

Pattern: An object oriented design pattern can be considered as a sequence of methods or operations to be called. For example, the specification described below has an operation by the name of isValidPattern. It checks if the sequence of relationships of a particular pattern is valid or not.class Patterntypes

pType = InterceptingFilter | FrontController | DAO | TransferAssembler;instance variables

relations : seq of Relation;operationsaddRelation(rel:Relation)ext wr relations : seq of Relationpre rel <> null and rel not in set relations post relations = relations ^ [rel];isValidPattern(relation : Relation`relations, classA : ClassDef, classB : ClassDef)flag:boolext rd relations : seq of Relationpre elems relations > 0 post forall r in set relations & rel(classA,classB,relation) in set r(i).relationship;end Pattern

B. Formalization of Enterprise Data Access Layer Patterns

Data Access Object (DAO) Pattern: Access to data depends on its source. Access to persistent storage, such as to a database,

varies greatly depending on the type of storage (relational databases, object-oriented databases, flat files, XML files and so forth) and the vendor implementation. Data Access Object (DAO) encapsulates access to the data source. The DAO manages the connection with the data source to obtain and store the data.

DAO Factory: The DAO pattern can be made highly flexible by adopting the Abstract Factory [GoF] and Factory Method [GoF] patterns. When the underlying storage is not subject to change from one implementation to another, this strategy can be implemented using the Factory Method pattern to produce a number of data access object needed.class DAOFactoryinstance variablesORACLE : int;SYBASE : int; operationsinitialize(oracleD:int,sybaseD:int)pre truepost ORACLE = oracleD and SYBASE = sybaseD;getFactory(whichFactory:int)out :DAOFactorypre truepost if whichFactory = ORACLE then out = mk_OracleDAOFactory() else if whichFactory = SYBASE then out = mk_OracleDAOFactory() else out=NULL; end DAOFactory

Factory Implementation: Factory can be implemented by asmany data sources as we need in our application. This makes application more flexible and layering implementation of different data sources.class OracleDAOFactory is subclass of DAOFactoryinstance variables

DRIVER : seq of char; DBURL : seq of char;

Connection : token; operationsinitialize(driverIn : seq of char,dburlIn : seq of char)pre truepost DRIVER = driverIn and DBURL = dburlIn;createConnection(conn : token)out:boolpre truepost Connection = conn and out = true;closeConnection()out:boolpre truepost Connection = Null and out=true;end OracleDAOFactory

class SybaseDAOFactory is subclass of DAOFactoryinstance variables

DRIVER : seq of char; DBURL : seq of char;operationsinitialize(driverIn : seq of char,dburlIn : seq of char)pre truepost DRIVER = driverIn and DBURL = dburlIn;createConnection(conn : token)out:boolpre truepost Connection = conn and out = true;closeConnection()out:boolpre truepost Connection = Null and out = true;end SybaseDAOFactory

170

Generic DAO: Generic DAO manages the generic activites for all data sources. Normally we write database selection, updation and deletion queries so that if change requires only one class has that effect and other application has no effect to change. class GenericDAOtypes

BaseWrapper :: token;operationsinsert(bWrapper : BaseWrapper)rows:intpre truepost true;update(bWrapper : BaseWrapper)rows:intpre truepost true;delete(bWrapper : BaseWrapper)rows:intpre truepost true;select(bWrapper : BaseWrapper)wWrapper:BaseWrapperpre truepost true;end GenericDAO

DAO Implementations: The implementations of different data sources can be done by implementing GenericDAO class defined above and making any specific changes according to the data source requirement.class XYZOracleDAO is subclass of GenericDAOtypes

BaseWrapper :: token;instance variables

oracleFactory : OracleDAOFactory;conn : token;gDao : GenericDAO;

operationsInitialize(oracleFactoryIn : OracleDAOFactory,connIn : token)pre truepost oracleFactory = oracleFactoryIn and conn=connIn;createConnection()out:boolpre truepost oracleFactory.createConnection(conn);insert(bWrapper : BaseWrapper)rows:intpre truepost gDao.insert(bWrapper);update(bWrapper : BaseWrapper)rows:intpre truepost gDao.update(bWrapper);delete(bWrapper : BaseWrapper)rows:intpre truepost gDao.delete(bWrapper);select(bWrapper : BaseWrapper)wWrapper:BaseWrapperpre truepost wWrapper = gDao.select(bWrapper);end XYZOracleDAO

2) Transfer Object Assembler

Transfer object assembler used to build the required model or submodel for the business object or the DAO object. The transfer object assembler uses transfer objects to retrieve data from various business objects or data access objects that define the model or part of the model. Mostly, business object is separate with the database objects with respect to the information this pattern is used to make an interface between business objects and data access objects.

Transfer Object: The transfer object is a composite transfer object that is constructed by the transfer object assembler and

returned to the client. This represents the complex data from various components that define the application model or the business objects.class TransferObject is subclass of ClassDef

instance variables--set of attribute from ClassDef

end TransferObject

Business Object: Business object is a role that can be fulfilled by a bean class, or DAO. When the assembler needs to obtain data directly from the persistent storage to build the transfer object, it can use a DAO.class BusinessObject is subclass of ClassDef

instance variables--set of attribute from ClassDef

end BusinessObject

Transfer Object Assembler: Assembler class is basically used to tranfer business to tranfer object and transfer object to business object. Here we normally write the code to change different attributes mapping. class Assembler is subclass of ClassDefinstance variablesoperations

TOTransferObject(BO : BusinessObject)TO:TransferObject

pre true post true;

TOTransferObject(SBO : set of BusinessObject)STO:set of TransferObject

pre true post true;

TOBusinessObject(TO: TransferObject) BO :BusinessObject

pre true post true;

TOBusinessObject(STO: set of TransferObject) SBO :set of BusinessObject

pre true post true;end Assembler

VI. CONCLUSION AND FUTURE WORK

Our objective of this research is to propose and formalize reusable components for systems development which can be used at an abstract level without giving the implementation details. To achieve this objective, we have presented a formal specification of two most important enterprise data access layer design patterns using VDM++. The VDM++ is a formal techniques used to model and construct software systems supporting object oriented technology. As formal methods are powerful at an abstract level that is why, their use was made increasing reusability in addition to increasing reliability ensuring correctness of a system. After describing formal specification of the design pattern, we observed that the formal nature of this design will trickle down to any implementation of the design of a system. We believe that these reusable components will result in consistent and uniform architectures that use formalism across the entire application instead of just formal custom code supported by informal reusable components.

171

We proposed a formal methodology rather than a detailed approach as followed in [9], [3]. We first provided a formal specification of the basic object oriented constructs and then reused it for constructing formal models of the above design patterns. Some similar work was found in [22], [23], [24] which was taken as a starting point for this resaerch.The relative ease by which we were able to formalize thesepatterns using VDM++ can be justified and attributed to the fact that an object oriented formal specification language was used to model object oriented concepts and constructs. Many concepts, that we would have had to model using a non-object oriented language, for example Z notation, came inherently while using VDM++. The formal specification of the next layer design pattern of the enterprise application is under progress and will appear soon in our future work.

VII. REFERENCES

[1]Allen, R. J., "A Formal Approach to Software Architecture",CMU Technical Report CMU-CS-97-144, Vol. 6, 1997.

[2]Alencar, P.S.C., Cowan, D.D. and Lucena, C.J.P., "A Formal Approach to Architectural Design Patterns", FME96: Industrial Benefit and Advances in Formal Methods, 1996.

[3]Reynoso, L. and Moore, R., “Gof Behavioral Patterns: A Formal Specification”, United Nations University, International Institute for Software Technology, 2000.

[4]Cechich, A. and Moore, R., "A Formal Specification of GoF Design Patterns", International Institute for Software Technology, The United Nations University, Vol. 1, 1999.

[5]Crnkovic, I., et al., "Object Oriented Design Frameworks: Formal specification and some Implementation Issues", Proc. Of 4th

IEEE Int’l Baltic Workshop, 2000.

[6]Eden, A.H., "Formal Specification of Object-Oriented Design", International Conference on Multidisciplinary Design in Engineering CSME-MDE, Montreal , 2001.

[7]Coad, P., "Object Oriented Patterns", Communications of the ACM, Vol. 5 (4), p102-103, 1994.

[8]Beck, K., and Johnson, R., "Patterns Generate Architectures", ECOOP'94, Springer-Verlag, 1994.

[9]Shaw, M., “Some Patterns for Software Architecture”, Vlissides, Coplien & Kerth (eds.), Pattern Languages of Program Design, Vol. 2, Addison-Wesley, pp. 255-269, 1996.

[10] Gamma, E., Helm, R. Johnson, R and Vlissides, J., “Design Patterns: Elements of Reusable Object Oriented Software”,Addison Wesley Professional Computing Series, 1995.

[11] Fowler, M., “Patterns of Enterprise Application Architecture”Addison-Wesley, 2003.

[12] Hohpe, G. Woolf, B., and Brown, K., “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions”, Addison-Wesley, 2004.

[13] Beck, K., “Implementation Patterns”, Addison-Wesley, 2008.

[14] Narsoo, J., and Nawaz M., "Identification of Design Patterns for Mobile Services with J2ME", The Journal of Issues in Informing Science and Information Technology, Vol. 5, 2008.

[15] Gay, D., et al., "Software Design Patterns for TinyOS", ACMTrans, Embedd Computing, Vol. 6 (4), 2007.

[16] Bowen, J.P., and Stavridou, V., "Safety-Critical Systems, Formal Methods and Standards", IEE/BCS Software Engineering Journal, Vol 5, 1993.

[17] Alur, D., Crupi, J., and Malks, D., “Core J2EE Patterns: Best Practices and Design Strategies”, Prentice Hall/Sun Microsystems Press, 2003.

[18] Bowen, P., and Hinchey, M., "Ten Commandments of Formal Methods", IEEE Computer Society, Vol. 10, 1995.

[19] Bowen, J., Stavridou, V. P., "Safety-Critical Systems, Formal Methods and Standards", IEE/BCS Software Engineering Journal, Vol. 1(2) 1993.

[20] Charatan, Q., and Kans, A., “Formal Software Development from VDM to Java”, Palgrave Macmillan, 2003.

[21] Garlan, D., and Shaw, M., "An Introduction to Software Architecture", CMU Software Engineering Institute Technical Report, CMU/SEI-94-TR-21, ESC-TR-94-21, Vol. 6, 1994.

[22] Reza, H. and Grant, E., “A Formal Approach to Software Architecture of Agent-base Systems”, Int’l Conference on Information Technology, Vol. 1, pp. 591-595, 2004.

[23] Dong, J., et al., “Composing Pattern-based Components and Verifying Correctness”, Journal of Systems and Software, Vol. 80 (11), pp. 1755-1769, 2007.

[24] Taibi, T., “Formal Specification of Design Patterns Relationships”, Proc. of 2nd Int’l Conference on Advances in Computer Science and Technology, pp. 310–315, 2006.

172