Applying formal methods to j2ee design patterns

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.


1.1 Overview

During the early days of commercial software development, the processes and practices were not mature enough to cater the huge demand of high quality software. 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 and 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 differentiate betweenwell designed and poorly designed software.

Software design patterns are abstract solutions to problems related to software components and their interaction. These patterns provide a wire-frame structure on top of which an implementer builds an implementation. Because software design patterns are abstract and are not specific to any domain, hence are reusable.

Enterprise Applications are frequently designed and developed using a layered approach where the entire application is divided into layers. Each layer in such architecture performs a specific and well defined function. Object oriented design patterns exist for these layerswhich provides reusable solutions to commonly occurring design problems. These patterns are frequently used to build different layer application frameworks which are in turn used to develop enterprise applications. Formal methods are techniques which are used to construct mathematically verifiable models of systems.

In this research importance of formal methods has been demonstrated by applying them in the development of design patterns which is an important part of software development.Formal methods are mathematical modelling technique based on the principles of set theory and predicate logic which are used to build verifiable models of software systems. Modelling of these patterns will produce structures that are reusable and mathematically verifiable thus retaining the properties of both patterns and formal methods. A good design makes software more reusable and maintainable. In development of any system either hardware or software early analysis and design phase is more critical in subject of errors. Hardware designers use specific languages to specify their design but in software engineering early stages like requirements engineering and requirements analysis have not yet got proper tools and methods support. There is a rare use of specification language and design language in software development. In software industry, highly qualified development of safety critical systems is a hot subject, because protection of safety of human, environment and protection of valuable assets are of vital importance. So there is a need to switch from adhoc and manual methods to rigorous engineering discipline. In order to contribute in this effort, integration of formal methods in existing software engineering life cycle has been demonstrated in this research. Integrating a formal method such as model checker into a hardware design is relatively easy because other tools are already a standard part of analysis and design process at many hardware companies but this is not the case in software analysis and design. The use of proper specification language such as Z, which is a well known formal method, compels us to ensure the correctness, reliability and consistency at analysis and design stage, before we start the actual implementation of the software system. As already mentioned, the modelling under consideration in this research is specifying design approaches in some formal manner. The existing software engineering approach to analysis and design is the use of Unified Modelling Language (UML). This is an informal approach to system development as it has no mathematical foundation. UML class diagram are used for analysis and to represent the static aspects of and design and then this approach is integrated with the new one, which is the use of formal method in terms of Z notation. Z notation is based on set theory and first order predicate logic. A formal model at abstract level has been developed in Z specification language. This model is finally verified using a Z/EVES toolset. [13]

1.2 Purpose of Research

The purpose of this thesis is to contribute in the effort for making the use of formal methods common in industry for the development of design approaches which are useful in application development. Some development motivations are also considerable like, testing cannot take place until some implementation is available, so correcting errors uncovered by testing could involve retracing many steps and undoing work previously done. The earlier the error occur the more work this involves. If testing is the only approach to error detection then errors in the specification involve the greatest amount of work to rectify. Testing can only help to uncover errors it cannot guarantee the absence of them. Since, for any application, it is impossible to test every set of input values, residual errors will always have to be accepted. Testing is always carried out with respect to requirements as laid down in the specification. If the specification document is in any way ambiguous it is open to interpretation, and hence misinterpretation, making testing a rather inexact science.

Objectives in this research includes

* Applying formal methods to J2EE design patterns.

* Developing the model of design patterns which is more reliable, using Z notation.

* Integration of formal and informal approaches.

Formal notations have now reached to the level of maturity that some of them are being standardized e.g. LOTOS, VDM and Z. Formal methods are ideal for ensuring the correctness and reliability of system. Although formal methods can be used at any stage of software system development but they are particularly suited at the initial stages of system development like requirements analysis and design. This is because capturing the errors and inconsistencies at initial stages could greatly affect the time and cost spent in later stages. If the correctness and completeness of requirements will not be guaranteed at initial stages, it is likely that inconsistencies will propagate to later stages which will become more difficult to cater at that time of the development [25].It is fair to say that the practical use of formal method is limited till now, but this is not due to that formal methods have some underlying drawbacks but due to some misconceptions as discussed in [4].

Another reason for hindrance to use formal methods is that it is a new technique and software analysts, designers and programmer are reluctant to switch from existing techniques to this new one and software development reliability is of paramount concern.

1.3 Related Work

As the nature of business changes we must have to ripple that change into the application which used to manage business. For this reason some specific design techniques were develop to handle business needs and their behaviour. Enterprise software applications provide internal services to an enterprise in some focused business domain such as human resource or accounting, or could also provide services to customers of the enterprise in question. Being a class of computer software, all enterprise applications share a certain set of properties which are discusses below.

Modern enterprise applications are distributed, multi-tiered and modular in nature and need to have high reliability. All enterprise applications have a data source which in most cases is a Relational Database Management System but can also have other sources such as XML, Excel etc. Multiple data sources are common. Access to these data sources will be required by hundred of concurrent users. Enterprise applications often interact with other software systems to access data or delegate computational responsibility. All these aspects of Enterprise applications make designing and maintaining an enterprise application a challenge. While developing enterprise applications, the focus is on good structural design so they are easily maintainable.

