Software design patterns are general reusable object-oriented solution. In software engineering, patterns have been proven to offer many benefits. Scientific software also becomes more object-oriented and the importance of design patterns increases. We present a set of design patterns for object-oriented scientific software. Particularly we develop computer-aided engineering software based on the Finite element method. Initially, we decompose the problem into subsystems by applying the commonality and variability analysis. A set of commonalities includes following terms: a representation scheme, a mesh, a solver, etc. A representation scheme is an interface that allows to check whether a point belong to a solid or not. A mesh is the discrete representation of the solid via a set of simple geometric shapes. Four basic design patterns for the scientific software development have been presented in this paper. There are developed UIModel-Analysis, Representation-Mesh, Element-Mesh, and FEA Problem patterns. These design patterns separate pre-processing, the analysis solver, and post-processing of results.
Software design patterns as general reusable solutions were introduced in the end of the
1980s and, since that time, they have been actively explored in software engineering
[
CAE software is a kind of scientific software that areas may include the stress analysis, the thermal analysis, the fluid flow analysis, the multibody dynamics etc. In general, a CAE system consists of three subsystems: pre-processing, an analysis solver, and post-processing of results.
Consider a generic CAE system that uses the finite element method in the solver subsystem. We can assume that every solid’s model is initially defined by some representation scheme and then this model is discretized into a mesh. 2.1
The most modern CAE software have integrated graphical user interface (UI). Using UI controls, user defines the model of the problem and performs the analysis. Hence, three main packages participate in the high-level decomposition.
The UI package contains classes that implement UI-related responsibilities of software. The analysis package is responsible for the numerical analysis. The model package defines the interface that allows to check whether a point belong to a solid or not. Naturally, there should be no coupling between the analysis and UI subsystems. However, the UI package is dependent on pre-processing, the solver and post-processing. 2.2
We suppose that a domain model is described in terms of some representation scheme. Boundary representation (BRep), constructive solid geometry (CSG), and function representation (FRep) are the most commonly used schemes. A common property of CSG and FRep that it is easy to check whether arbitrary point belong to the solid or not. We also can assume that a mesh is an abstract interface that allows generating and iterating over a collection of elements. In this case, concrete classes derived from the Mesh class generate collections of elements with appropriate shape using an abstract representation’ interface to classify a point. Both Representation and Mesh classes participate in the Representation–Mesh pattern (see Fig. 2). The intent of this pattern is to separate responsibilities between representations and mesh generation classes.
Both Representation and Mesh classes are an application of the Strategy pattern [
+isInside FunctionRepresentation +isInside Uses Uses
+isInside TriangleMesh +isInside has has
Triangle Fig. 1. The Representation–Mesh pattern Abstract Concrete 2.3
In general, an element is a collection of nodes in order is significant. Both two- and three-dimensional elements have edges (an edge is a straight-line segment connecting two nodes). In addition, three-dimensional elements have faces that are flat elements enclosed by edges. Thus, the concrete face is an object of the class that inherits the Element interface. Hence, Element, Face, Edge, and Node are structural elements of the Element–Node pattern (see Fig. 2).
The Element class and its derivatives (including faces) can be implemented as
Iterator [
has
Edge has Face has
Edge Hexahedron
Node3d
has Quadrilateral
has
has
has
has
The FEA Problem pattern can be derived from the Template Method Pattern [
Forces and boundary conditions implement the FeaValue interface. This interface
allows to obtain the direction and the value in any point. Forces and boundary
conditions are usually specified by the UI or DSL model. However, using the Adapter pattern
[
This paper has been proposed an approach for the development of scientific software using design patterns. Particularly, four basic design patterns for the finite element programming have been presented in this paper. The first, the UI–Model–Analysis pattern decomposes software into high-level subsystems. The second, the Representation– Mesh pattern separates relations between representations and mesh generation classes. Next, the Element–Node pattern uses object decomposition to define elements of a mesh. Last, the FEA Problem pattern defines the structure for a generic finite element problem. These patterns show how object can be organized for greater flexibility and maintainability. Patterns represent abstractions of the CAE design without restrictions on the source code.
Acknowledgments. This research is funded by The Ministry of Education and Science of Ukraine.
FeaProblem +assemblyGlobalMatrix() +assemblyGlobalVector() +processInitialValues() +solveLinearSystem() +processSolution() +analyse() assemblyGlobalMatrix(); assemblyGlobalVector(); processInitialValues(); solveLinearSystem(); processSolution(); boundaryConditions mesh forces +direction(Point) +value(Point)
elements