Keywords: design patterns, object-oriented, finite element method.

This paper examines the use of design patterns in object-oriented finite element programming. Software design patterns are named abstractions of proven solutions to recurring design problems [1]. They help improve software quality and reduce development time. There are similarities among object-oriented finite element programs. They reflect consensus among developers with respect to best practices in this field. Capturing these practices as design patterns facilitates design reuse and collaboration. It also represents a step towards unifying the different approaches to object-oriented finite element programming in the literature. Five basic patterns are presented in this paper. The motivation behind each pattern is described. The solution and its rationale are explained, accompanied by illustrating diagrams. The consequences of applying each pattern are stated. Issues of implementation are highlighted. Previous uses of each pattern, whether explicit or implicit, are also reviewed.

In the Model-Analysis Separation pattern, the finite element system is decomposed into model and analysis subsystems. The model subsystem contains classes related to finite element modelling, whereas the analysis subsystem is responsible for analyzing the finite element model. Organizing classes into these two subsystems improves coherence and comprehension. In addition, by making the analysis subsystem dependent on the model subsystem and minimizing coupling, the impact of making changes to analysis classes are reduced.

Model-UI Separation advocates separating methods and data related to the user interface (UI) from model classes. UI classes are placed in a separate subsystem that is dependent on the model subsystem. In this way, model classes are not bloated with UI-related responsibilities and can remain coherent. UI-related changes are also less likely to affect model classes.

Defining element types using class inheritance alone can lead to code duplication and complex class hierarchies. Modular Element uses object composition to reduce the element class hierarchy, increase reuse and ease extensions. An element is defined by component classes representing the strain-displacement matrix, the constitutive matrix, and the numerical integration scheme. Delegating responsibilities appropriately to these components reduces the complexity of the element class. Implementation encapsulation is enhanced by forcing the element class to access functionality in its component classes through interfaces.

A Composite Element represents a substructure in the finite element model. At the same time, it can also be handled like a simple element. This is achieved by defining a common interface for substructures and elements. Clients of this interface can handle composite and simple elements uniformly, thus simplifying implementations. Managing groups of elements become easier. This pattern also facilitates the implementation of domain decomposition methods, concurrent processing and distributed analysis.

Placing analysis procedures in one monolithic class makes the analysis subsystem difficult to extend and gives little scope for code reuse. A well-designed analysis subsystem is essential to reap greater benefits from object-oriented design. Modular Analyzer decomposes the analysis subsystem into component classes to increase code reuse and flexibility. It applies the Strategy pattern [1] recursively to allow variations with respect to the type of analysis and the equation solution algorithm. This pattern also decouples the storage scheme for the system of equations from the solution algorithm, allowing the two aspects to vary independently. From a broader perspective, the analysis subsystem is partitioned into two packages. The classes in one interact with model classes. The other package is mathematical and independent of the model subsystem. The classes in this package can easily be replaced by general library classes implemented by numerical specialists.

The design patterns in this paper have been implemented in a prototype program first developed by the second author [2] to test their feasibility and to give further insight. The implementation of each pattern generally differs from previous uses in the literature. The developer has to decide on the most appropriate implementation based on his requirements and constraints. The forces of flexibility and simplicity have to be balanced.

This paper is by no means the final word on this subject. The catalogue of patterns in object-oriented finite element programming can be improved upon and added to. It would be a useful reference for researchers and developers alike.

1

E. Gamma, R. Helm, R. Johnson, J. Vlissides, "Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley, Reading, Massachusetts, USA, 1995.

2

R.I. Mackie, "Object-Oriented Methods and Finite Element Analysis", Saxe-Coburg Publications, Stirling, UK, 2001.

purchase the full-text of this paper (price £20)

go to the previous paper
go to the next paper
return to the table of contents
return to the book description
purchase this book (price £105 +P&P)