One of the ways to organize an application is by dividing the functionality into layers. Typical examples are the Operating System, the logical OSI network layers etc. Enterprise applications are frequently divided into layers each of which performs a specific and well defined functionality. The outermost layer of an enterprise application is the presentation layer which serves the purpose of an interface between the application and the outside world. Typically this is a graphical user interface meant for a human user. Other interfaces may exist as well. Next is the service layer, also known as the business layer, which performs the core functionality of the system. The data access layer hides the data source from the service layer allowing us to change the data source without impacting the rest of the application. The data source could be a relational database system, flat files, a directory, or a remotely accessible external system.

The layering mechanism increases modularity, decreases unnecessary coupling between components, increases cohesion and promotes reusability, resulting in a maintainable and well structured system. Merits of a layered approach in designing Enterprise Application and how this architecture evolved are discussed in detail by Fowler [35].

Patterns that specifically relate to building enterprise 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 thesis, we present the formal model of two widely used presentation layer design patterns, the Intercepting Filter pattern and Front Controller pattern. These patterns are a part of the enterprise pattern catalogpublished by Sun Microsystems [42].

1.4 Research Area

1.5.1. Overview

Design patterns are reusable components which are used in the application development. A good design can only be achieved using the appropriate and good selection of design patterns. Design patterns provide access to proven methodologies for solving general problems and the ability to use the collective knowledge and experience of the IT community to improve the quality of your own applications. You can use patterns to help you organizing code in proven ways to solve well-understood problems. Patterns are reusable components encapsulating functionality that is common across many applications increase productivity when building your own components following a certain set of design patterns.

There are many proven design patterns that help solving problems relevant to the any design layers. Choosing the correct patterns leads to more maintainable code that separates unrelated tasks and functionality. Using these patterns leads to better modularity, higher cohesion, and lower coupling in your application these are essential characteristics of well-designed systems.

In software engineering, a design pattern is a general reusable solution to commonly occurring problems. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems. Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative scopes [41].

Some other properties of software design patterns are:

* Patterns are abstract.

* Patterns themselves cannot be coded but their implementations are.

* Many patterns are well documented and their use improves the readability of the code which in turn increases maintainability.

* Patterns promote reusability.

* Patterns are components which can be used in different situations according to its usage.

* Patterns increase compliance to object oriented principles.

* Patterns increase code readability and maintainability.

* Patterns provide Layering between applications.

* Patterns provide transparency between application components.

* Patterns provide application flexibility.

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this objectcreation.

Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives us program more flexibility in deciding which objects need to be created for a given case. These types of patterns provide user to focus on application core logic rather than thinking on how to deal with objects creations these patterns take the responsibility of creation activities we just ask than to create other specific knowledge gathering [41].

In software engineering, structural design patterns ease the design by identifying a simple way to realize relationships between entities. Structural patterns help composing groups of objects into larger structures, such as complex user interfaces or accounting data. Structure patterns focus on the application structure interfacing and layer of application is also comes under structural patterns. One very important feature of structural patterns is that they make different layer transparent about others functionality and focus on interfaces designing. In perspective of component based development these patterns play important role by providing interfaces to different group of people who can work parallel and due to transparency between modules everyone knows their work. Structural Design Pattern focuses on the relationships/interfaces between entities and objects [41].

In software engineering, behavioural design patterns identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication. Behavioural patterns help you define the communication between objects in your system and how the flow is controlled in a complex program. The behaviour patterns deal with the application behaviour. These techniques normally tackle the situation where software has to be performed upon any particular user action for example when user clicks a button how software should behave. These patterns help to handle such situation efficiently.

The use of patterns in any field indicates progress of human understanding.In computer science, rather more specifically in software engineering, patterns are a key element of software architecture because patterns can be used to derive architectures, much as a mathematical theorem can be proved from a set of axioms [30] [31].

Software design patterns are a mechanism for expressing design structuresand can be repeatedly used to address similar design problems in similar architectures. Design patterns have been extracted and repetitively applied in diverse sub domains such as software architecture, general object oriented design, web application development and enterprise application development, enterprise application integration, software implementation, software development for portable devices, embedded systemsand many more [33] [34] [36] [37] [38] [39].

An object oriented design pattern is a reusable and abstract solution to a commonly occurring design problem. This solution is defined in terms of classes, their instances, the relationships between the instances and the delegation of responsibility amongst them. The most important term in the definition above is design problem. A design problem relates to the structural, creational, behavioural or other aspects of a software system as opposed to the algorithmic or computational aspects. We can classify design patterns on the basis of the problem they solve. For example, structural patterns define ways to compose objects to obtain new functionality; creational patterns address issues related to object construction whereas behavioural patterns are specifically concerned with communication between objects [40] [41].

1.5.2. Applications

Formal Methods support the description of the behaviour of systems in an abstract manner. Of particular relevance is the term abstract - programming languages for example clearly allow the behaviour of systems to be described. However, they describe this behaviour in a prescriptive manner i.e. a program defines a single implementation. In contrast, using devices such as non-determinism, FMs typically support more abstract description, where the specification characterizes a set of possible implementations.

Formal descriptions of systems are amenable to formal manipulation and analysis. For example, powerful theorem proving and model checking tools now exist. These can be used to determine what properties system descriptions exhibit. Furthermore, this analysis can often be performed in an automatic, or at least, semi-automatic, manner.

To indicate the spectrum of possible exotic applications, there is a list some possible topics where we know some formal methods work has been done or where we have some intuition that the area could be amenable to formal interpretation.

* Formal description of games (children games, board games, electronic games).

* Formalisation and verification of legal, medical, bureaucracy procedures and protocols.

* Formal representation of novels (narrative text) / theatre / movie plots.

* Personal/social behaviour of humans and virtual agents.

* Natural language issues.

* Formal user modelling for Human Computer Interaction. A major element of this is formally interpreting cognitive architectures and it has some history.

* Formal modelling of biological systems.

* Formal modelling in physics.

* Formal modelling of safety critical systems.

1.5.1. Limitations

Formal methods have undoubted power and undoubted advantages but they also have in their present form, severe limitations which have militated against their widespread adoption. Some of these limitations are inherent in formality itself: not everything in a software project can be handled formally no matter how powerful the formalism. But some are due only to the undeveloped state of formal methods and can be relaxed by the right kind of advance. We need to understand how to choose the most appropriate language for each description and we need a repertoire of composition and other operators that can act on those descriptions to derive new descriptions. Today's formalisms tend to be isolated from one another, research concentrating on improving each formalism in its isolation we need to build many bridges between different formalisms, converting our existing archipelago into the solid ground on which software developers should be able to stand as discussed in [43].

1.5 ProblemStatement

Our work includes:

* Formalizing the selected standard set of common design problems in Z notation as specified in IFX standard version 1.4.

* Focusing on specification of more useable design patterns of Enterprise Application Layers.

* Creating a specification library for reusable formal components.

* Model checking of resultant formal model using Z/EVES tool set formalizing the selected standard set of requirements of common design problems in Z notation as specified in IFX standard version 1.4. [15]

1.6 Formal Methods

Formal method is an area of computer science that is concerned with the application of mathematical techniques to the analysis, design and implementation of computer software and hardware. Formal methods provide frame work with in which one can specify, develop and verify system in a systematic manner. Formal specification is the use of mathematics to specify the desired properties of a computer system. Software, currently, used in computers that have been developed using informal techniques has itself become so complex that it is not trust-worthy and has caused human injury and death as a result. In it is provided a list of incidents caused by poor system development and it is updated annually [31] [28].

In computer science and software engineering, Formal Methods are particular kind of mathematically-based techniques for the specification, development and verification of software and hardware systems. The use of formal methods for software and hardware design is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analyses can contribute to the reliability and robustness of a design.

Formal methods have the potential to improve both quality and productivity in software development.

* To enhance early error detection.

* To develop safe, reliable, secure software-intensive systems.

* To facilitate verifiability of implementation.

* To enable simulation, animation, proof, execution, transformation

Formal methods are on the verge of becoming best practice and/or required practice for developing safety-critical and mission-critical software systems.Main problem with informal specification is the inherent ambiguity of textual description. Mathematics can eliminate such ambiguity as it is concise and complex properties can be expressed succinctly.

1.6.1 Z Notation

Z is a model based specification notation used at analysis stage of system development. It is based upon set theory and first order predicate logic. The characteristic features of Z include: it allows type definition even at specification level, it allows refinement of the model, so that each refined model will be closer to implementation, it has a powerful structuring mechanism. There are about 90 techniques of formal methods but we chose Z notation due to following reasons [24].

Z is considered suitable tool for the specification of systems which are not complex. As we are developing the model at abstract level which doesn't involve any inherent complexity, so Z is a best option at this stage of system development.

Z is base on basic set theory and first order predicate logic which can be learnt by a person who has very little idea about mathematics. As integrating of different approaches is one of the objectives set for this research, so at this stage, it is not appropriate to use any formal technique which involves complex mathematics. Z has got wide tool support [14].

1.6.2 Z/EVES

Z/EVES is a tool for analyzing Z specifications. It can be used for parsing, type checking, domain checking, schema expansion, precondition calculation, refinement proofs and theorem proving. The specifications developed in Z in this research are validated using Z/EVES tool.

1.7 Methodology

The flow of work will be first to describe the system in informal way using UML and then modelling the system in formal way using formal specification language. Here we used some of UML structures for initial abstract system modelling Class diagrams are used to show the static system model and then sequence diagrams for more system details class object responsibility and relationships. For more refined and detailed system model we use formal methods. Formal methods have mathematical foundation that are more precise, and in fact more rigorous and robust in stating software system properties. Z specification language is used here for formal system modelling. Accordingly, its use is especially attractive for systems in which errors are particularly costly.

1.8 Results

Integration of two most design technique which makes each other more powerful when used together. Design patterns need formalism due to its informal nature and formal methods provide it with its formalism nature. According to the limitation we will not be able to model a fully functional system rather a skeleton imposes with rules to validate its structure which later can be implemented in any programming language.