- Email: [email protected]
Optimization of slabs using object oriented programming
Computers and Structures 82 (2004) 741–752 www.elsevier.com/locate/compstruc
Optimization of slabs using object oriented programming Adel Al-Assaf, Hassan S. Saffarini
*
University of Jordan, P.O. Box 13336, Amman 1942, Jordan Received 2 July 2003; accepted 1 February 2004
Abstract This paper discusses the application of Object-oriented programming (OOP) to the optimization of concrete slabs. This is achieved by combining: modeling, structural analysis, concrete design, cost estimation and discrete optimization together with data on cost of systems and materials. The user gets the optimal design parameters, steel topology, optimal slab system and least costs. The paper describes the overall design of the software system as well as some programming details and strategies. Inheritance and the repository model are utilized in the optimization of slabs. The unified modeling language (UML) notation is adopted. The advantages of using OOP over structured programming are discussed with particular reference to the software developed in this research. A case study on the selection of optimal system among common slab systems is briefly shown. Ó 2004 Elsevier Ltd. All rights reserved. Keywords: Optimization; Concrete; Slab; Structure; UML; Object-oriented programming (OOP); Discrete programming; Repository model
1. Introduction Optimization of building structures is a prime target for designers and has been investigated by many in the past (Balling and Yao [1], Ramm et al. [2], Choi [3], Fox [4], Gallagher and Zienkiewicz [5], Kirsch [6], Reddy et al. [7], Sarma [8], Templeman [9]). The optimization is highly linked to the selection of the most suitable structural system. Such a system would still be sized to ensure the least overall cost. In structural design, many parameters are incremental in their nature rendering a continuous approach almost impossible to implement in a practical optimization exercise. This research uses Object-oriented programming to implement a well known method for the optimization of structures, Farkas’ method for discrete nonlinear optimization [10].
*
Corresponding author. Tel.: +962-795567607; fax: +962646-123-80. E-mail address: saff[email protected] (H.S. Saffarini).
The OOP approach provides a superior software technology that is rational, flexible and easy to maintain. The development of the optimization components is described in parallel with the introduction of OOP to an engineering programmer. The more complex the problem becomes, such as is the optimization problem, the more advantage can be gained of OOP.
2. The problem Combining optimization modules together with structural modeling, analysis and design modules and augmenting them with basic raw data on availability and cost of systems and materials in one software package will lead to the development of a powerful optimization system, which may assist young and experienced engineers in identifying the most economical system to any particular architectural configuration. The study presented here takes a small step in this direction. It adapts a well-known optimization technique, Farkas’ method
0045-7949/$ - see front matter Ó 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.compstruc.2004.02.009
742
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
for discrete nonlinear optimization to develop a program which selects the most economical structural system among as many systems as the user may choose to test. The program which addresses the optimization of reinforced concrete slab systems, is not without limitations at this stage. Its development has been limited to regular layouts. It is, nevertheless, quite indicative of the processes that may be further enhanced to cover more practical situations. The results of studies conducted by the authors using the developed software on regular systems do on their own right provide a lot of insight and useful guidelines to professional designers. The general form of the nonlinear programming problem could be expressed as follows: Minimize f ðfxgÞ subject to gi ðfxgÞ 6 0 i ¼ 1; . . . ; m and
ð1Þ
hi ðfxgÞ ¼ 0 j ¼ 1; . . . ; l
where fxg ¼ ðx1 ; x2 ; . . . ; xn ÞT is a column vector of n realvalue design variables, f is the objective or cost function, g’s are inequality constraints and h’s are equality constraints. Most optimization methods require some manipulation so as to be in the form of Eq. (1). A number of methods have been developed to deal with nonlinear programming. The Rosen’s gradient projection method for linear constraints solves nonlinear systems having nonlinear objective function and linear constraints; while the Zoutendijk’s method of feasible directions solves nonlinear systems having a nonlinear objective function and inequality constraints (h’s). Nonlinear equality constraints (h’s) cause difficulty with this method, but this may be tackled approximately by introducing penalty functions. These methods require all functions to have continuous derivatives. Consequently, careful selection of the functions needs to be made. For example, if the yield strength of reinforcement steel (fy ) is taken as a design variable, then the minimum steel ratio function for twoway slab systems will not be continuous considering that only a few grades of steel may be used. The use of gradient-based methods is thus not possible for such a problem. Fortunately, however, several optimization algorithms do not involve derivatives, these are referred to as direct methods, zero-order or minimization methods without derivatives. Direct methods are helpful tools when gradient information is not readily available or when evaluation of gradient is cumbersome or prone to errors. Direct methods are generally robust, but a degree of randomness is required to achieve global optimization among many local optimization solutions [11]. Some of the zero-order methods use the characteristics of the gradient-based methods to verify convergence. Powell’s method of conjugate directions has similar characteristics to the Fletcher–Reevers method. He suggests that if minimization is carried out along
successive directions that are conjugate with respect to all previous directions, convergence could be achieved in a finite number of steps. He thus develops the idea of constructing the conjugate directions without using derivatives. Many direct search methods examine functions assuming a continuous domain. However in many engineering problems, variables are indivisible as fractions. These problems form an important class called integer-programming problems. Mixed integer problems are the problems having some variables that should be integers and others that are allowed to be fractions. Discrete programming problems are those problems where the variables are to be selected from a discrete set of variable sizes. Most of the design problems fall into this category. In steel design, certain sections are available in markets; the designer is thus confined to the use of available steel sections. The same argument is applied to concrete design problems, where sections are increased by prescribed increments. The details of the study including the design constraints, the design parameters and constants, objective function selection, etc. are not discussed here and may be referred to elsewhere [12]. This paper rather focuses on the OOP approach and makes reference to the optimization problem almost as a prototype for such a development in structural engineering.
3. Introduction to object-oriented development Object-oriented development is an analysis and design strategy for software where system designers think in terms of ‘‘things’’ rather than operations and variables. It involves designing the object classes and the relationships among these classes. A class module is an ‘‘idea’’ that provides a template for the attributes and the services that the object will provide. An object is an instance of its class module [13]. For example a ‘‘structural member’’ is an idea that has general attributes such as: length, width, depth, applied loads, member type (such as column or beam), stiffness, material, etc. and it has behaviors such as computation of length, own weight, stiffness matrix, deflection, member forces, etc. A member with defined attributes such as: concrete material, column type, 5 m length, 700 mm width, . . . etc. is called an object. This is an instance of the main idea that is the ‘‘structural member’’ class module. The set of attributes of the object defines its state, which in turn defines the behaviors and the operations of the object. The object-oriented development process includes three main phases. First, the object-oriented analysis phase deals with the development of the object-oriented model of an application domain. In other words, it
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
identifies the classes and the entities, with their abstract possible attributes and operations, which satisfy the system requirements and specifications. Secondly, the object-oriented design phase involves developing an object-oriented model of a system to implement the identified requirements. This phase defines the software modules and sub-systems and identifies the relations that govern the system operations and modules interaction. In fact, several object-oriented design methods have been proposed by different researchers (Coad and Yourdon [14], Robinson [15], Graham [16]). A unification of notations used in these methods has been has been made by Rambaugh and Jacobson [17] and was dubbed as the unified modeling language (UML). This was simplified by Sommerville I. [18] and divided into five stages: define system context, design system architecture, identify the principal objects in the system, develop design models, and specify object interface. Details may be found in other literature such as TriReme courses [19]. Object-oriented programming (OOP) phase is the third in the sequence and it encompasses the realization of the software design. This could be done using any of the OOP languages such as C++ and Java.
4. Relevant work and motivation Object-oriented methods have now been implemented in numerous structural engineering applications. Research in this field focused on structural analysis and related computational methods. Archer et al. [20] devised an inventive object-oriented finite element analysis architecture which separates the numerical tasks and the algorithms of the analysis in distinct classes from the components of the finite element model which are placed in other classes. A useful application of the agent object in equation solvers and overall calculation control in the finite element modeling systems was suggested Mackie [21]. Computer applications in the field of design and optimization were carried out. Neural networks were applied in simple fashion to concrete design of beams Hadi [22]. Little research has been conducted in structural systems optimization whereby structural analysis and design is conducted for a whole structural component, such as slabs and shells. Tabatabai [23] introduced a finite element design object, which is associated with a linear programming approach in an object-oriented environment for sizing two- and three-dimensional reinforced concrete structural panels. Furthermore, very few optimization research attempt to serve the structural design practice. The user requirements and the software components described in this paper are based on the general office-practice and its need.
743
5. General description of the optimization program This paper discusses in brief the application of the object-oriented development to concrete slabs optimization. The first step in any software development process is the development of a comprehensive understanding of the software requirements and specifications. This includes system environment, internal system, and behavior. Establishing the system context and the models of use requires performing an objectoriented analysis to determine the software requirements. Generally speaking, the software requirements constitute a description of the services that a system is expected to provide and the constraints under which it must operate. The proposed optimization software is required to perform structural analysis, concrete design, cost estimation, and cost optimization. The user’s objective is to arrive at the optimal design parameters; in this case they are the beam width, beam depth and the slab thickness. The user is also interested in knowing the optimal slab system, steel topology and arrangement, and the optimal costs. The user needs to feed the available range of design parameters, costs, the structure layout and the basic geometry. Those requirements are called the user requirements. However, to satisfy user requirements there are many other services that are provided by the system. For example, the system generates the finite element mesh or the member framing, assigns the appropriate properties to the structural elements, stores the user input and the optimization output, performs structural analysis, parses the analysis results and performs the appropriate design procedures, iterates over the design variables to arrive at the optimal design variables, displays and saves output and input, as well as other numerous ‘‘services’’. Those ‘‘services’’ are called system requirements. The system and user requirements define the system components, and their internal and external interaction. The system components and their interaction are known as the use-case of the system. Fig. 1 shows the use-case of the proposed optimization system. Each ellipse represents a module or a sub-system. The arrows define the interaction between the sub-systems with one anther and/or with the user, which is the actor as shown in the figure. It should be pointed out that different use-case arrangements could be suggested to serve the same requirements. Fig. 1 provides a diagrammatic demonstration of how the system operates. A more detailed diagram is usually associated with this diagram which is called the sequence diagram (see Fig. 5). The use-case diagram, however, includes an overall abstraction of the organization of the system requirements.
744
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
Central Controller
System Generator Actor
Design Parameters Database
Elements Database
Slab Sys. Operation & Optimization
Analysis (FEM, Line mem., ... etc)
Concrete Design (ACI)
Results and Output
Fig. 1. The proposed system use-case.
6. Program’s architecture Performing the object-oriented analysis is a prerequisite of the design of the software architecture. The Architectural design is then the process that identifies the sub-systems and modules, which constitute the overall system. It also establishes a framework for the sub-system control and communication that in turn define the data flow and the sequence in the system. The output of the architectural design process is a description of the software architecture. The proposed optimization system is decomposed into eight sub-systems. Some of them are generic and apt to be used in other software such as the structural analysis and design sub-systems, while others are customized to serve the studied structure’s needs, such as the ‘‘design parameters database’’, ‘‘members database’’, ‘‘central controller’’, ‘‘system generator’’, and ‘‘optimization sub-system’’. Recalling Fig. 1, it can be seen that all the shared data is held in a central database that can be accessed by almost all the structures. This system model, which is based on a shared database, is called repository model. Generally speaking, employing the repository model in engineering application is much more efficient than providing a separate database for each sub-system, and thus the data is interchanged with other sub-systems by passing messages to them. The latter concept is applied here on the ‘‘analysis’’ and ‘‘design’’ sub-systems.
Applying the repository model is appropriate when the data is generated by one sub-system and used by the others. The ‘‘members database’’ is totally generated by the ‘‘system generator’’ sub-system. The other sub-systems use the data stored in that database and are allowed to modify some values but they are never allowed to instantiate any new instances in the ‘‘members database’’ sub-system. The same argument applies to ‘‘design parameters database’’, where the ‘‘central controller’’ is the only module that has the responsibility of instantiating and generating this sub-system. Applying the repository model helps in sharing large amounts of data, and reduces the explicit data transfer among the subroutines. Sub-systems that produce data are indifferent to how that data is used by other subsystems. Introducing a new sub-system could be much easier if a compatible interface is developed. For example, introducing a ready sub-system to plot the analysis and the design outputs only requires the construction of an interface that acquires the data from the repository and then transfers it to the suitable methods in the drafting modules. The drafting modules will then do the job and plot the data on the required user graphical interface. In order to work as a whole system, sub-systems must be controlled so that their services are delivered to the right place at the right time. Thus, there is a need to create a control model that handles the control flow between the various sub-systems. The ‘‘central control-
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
ler’’ sub-system shown in Fig. 1 works as a control module for the entire system. This centralized control has overall responsibility of controlling, initializing and terminating the other objects. However, it may devolve control to another sub-system but will expect to have this control responsibility returned to it. This occurs, for example, when the ‘‘optimization’’ sub-system controls the ‘‘structural analysis’’ and the ‘‘concrete design’’ modules. The implementation of the centralized control could be done sequentially (call-return model) or in parallel. The proposed optimization system is designed based on the call-return model, where control starts at the top of the sub-routine hierarchy and, through subroutine calls, passes lower levels in the tree. Prior to the introduction of the object-oriented programming the trend was to use the data-flow model (pipeline), where the system is decomposed into functional modules which accept input data and transform it to output data. Data flows from one module or subroutine to another and is transformed as it moves through the sequence. Despite the fact that the data-flow concept is still used nowadays in some applications, the object-oriented model is considered the superior approach in creating an engineering application. One of the advantages of the use of the object-oriented model in designing engineering applications is that it simulates the real-world entities, thus, it makes the break down of the system much easier to understand. Furthermore, as each entity (class module) encompasses its own complete instance variables and behaviors, it can be reused in other programs. For example, the ‘‘structural analysis’’ and ‘‘design’’ class modules in this case were reused from another program. However, some modifications were required to reuse the ‘‘Structural Analysis’’ module in the proposed program. Still, the implementation of the object can be easily modified without affecting other objects. Thus, the design of the object-oriented module is easier to reuse than that of the data-flow model.
7. Class module details The internal features and the structure of the subsystems and the modules of a system are dictated by the system requirements and specifications, as well as the system structuring articulated at the architectural design phase. The following is a brief discussion for the identification of some classes. Fig. 2 shows an abstract sketch for the Members class module (clsMember). The top part shows the module name, the middle part includes the properties, and the lower part includes the methods. This class module is a part of the Members database.
745
clsMemeber Beam Caption: String Beam Width, Depth, Length: Single Flange Thickness, Width: Single Area, Ixx, Iyy, Izz: Double Number of Section: Integer Number of Load Cases: Integer Include Own Weight: Boolean Density, E, G: Double Section Type: TypeOfSection Enum TypeOfSection RectangleSection = 0 TeeSection = 1 LSection = 2 Custom = 3 End Enum Uniformly Distributed Load Array[] Bending Moment Array[][] Deflection Array[][] ...
Copy Me () Get/Set Width() Get/Set Height() Get/Set Bending Moment () Get/Set Deflection () Get/Set Uniformly Distributed Load () Find Section Properties () ...
Fig. 2. Member class module.
It can be seen that the clsMember has all the attributes of a beam. It stores beam properties such as cross section properties, material constants, and loads. Moreover, it stores the analysis, design, and optimization outputs, the clsMember thus serves as a database. The module decomposition of the clsMember shows that no calculations are performed in the module except for the computation of the section properties. However, many other methods may be assigned to the class module, such as calculating the section forces and deflection. These tasks are, however, assigned here to the analysis module. The same idea is applied to the ‘‘design parameter’’ module. A set of attributes is assigned to the class module that stores material properties, costs, available R-bar sizes, and available deign variables. The ‘‘Copy me ( )’’ method in the clsMember reproduces the object itself in another object. This is useful to create a back up object to store the optimal solution results. It should be noted that using the equating operator ( ¼ ) between two objects will not copy the members of the origin class to the target object but rather assigns a pointer (reference) from the target object to the original one. Instantiating many objects of the clsMember or the ‘‘design parameters class module’’ and then storing each
746
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
kind of object in its stack will form a repository for each kind of object. The ‘‘central controller class module’’ (clsController) includes many methods to enable it to control the overall system. The user is connected to the ‘‘central controller module’’ via a set of interfaces. Through the interfaces the user can request services from the ‘‘central controller’’, such as feeding a new set of design parameters, or modifying an old one. The user feeds the whole geometry of the structure. The ‘‘central controller’’, then, analyzes the details of the members and matches the required geometry to the required set of design variables. The user can perform optimization for more than one slab system for the same geometry by linking each slab system with its appropriate set of ‘‘design parameters object’’. The ‘‘central controller’’, through its attributes and behaviors, is able to organize matching the appropriate objects together to solve the problem correctly. For example, the user can request optimizing a certain slab geometry such as a one-way ribbed slab and then a two-way ribbed slab. The user, then, assigns a certain set of design parameters to each slab system, and assigns the appropriate number of design parameters by specifying whether the system has drop or hidden beams. The ‘‘central controller’’ then controls the behavior of the ‘‘system generator’’ by sending a message to create the suitable system geometry taking into consideration its set of design parameters and its number of design variables. It then invokes the appropriate ‘‘optimization class module’’ to solve the problem. There are different ways to design the ‘‘optimization class module’’ (clsOptimization) to suit the slab system. Fig. 3 shows a part of a class hierarchy for the optimization system. The most general object class (super-class) is presented at the top of the hierarchy (clsOptimization), however, the more specialized object classes (subclasses), which are at the lower level in the hierarchy, inherit the attributes and the behaviors of their superclass. Still, the sub-classes have their own attributes and behaviors as well. Although each class module has the same attribute and method names, each one maintains its own identities. The ‘‘central controller’’ instantiates the suitable class object of the clsOptimization sub-class, and then it invokes the optimization method. This method is available in each sub-class as shown in Fig. 3, however, the behavior of this method is different from one class object to another. The Class diagram, shown in Fig. 4, is a more detailed diagram than the use-case diagram. It provides information about the classes in the system. This diagram identifies each class in the system and defines the required attributes, methods, and associations with the other objects in the system.
The figure shows the association relationships among the system components. The ‘‘central controller’’ is associated with at least one instance of the ‘‘design parameter’’ class and the ‘‘optimization class’’ modules. However, it is associated with only one instance of the ‘‘system generator class’’. The ‘‘system generator’’ object is associated with at least one instance of the ‘‘member class module’’. The ‘‘central controller object’’ could be associated with different instances of the ‘‘optimization class modules’’. For example, there could be many instances of the ‘‘flat plate class module’’ (clsFlatPlate). However, each object of the ‘‘optimization class module’’ is associated with one instance of the ‘‘design parameters’’ and/ or one set of ‘‘member’’ objects. Thus, different slab assignments could easily be created in the system using the same geometrical layout but with different design parameters and/or geometry specifications. In the proposed program the methods of the single instance classes are class methods rather than instance methods. Class methods, as opposed to instance methods, have no knowledge of an individual object’s state. They are intended to provide a service that is independent of a class instance. In the Java Language this type of method is declared as static [13].
8. Program’s flow To design the behavior of an object, it is required to define the operations and services provided by this object. This could be done by constructing a sequence diagram. Fig. 5 shows a summarized sequence diagram of the proposed system. The real sequence diagram of the system is more complicated and includes more details than the one shown here. The sequence diagram shows the actor involved in the interaction, the objects within the system and the operations. The horizontal scale of the diagram represents the system components, while the vertical scale represents the time sequence of the operations. The actor (user) shown in Fig. 5, sets the design parameters through the ‘‘central controller’’. The actor also sets the geometric characteristic of the slabs and the required slab systems to be optimized. The ‘‘central controller’’ initiates the required object and then links it to the design parameter stack. It then stores the design variables and parameters accordingly. When the user requests the ‘‘central controller’’ to solve the problem, it checks the problem input. If the input is correct the process starts by requesting the ‘‘system generator’’ to generate the structural elements that will be used in the analysis process. The ‘‘system generator’’ may consult the ‘‘design parameter’’ entity to initiate the section properties and the material constants.
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
747
clsOptimization Optimal Slab Thickness Optimal Cost Concrete Optimal Cost … Number of Iterations ….. Optimal Failed Due (as UnSatCond) Number of Design Variables Enum UnSatCond optNone = 0 optStrength = 1 optBarSelection = 2 optDeflection = 3 optShear = 4 optDimError = 5 End Enum Search another design variable () Set Data Object () Design Rec Section () Design T-Section () Check Beam Deflection () ...
cls1WRS_Drop
cls2WRS_Hidden
clsFlatPlate
Num. of Design Variables = 3 Optimal Beam Width ...
Num. of Design Variables = 2 Optimal Beam Width ...
Num. of Design Variables = 1 Optimal Beam Width = 0 ...
Design Param. Manager () Find Steel Length () Function and Constraints () Last Variable () Store Optimal Results () Perform Analysis () Design () Cost Estimation () Optimize () ...
Design Param. Manager () Find Steel Length () Function and Constraints () Last Variable () Store Optimal Results () Perform Analysis () Design () Cost Estimation () Optimize () ...
Design Param. Manager () Find Steel Length () Function and Constraints () Last Variable () Store Optimal Results () Perform Analysis () Design () Cost Estimation () Optimize () ...
Fig. 3. Optimization class module.
After the call returns back to the ‘‘central controller’’, it instantiate the appropriate requests for the ‘‘optimization object’’ and invokes its ‘‘optimization method’’. The ‘‘optimization object’’ consults the appropriate ‘‘member object’’ and the appropriate ‘‘design parameter object’’ to initiate the optimization process. It, then, performs structural analysis for the structure by requesting the appropriate method in the specialized ‘‘structural analysis object’’ to do the job, which then returns the analysis outputs back to the ‘‘optimization object’’. The ‘‘optimization object’’ performs the design process by invoking the suitable design methods of the ‘‘structural design object’’. This returns the outputs back to the ‘‘optimization object’’ that stores all the analysis and design outputs in the appropriate member objects
(element entity). The ‘‘optimization object’’ iterates on the solution by searching other design variables and repeats the above process until reaching the optimum solution. The ‘‘optimization object’’ invokes the ‘‘results object’’. This object is designed to store the final results and to facilitate friendly output to the user. Finally, the user may request saving the outputs in a file by invoking the ‘‘save method’’ of the ‘‘results object’’ (clsResults).
9. OOP versus structured programming The favored development philosophy before the object-oriented development was the structured
748
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
clsOptimization
clsDesign
OptimalCost: Single SteelOptimalCost: Single …
DesignCompSteel: Bool. DeepBeam: Boolean …
1..1
1..1
SetDataObject () DesignRecSection () Optimize()
cls1WRS_Drop
Design_Rect() Design_T() Design_Comp() Select_Steel() …
cls2WRS_Hidden
clsFlatPlate
NumDesignVar = 3
NumDesignVar = 2
NumDesignVar = 1
FunctionConstraints () Last Variable () Store Optimal Results () Perform Analysis () …
FunctionConstraints () Last Variable () Store Optimal Results () Perform Analysis () …
FunctionConstraints () Last Variable () Store Optimal Results () Perform Analysis () …
1..*
1..*
SetGeometry() NewDesignParam() EditDesignParam() CreateNewSystem() DeleteSystem() GenerateSystem() SolveProblem() SaveInputFile() OpenInputFile() …
1..1
1..*
1..1 clsController SlabGeometry[]: Single InputFile: String SlabSystems[]: Object DesignParam[]: Object OptProblem [][]: Object MembersStack[]: Object …
1..*
clsDesignParameter
1..1
1..*
Caption: String Fc, Fy: Single ReBarDiam[]: Single ConcUnitCost: Single … GetBlockSize() Get/SetReBarDiam() OpenDataFile() …
1..1
1..1
clsResult
UniformLoad[]: Single BM[][]: Double …. PerformAnalysis() FindFEM() ConstructStiffness() FindSectionBM() GetAnalysisResults() …
clsSystemGenerator Create1WSS_Drop() Create1WRS_Drop() Create2WRS_Drop() Create1WRS_Hidden() Create2WRS_Hidden() CreateFlatPlate() …
1..1
clsAnalysis
SlabSystem: String DesignParam: Object OptimalCost: Single … SaveOutPutFile() SortResultsByCost() SortResultsByType() ….
clsMember
1..1
1..*
BeamCaption: String BeamWidth, Area, Ixx, Iyy, Izz: Double NumSec: Integer OwnWeight():`Double …
1..*
Set/GetWidth() CalculateArea(): Double CalculateIzz(): Double Get/SetBending() CopyMe() …
Fig. 4. Class diagram of the proposed system.
development. In it programmers were expected to plan 100% of a program before writing the code. This heavy pre-code work may lead to good documentation but not necessarily great design [13]. Although the use-case of a program appears almost the same for both development philosophies, the modules decomposition and the internal interaction of the system are totally different. In structured development the representation of entities is oriented towards arrays rather than objects. For example, all the section properties are typically
stored in one array, while material constants are stored in another. Each row then corresponds to a structural member; it is thus required to construct a bookkeeping matrix to track the data indices. Working with parallel arrays complicates the application; since it is always required to search the index of each element to access its appropriate location in another matrix. Some programmers used the defined data type (DDT) to solve the problem of the parallel arrays. Defined data type is a fixed-length record that holds a number of defined types of variables (see Fig. 6). How-
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
:Central Controller
:System Generator
:clsElement
:clsDesign Parameter
:Optimization
:Analysis
:clsDesign
749
:clsResults
Actor Set Design Parameters
New Store
Set Geo. & Slab Sys.
Solve [Check Data]
Generate Beams & Finite Elem.
new
Store
Optimize
Acquire
Acquire
Analyze
Design
Store
Iterate
Check Opt. Criteria View Output
Display
Save
Fig. 5. Sequence diagram of the proposed system.
Type member Caption As String * 20 E As Double Ixx As Double Area As Double Width As Single … End Type … ReDim Elements(NumOfElem) As member Elements(1).Area = .002 Elements(1).Width= .5 …
Fig. 6. Define data type.
ever, although this approach reduces part of the programming and the machine efforts it does not totally eliminate the need for using the parallel array approach, and is not without limitations, such as the limitation of holding arrays as a field in the record. Unlike the DDT, each entity in the OOP can hold indeterminate lengths of arrays, and could be linked to other entities. Changing a certain variable such as the member’s width causes changes in other properties of the member such as the cross section area and inertia. In structured programming the programmer should be aware of this and should thus recalculate the member properties each
750
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
time the dimensions of the section change. This requires invoking the appropriate functions to carry out this task in many different places in the program. On the contrary in OOP the object itself handles the problem. Fig. 7 shows an abbreviated code of the ‘‘member class’’ module (clsMember). The code shown is written using the Java language. The Public ‘‘SetWidth( )’’ method passes new value of ‘‘beam width’’ attribute. This ‘‘method’’ checks the width value and stores it in the private variable ‘‘myWidth’’. Then, the method itself recalculates the other variables that are related to the width, such as the cross section area and the inertia that belong to that member, i.e., updating the private variables myArea, myIxx, myIyy,. . . etc. The same idea is applied on other variables such as the loads. In the current program when ‘‘Set_ Uniformly_Distributed_Load ( )’’ procedure is invoked the fixed end forces are automatically updated correspondingly. It is seen from the above discussion that the structured development depends on creating strong coupling among the program components, which increases the agreed upon rules and complicates the software. In contrast, OOP eliminates these complications, simplifies software design, and makes it more readily upgradeable.
public class clsMember{ /** Private Attributes**/ private float myWidth, Length, myHeight; private float myFlangeWidth, myFlangeThickness; private double myIxx, myIyy , myIzz , myArea; … /** Methods**/ public float width(){ return myWidth; } public void SetWidth(float newWidth){ if (newWidth>=0){ myWidth=newWidth; SetArea(0); SetIxx(0); … } } public void SetArea(double newArea){ if (newArea>0){ myArea=newArea; } //T-Section else if (myFlangeWidth*myFlangeThickness>0){ myArea=myWidth*(myHeight-myFlangeThickness)+ (myFlangeThickness*myFlangeWidth); } //Rectangle else{ myArea=myWidth*myHeight; } } public double Area(){ return myArea; } } …
Fig. 7. Member class module.
10. Possible extensions to the program Currently, the program is not devised to find the geometry of the structure. For example, span length and spacing between spans should be directly fed by the user. However, it is easy to introduce a new class module that describes each joint location, and then link it to the ‘‘clsmember’’ class module via the ‘‘clsSystemGenerator’’ class module to find the geometry of each member. This evolution is quite possible here, in OOP, however it could be complicated to implement in the structural programming. Other possible improvement in this regard is to devise more than one design code class module and add them to the system. The new class modulus should have the same interface used in the current design code class module ‘‘clsDesign’’ see Fig. 4. The clsController passes a message to the clsOptimization to instantiate the required design code class module. Since each slab system has different requirements, each one of them is considered as different class module. This reduces the programming effort and adds powerful features to the program. For example, the user can solve the same slab system using different design variables or parameters. This also supports the prospect of applying concurrent (parallel) processing, such that each slab system with its parameters is considered as a separate problem. Although the use-case of a program appears almost the same for both development philosophies, the modules decomposition and the internal interaction of the system is totally different. It is seen from the above discussion that the structured development depends on creating strong coupling among the program components, which increases the agreed upon rules and complicates the software. In contrast, OOP eliminates these complications, simplifies software design, and makes it more readily upgradable.
11. Case study The program is developed with the intention of obtaining the optimal system and member sizes for any particular layout where column locations are predetermined. A large number of test cases were studied first to verify the functionality of the program and then to examine real life problems [12]. A sample is given here of a study that was made to find the optimal slab system for a regular layout. In this case one condition was imposed on all candidate systems and that is to have no drop beams. In other words the soffit of the slab system is flat. Cost of material, labor and plant have all been taken from the local, Jordanian, market and are consistent with common norms of pricing by contractors. The studied systems include: (1WRS-X-HB) one way
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
joist slab with concrete blocks as formers, (1WRS-XPoly) same but with polystyrene block formers and (1WRS-X-Waffle), one way waffle or trough. The next three are the same but are two way joists (2WRS-HB), (2WRS-Poly) and (2WRS-Waffle). Finally (Flat Plate) is studied. Superimposed dead load of 4 kN/m2 , live load of 3 kN/m2 and self weight are allowed for. In this particular study concrete and reinforcement properties are held constant throughout. Design variables include width and depth of beams and depth of slabs/joists. In this case joists and beams have the same depth. Magnitude of reinforcement, including bar selection, comes as a by product of the design constraints. Many other contributors to the over all design are constants held in the program database such as waffle sizes, concrete and polystyrene blocks sizes, bar diameters, etc. The system under investigation is square in plan, with four equal bays in each direction. The spans are held at 4 m while the optimal solution is determined and then the process is repeated for 5.5, 7, 8.5, 10 and 12 m bay widths. The normalized cost for each system for every span width is shown in Fig. 8. It is evident that all systems are feasible at short spans while only a few are for longer spans. It is also clear that the cost effectiveness of these systems vary from one span width to another. The optimal system for short spans is the one-way ribbed slab with concrete hollow blocks. This is consistent with the fact that this is by far the most prevalent system for such spans in the local industry. Variations were made on the pricing database to reflect other hypothetical regions and as expected the optimal systems were different than those identified for the Jordanian market emphasizing the point for the need to investigate the suitability of systems based on local data and using a methodical optimization techniques. Furthermore, the cost effectiveness of one solution over the other may vary with
3.00 1WRS-X-HB
Normalized Cost
1WRS-X-Poly
2.50
1WRS-X-Waffle 2WRS-HB 2WRS-Poly 2WRS-Waffle
2.00
Flat Plate
1.50
1.00 4
5.5
7
8.5
10
Span (m)
Fig. 8. Results of optimization study.
12
751
time depending on cost of material and labor at that particular time thus underscoring the advantage of the versatility of the developed program and the approach on which it is based.
12. Conclusions 1. To be effective in structural engineering practice, the problem of optimization needs to be applied to a whole system rather than a section or an element. In this case, a software package was developed to find the optimal solution for the structural system of a whole floor. 2. Farkas’ method for discrete nonlinear optimization proved to be quite effective in dealing with the problem of slab systems. Limitations of some other techniques were illustrated. 3. Object-oriented programming has been applied effectively and its advantages have been emphasized particularly as they relate to software development for structural design problems. 4. Particular conclusions were derived in regards to the optimal systems in the Jordanian market. These were consistent with common practice for low spans design. For longer spans, decisive choices in the industry are less obvious. 5. It is emphasized that optimization outcome is highly dependent on the prevalent prices in any particular region at any particular time. The selection of the most suitable system is thus not necessarily an obvious exercise and the developed approach and software in this paper facilitates the expedient and effective selection of systems and dimensions.
References [1] Balling R, Yao X. Optimization of reinforced concrete frames. ASCE J Struct Eng 1997;123(2):193–202. [2] Ramm E, Bletzinger K, Reitinger R, Maute K. The challenge of structural optimization. Civil-Comp Press; 1994. p. 27–52. [3] Choi C, Kwak H. Optimum RC member design with predetermined discrete sections. ASCE Struct Eng 1990;116(10):2634–55. [4] Fox R. Optimization methods for engineering design. 1st ed. Massachusetts: Addison-Wesley; 1971. [5] Gallagher R, Zienkiewicz O. Optimum structural design. 1st ed. New York: J.W. Arrowsmith; 1977. [6] Kirsch U. Optimal structural design. New York: McGraw Hill; 1981. [7] Reddy R, Gupta A, Singh R. Expert system for optimum design of concrete structures. J Comput Civil Eng 1993;(April):146–60. [8] Sarma K, Adeli H. Cost optimization of concrete structures. ASCE J Struct Eng 1998;(May):570–9.
752
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
[9] Templeman A. Optimization methods in structural design practice. ASCE J Struct Eng 1983;(Oct.):2420–32. [10] Farkas J. Optimum design of metal structures. Chichester: Ellis Horwood Limited; 1984. [11] Belegundu A, Chadrupaltla T. Optimization concepts and applications in engineering. New Jersey: Prentice Hall; 1999. [12] Al-Assaf A. Optimization of reinforced concrete slabs, Master’s degree thesis, University Of Jordan, Jordan, 2001. [13] Cavaness C, Friesen G, Keeton B. Special edition using Java 2. Indiana: Que Corporation; 2001. [14] Coad P, Yourdon E. Object-oriented analysis. Englewood Cliffs, NJ: Prentice-Hall; 1990. [15] Robinson J. Hierarchical object-oriented design. Englewood Cliffs, NJ: Prentice-Hall; 1992. [16] Graham I. Object-oriented methods. 2nd ed. Wokingham: Addison-Wesley; 1994.
[17] Rumbaugh J, Jacobson I. The unified software development process. Reading, MA: Addison-Wesley; 1999. [18] Sommerville I. Software engineering. New York: AddisonWesley; 2001. [19] TriReme courses, UML Tutorial, 2001, TriReme International Ltd., Available from: http://uml.tutorials.trireme.com. [20] Archer GC, Fenves G, Thewalt C. A new object-oriented finite element analysis program architecture. Comput Struct 1999;70(1999):63–75. [21] Mackie R. Using object to handle calculation control in finite element modeling. Comput Struct 2002;80:2001–9. [22] Hadi M. Neural networks applications in concrete structures. Comput Sturct 2003;81(2003):373–81. [23] Tabatabai S. Object-oriented finite element-based and progressive steel weight minimization. Finite Elements Anal Des 2002;39(2002):55–76.
Optimization of slabs using object oriented programming Adel Al-Assaf, Hassan S. Saffarini
*
University of Jordan, P.O. Box 13336, Amman 1942, Jordan Received 2 July 2003; accepted 1 February 2004
Abstract This paper discusses the application of Object-oriented programming (OOP) to the optimization of concrete slabs. This is achieved by combining: modeling, structural analysis, concrete design, cost estimation and discrete optimization together with data on cost of systems and materials. The user gets the optimal design parameters, steel topology, optimal slab system and least costs. The paper describes the overall design of the software system as well as some programming details and strategies. Inheritance and the repository model are utilized in the optimization of slabs. The unified modeling language (UML) notation is adopted. The advantages of using OOP over structured programming are discussed with particular reference to the software developed in this research. A case study on the selection of optimal system among common slab systems is briefly shown. Ó 2004 Elsevier Ltd. All rights reserved. Keywords: Optimization; Concrete; Slab; Structure; UML; Object-oriented programming (OOP); Discrete programming; Repository model
1. Introduction Optimization of building structures is a prime target for designers and has been investigated by many in the past (Balling and Yao [1], Ramm et al. [2], Choi [3], Fox [4], Gallagher and Zienkiewicz [5], Kirsch [6], Reddy et al. [7], Sarma [8], Templeman [9]). The optimization is highly linked to the selection of the most suitable structural system. Such a system would still be sized to ensure the least overall cost. In structural design, many parameters are incremental in their nature rendering a continuous approach almost impossible to implement in a practical optimization exercise. This research uses Object-oriented programming to implement a well known method for the optimization of structures, Farkas’ method for discrete nonlinear optimization [10].
*
Corresponding author. Tel.: +962-795567607; fax: +962646-123-80. E-mail address: saff[email protected] (H.S. Saffarini).
The OOP approach provides a superior software technology that is rational, flexible and easy to maintain. The development of the optimization components is described in parallel with the introduction of OOP to an engineering programmer. The more complex the problem becomes, such as is the optimization problem, the more advantage can be gained of OOP.
2. The problem Combining optimization modules together with structural modeling, analysis and design modules and augmenting them with basic raw data on availability and cost of systems and materials in one software package will lead to the development of a powerful optimization system, which may assist young and experienced engineers in identifying the most economical system to any particular architectural configuration. The study presented here takes a small step in this direction. It adapts a well-known optimization technique, Farkas’ method
0045-7949/$ - see front matter Ó 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.compstruc.2004.02.009
742
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
for discrete nonlinear optimization to develop a program which selects the most economical structural system among as many systems as the user may choose to test. The program which addresses the optimization of reinforced concrete slab systems, is not without limitations at this stage. Its development has been limited to regular layouts. It is, nevertheless, quite indicative of the processes that may be further enhanced to cover more practical situations. The results of studies conducted by the authors using the developed software on regular systems do on their own right provide a lot of insight and useful guidelines to professional designers. The general form of the nonlinear programming problem could be expressed as follows: Minimize f ðfxgÞ subject to gi ðfxgÞ 6 0 i ¼ 1; . . . ; m and
ð1Þ
hi ðfxgÞ ¼ 0 j ¼ 1; . . . ; l
where fxg ¼ ðx1 ; x2 ; . . . ; xn ÞT is a column vector of n realvalue design variables, f is the objective or cost function, g’s are inequality constraints and h’s are equality constraints. Most optimization methods require some manipulation so as to be in the form of Eq. (1). A number of methods have been developed to deal with nonlinear programming. The Rosen’s gradient projection method for linear constraints solves nonlinear systems having nonlinear objective function and linear constraints; while the Zoutendijk’s method of feasible directions solves nonlinear systems having a nonlinear objective function and inequality constraints (h’s). Nonlinear equality constraints (h’s) cause difficulty with this method, but this may be tackled approximately by introducing penalty functions. These methods require all functions to have continuous derivatives. Consequently, careful selection of the functions needs to be made. For example, if the yield strength of reinforcement steel (fy ) is taken as a design variable, then the minimum steel ratio function for twoway slab systems will not be continuous considering that only a few grades of steel may be used. The use of gradient-based methods is thus not possible for such a problem. Fortunately, however, several optimization algorithms do not involve derivatives, these are referred to as direct methods, zero-order or minimization methods without derivatives. Direct methods are helpful tools when gradient information is not readily available or when evaluation of gradient is cumbersome or prone to errors. Direct methods are generally robust, but a degree of randomness is required to achieve global optimization among many local optimization solutions [11]. Some of the zero-order methods use the characteristics of the gradient-based methods to verify convergence. Powell’s method of conjugate directions has similar characteristics to the Fletcher–Reevers method. He suggests that if minimization is carried out along
successive directions that are conjugate with respect to all previous directions, convergence could be achieved in a finite number of steps. He thus develops the idea of constructing the conjugate directions without using derivatives. Many direct search methods examine functions assuming a continuous domain. However in many engineering problems, variables are indivisible as fractions. These problems form an important class called integer-programming problems. Mixed integer problems are the problems having some variables that should be integers and others that are allowed to be fractions. Discrete programming problems are those problems where the variables are to be selected from a discrete set of variable sizes. Most of the design problems fall into this category. In steel design, certain sections are available in markets; the designer is thus confined to the use of available steel sections. The same argument is applied to concrete design problems, where sections are increased by prescribed increments. The details of the study including the design constraints, the design parameters and constants, objective function selection, etc. are not discussed here and may be referred to elsewhere [12]. This paper rather focuses on the OOP approach and makes reference to the optimization problem almost as a prototype for such a development in structural engineering.
3. Introduction to object-oriented development Object-oriented development is an analysis and design strategy for software where system designers think in terms of ‘‘things’’ rather than operations and variables. It involves designing the object classes and the relationships among these classes. A class module is an ‘‘idea’’ that provides a template for the attributes and the services that the object will provide. An object is an instance of its class module [13]. For example a ‘‘structural member’’ is an idea that has general attributes such as: length, width, depth, applied loads, member type (such as column or beam), stiffness, material, etc. and it has behaviors such as computation of length, own weight, stiffness matrix, deflection, member forces, etc. A member with defined attributes such as: concrete material, column type, 5 m length, 700 mm width, . . . etc. is called an object. This is an instance of the main idea that is the ‘‘structural member’’ class module. The set of attributes of the object defines its state, which in turn defines the behaviors and the operations of the object. The object-oriented development process includes three main phases. First, the object-oriented analysis phase deals with the development of the object-oriented model of an application domain. In other words, it
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
identifies the classes and the entities, with their abstract possible attributes and operations, which satisfy the system requirements and specifications. Secondly, the object-oriented design phase involves developing an object-oriented model of a system to implement the identified requirements. This phase defines the software modules and sub-systems and identifies the relations that govern the system operations and modules interaction. In fact, several object-oriented design methods have been proposed by different researchers (Coad and Yourdon [14], Robinson [15], Graham [16]). A unification of notations used in these methods has been has been made by Rambaugh and Jacobson [17] and was dubbed as the unified modeling language (UML). This was simplified by Sommerville I. [18] and divided into five stages: define system context, design system architecture, identify the principal objects in the system, develop design models, and specify object interface. Details may be found in other literature such as TriReme courses [19]. Object-oriented programming (OOP) phase is the third in the sequence and it encompasses the realization of the software design. This could be done using any of the OOP languages such as C++ and Java.
4. Relevant work and motivation Object-oriented methods have now been implemented in numerous structural engineering applications. Research in this field focused on structural analysis and related computational methods. Archer et al. [20] devised an inventive object-oriented finite element analysis architecture which separates the numerical tasks and the algorithms of the analysis in distinct classes from the components of the finite element model which are placed in other classes. A useful application of the agent object in equation solvers and overall calculation control in the finite element modeling systems was suggested Mackie [21]. Computer applications in the field of design and optimization were carried out. Neural networks were applied in simple fashion to concrete design of beams Hadi [22]. Little research has been conducted in structural systems optimization whereby structural analysis and design is conducted for a whole structural component, such as slabs and shells. Tabatabai [23] introduced a finite element design object, which is associated with a linear programming approach in an object-oriented environment for sizing two- and three-dimensional reinforced concrete structural panels. Furthermore, very few optimization research attempt to serve the structural design practice. The user requirements and the software components described in this paper are based on the general office-practice and its need.
743
5. General description of the optimization program This paper discusses in brief the application of the object-oriented development to concrete slabs optimization. The first step in any software development process is the development of a comprehensive understanding of the software requirements and specifications. This includes system environment, internal system, and behavior. Establishing the system context and the models of use requires performing an objectoriented analysis to determine the software requirements. Generally speaking, the software requirements constitute a description of the services that a system is expected to provide and the constraints under which it must operate. The proposed optimization software is required to perform structural analysis, concrete design, cost estimation, and cost optimization. The user’s objective is to arrive at the optimal design parameters; in this case they are the beam width, beam depth and the slab thickness. The user is also interested in knowing the optimal slab system, steel topology and arrangement, and the optimal costs. The user needs to feed the available range of design parameters, costs, the structure layout and the basic geometry. Those requirements are called the user requirements. However, to satisfy user requirements there are many other services that are provided by the system. For example, the system generates the finite element mesh or the member framing, assigns the appropriate properties to the structural elements, stores the user input and the optimization output, performs structural analysis, parses the analysis results and performs the appropriate design procedures, iterates over the design variables to arrive at the optimal design variables, displays and saves output and input, as well as other numerous ‘‘services’’. Those ‘‘services’’ are called system requirements. The system and user requirements define the system components, and their internal and external interaction. The system components and their interaction are known as the use-case of the system. Fig. 1 shows the use-case of the proposed optimization system. Each ellipse represents a module or a sub-system. The arrows define the interaction between the sub-systems with one anther and/or with the user, which is the actor as shown in the figure. It should be pointed out that different use-case arrangements could be suggested to serve the same requirements. Fig. 1 provides a diagrammatic demonstration of how the system operates. A more detailed diagram is usually associated with this diagram which is called the sequence diagram (see Fig. 5). The use-case diagram, however, includes an overall abstraction of the organization of the system requirements.
744
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
Central Controller
System Generator Actor
Design Parameters Database
Elements Database
Slab Sys. Operation & Optimization
Analysis (FEM, Line mem., ... etc)
Concrete Design (ACI)
Results and Output
Fig. 1. The proposed system use-case.
6. Program’s architecture Performing the object-oriented analysis is a prerequisite of the design of the software architecture. The Architectural design is then the process that identifies the sub-systems and modules, which constitute the overall system. It also establishes a framework for the sub-system control and communication that in turn define the data flow and the sequence in the system. The output of the architectural design process is a description of the software architecture. The proposed optimization system is decomposed into eight sub-systems. Some of them are generic and apt to be used in other software such as the structural analysis and design sub-systems, while others are customized to serve the studied structure’s needs, such as the ‘‘design parameters database’’, ‘‘members database’’, ‘‘central controller’’, ‘‘system generator’’, and ‘‘optimization sub-system’’. Recalling Fig. 1, it can be seen that all the shared data is held in a central database that can be accessed by almost all the structures. This system model, which is based on a shared database, is called repository model. Generally speaking, employing the repository model in engineering application is much more efficient than providing a separate database for each sub-system, and thus the data is interchanged with other sub-systems by passing messages to them. The latter concept is applied here on the ‘‘analysis’’ and ‘‘design’’ sub-systems.
Applying the repository model is appropriate when the data is generated by one sub-system and used by the others. The ‘‘members database’’ is totally generated by the ‘‘system generator’’ sub-system. The other sub-systems use the data stored in that database and are allowed to modify some values but they are never allowed to instantiate any new instances in the ‘‘members database’’ sub-system. The same argument applies to ‘‘design parameters database’’, where the ‘‘central controller’’ is the only module that has the responsibility of instantiating and generating this sub-system. Applying the repository model helps in sharing large amounts of data, and reduces the explicit data transfer among the subroutines. Sub-systems that produce data are indifferent to how that data is used by other subsystems. Introducing a new sub-system could be much easier if a compatible interface is developed. For example, introducing a ready sub-system to plot the analysis and the design outputs only requires the construction of an interface that acquires the data from the repository and then transfers it to the suitable methods in the drafting modules. The drafting modules will then do the job and plot the data on the required user graphical interface. In order to work as a whole system, sub-systems must be controlled so that their services are delivered to the right place at the right time. Thus, there is a need to create a control model that handles the control flow between the various sub-systems. The ‘‘central control-
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
ler’’ sub-system shown in Fig. 1 works as a control module for the entire system. This centralized control has overall responsibility of controlling, initializing and terminating the other objects. However, it may devolve control to another sub-system but will expect to have this control responsibility returned to it. This occurs, for example, when the ‘‘optimization’’ sub-system controls the ‘‘structural analysis’’ and the ‘‘concrete design’’ modules. The implementation of the centralized control could be done sequentially (call-return model) or in parallel. The proposed optimization system is designed based on the call-return model, where control starts at the top of the sub-routine hierarchy and, through subroutine calls, passes lower levels in the tree. Prior to the introduction of the object-oriented programming the trend was to use the data-flow model (pipeline), where the system is decomposed into functional modules which accept input data and transform it to output data. Data flows from one module or subroutine to another and is transformed as it moves through the sequence. Despite the fact that the data-flow concept is still used nowadays in some applications, the object-oriented model is considered the superior approach in creating an engineering application. One of the advantages of the use of the object-oriented model in designing engineering applications is that it simulates the real-world entities, thus, it makes the break down of the system much easier to understand. Furthermore, as each entity (class module) encompasses its own complete instance variables and behaviors, it can be reused in other programs. For example, the ‘‘structural analysis’’ and ‘‘design’’ class modules in this case were reused from another program. However, some modifications were required to reuse the ‘‘Structural Analysis’’ module in the proposed program. Still, the implementation of the object can be easily modified without affecting other objects. Thus, the design of the object-oriented module is easier to reuse than that of the data-flow model.
7. Class module details The internal features and the structure of the subsystems and the modules of a system are dictated by the system requirements and specifications, as well as the system structuring articulated at the architectural design phase. The following is a brief discussion for the identification of some classes. Fig. 2 shows an abstract sketch for the Members class module (clsMember). The top part shows the module name, the middle part includes the properties, and the lower part includes the methods. This class module is a part of the Members database.
745
clsMemeber Beam Caption: String Beam Width, Depth, Length: Single Flange Thickness, Width: Single Area, Ixx, Iyy, Izz: Double Number of Section: Integer Number of Load Cases: Integer Include Own Weight: Boolean Density, E, G: Double Section Type: TypeOfSection Enum TypeOfSection RectangleSection = 0 TeeSection = 1 LSection = 2 Custom = 3 End Enum Uniformly Distributed Load Array[] Bending Moment Array[][] Deflection Array[][] ...
Copy Me () Get/Set Width() Get/Set Height() Get/Set Bending Moment () Get/Set Deflection () Get/Set Uniformly Distributed Load () Find Section Properties () ...
Fig. 2. Member class module.
It can be seen that the clsMember has all the attributes of a beam. It stores beam properties such as cross section properties, material constants, and loads. Moreover, it stores the analysis, design, and optimization outputs, the clsMember thus serves as a database. The module decomposition of the clsMember shows that no calculations are performed in the module except for the computation of the section properties. However, many other methods may be assigned to the class module, such as calculating the section forces and deflection. These tasks are, however, assigned here to the analysis module. The same idea is applied to the ‘‘design parameter’’ module. A set of attributes is assigned to the class module that stores material properties, costs, available R-bar sizes, and available deign variables. The ‘‘Copy me ( )’’ method in the clsMember reproduces the object itself in another object. This is useful to create a back up object to store the optimal solution results. It should be noted that using the equating operator ( ¼ ) between two objects will not copy the members of the origin class to the target object but rather assigns a pointer (reference) from the target object to the original one. Instantiating many objects of the clsMember or the ‘‘design parameters class module’’ and then storing each
746
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
kind of object in its stack will form a repository for each kind of object. The ‘‘central controller class module’’ (clsController) includes many methods to enable it to control the overall system. The user is connected to the ‘‘central controller module’’ via a set of interfaces. Through the interfaces the user can request services from the ‘‘central controller’’, such as feeding a new set of design parameters, or modifying an old one. The user feeds the whole geometry of the structure. The ‘‘central controller’’, then, analyzes the details of the members and matches the required geometry to the required set of design variables. The user can perform optimization for more than one slab system for the same geometry by linking each slab system with its appropriate set of ‘‘design parameters object’’. The ‘‘central controller’’, through its attributes and behaviors, is able to organize matching the appropriate objects together to solve the problem correctly. For example, the user can request optimizing a certain slab geometry such as a one-way ribbed slab and then a two-way ribbed slab. The user, then, assigns a certain set of design parameters to each slab system, and assigns the appropriate number of design parameters by specifying whether the system has drop or hidden beams. The ‘‘central controller’’ then controls the behavior of the ‘‘system generator’’ by sending a message to create the suitable system geometry taking into consideration its set of design parameters and its number of design variables. It then invokes the appropriate ‘‘optimization class module’’ to solve the problem. There are different ways to design the ‘‘optimization class module’’ (clsOptimization) to suit the slab system. Fig. 3 shows a part of a class hierarchy for the optimization system. The most general object class (super-class) is presented at the top of the hierarchy (clsOptimization), however, the more specialized object classes (subclasses), which are at the lower level in the hierarchy, inherit the attributes and the behaviors of their superclass. Still, the sub-classes have their own attributes and behaviors as well. Although each class module has the same attribute and method names, each one maintains its own identities. The ‘‘central controller’’ instantiates the suitable class object of the clsOptimization sub-class, and then it invokes the optimization method. This method is available in each sub-class as shown in Fig. 3, however, the behavior of this method is different from one class object to another. The Class diagram, shown in Fig. 4, is a more detailed diagram than the use-case diagram. It provides information about the classes in the system. This diagram identifies each class in the system and defines the required attributes, methods, and associations with the other objects in the system.
The figure shows the association relationships among the system components. The ‘‘central controller’’ is associated with at least one instance of the ‘‘design parameter’’ class and the ‘‘optimization class’’ modules. However, it is associated with only one instance of the ‘‘system generator class’’. The ‘‘system generator’’ object is associated with at least one instance of the ‘‘member class module’’. The ‘‘central controller object’’ could be associated with different instances of the ‘‘optimization class modules’’. For example, there could be many instances of the ‘‘flat plate class module’’ (clsFlatPlate). However, each object of the ‘‘optimization class module’’ is associated with one instance of the ‘‘design parameters’’ and/ or one set of ‘‘member’’ objects. Thus, different slab assignments could easily be created in the system using the same geometrical layout but with different design parameters and/or geometry specifications. In the proposed program the methods of the single instance classes are class methods rather than instance methods. Class methods, as opposed to instance methods, have no knowledge of an individual object’s state. They are intended to provide a service that is independent of a class instance. In the Java Language this type of method is declared as static [13].
8. Program’s flow To design the behavior of an object, it is required to define the operations and services provided by this object. This could be done by constructing a sequence diagram. Fig. 5 shows a summarized sequence diagram of the proposed system. The real sequence diagram of the system is more complicated and includes more details than the one shown here. The sequence diagram shows the actor involved in the interaction, the objects within the system and the operations. The horizontal scale of the diagram represents the system components, while the vertical scale represents the time sequence of the operations. The actor (user) shown in Fig. 5, sets the design parameters through the ‘‘central controller’’. The actor also sets the geometric characteristic of the slabs and the required slab systems to be optimized. The ‘‘central controller’’ initiates the required object and then links it to the design parameter stack. It then stores the design variables and parameters accordingly. When the user requests the ‘‘central controller’’ to solve the problem, it checks the problem input. If the input is correct the process starts by requesting the ‘‘system generator’’ to generate the structural elements that will be used in the analysis process. The ‘‘system generator’’ may consult the ‘‘design parameter’’ entity to initiate the section properties and the material constants.
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
747
clsOptimization Optimal Slab Thickness Optimal Cost Concrete Optimal Cost … Number of Iterations ….. Optimal Failed Due (as UnSatCond) Number of Design Variables Enum UnSatCond optNone = 0 optStrength = 1 optBarSelection = 2 optDeflection = 3 optShear = 4 optDimError = 5 End Enum Search another design variable () Set Data Object () Design Rec Section () Design T-Section () Check Beam Deflection () ...
cls1WRS_Drop
cls2WRS_Hidden
clsFlatPlate
Num. of Design Variables = 3 Optimal Beam Width ...
Num. of Design Variables = 2 Optimal Beam Width ...
Num. of Design Variables = 1 Optimal Beam Width = 0 ...
Design Param. Manager () Find Steel Length () Function and Constraints () Last Variable () Store Optimal Results () Perform Analysis () Design () Cost Estimation () Optimize () ...
Design Param. Manager () Find Steel Length () Function and Constraints () Last Variable () Store Optimal Results () Perform Analysis () Design () Cost Estimation () Optimize () ...
Design Param. Manager () Find Steel Length () Function and Constraints () Last Variable () Store Optimal Results () Perform Analysis () Design () Cost Estimation () Optimize () ...
Fig. 3. Optimization class module.
After the call returns back to the ‘‘central controller’’, it instantiate the appropriate requests for the ‘‘optimization object’’ and invokes its ‘‘optimization method’’. The ‘‘optimization object’’ consults the appropriate ‘‘member object’’ and the appropriate ‘‘design parameter object’’ to initiate the optimization process. It, then, performs structural analysis for the structure by requesting the appropriate method in the specialized ‘‘structural analysis object’’ to do the job, which then returns the analysis outputs back to the ‘‘optimization object’’. The ‘‘optimization object’’ performs the design process by invoking the suitable design methods of the ‘‘structural design object’’. This returns the outputs back to the ‘‘optimization object’’ that stores all the analysis and design outputs in the appropriate member objects
(element entity). The ‘‘optimization object’’ iterates on the solution by searching other design variables and repeats the above process until reaching the optimum solution. The ‘‘optimization object’’ invokes the ‘‘results object’’. This object is designed to store the final results and to facilitate friendly output to the user. Finally, the user may request saving the outputs in a file by invoking the ‘‘save method’’ of the ‘‘results object’’ (clsResults).
9. OOP versus structured programming The favored development philosophy before the object-oriented development was the structured
748
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
clsOptimization
clsDesign
OptimalCost: Single SteelOptimalCost: Single …
DesignCompSteel: Bool. DeepBeam: Boolean …
1..1
1..1
SetDataObject () DesignRecSection () Optimize()
cls1WRS_Drop
Design_Rect() Design_T() Design_Comp() Select_Steel() …
cls2WRS_Hidden
clsFlatPlate
NumDesignVar = 3
NumDesignVar = 2
NumDesignVar = 1
FunctionConstraints () Last Variable () Store Optimal Results () Perform Analysis () …
FunctionConstraints () Last Variable () Store Optimal Results () Perform Analysis () …
FunctionConstraints () Last Variable () Store Optimal Results () Perform Analysis () …
1..*
1..*
SetGeometry() NewDesignParam() EditDesignParam() CreateNewSystem() DeleteSystem() GenerateSystem() SolveProblem() SaveInputFile() OpenInputFile() …
1..1
1..*
1..1 clsController SlabGeometry[]: Single InputFile: String SlabSystems[]: Object DesignParam[]: Object OptProblem [][]: Object MembersStack[]: Object …
1..*
clsDesignParameter
1..1
1..*
Caption: String Fc, Fy: Single ReBarDiam[]: Single ConcUnitCost: Single … GetBlockSize() Get/SetReBarDiam() OpenDataFile() …
1..1
1..1
clsResult
UniformLoad[]: Single BM[][]: Double …. PerformAnalysis() FindFEM() ConstructStiffness() FindSectionBM() GetAnalysisResults() …
clsSystemGenerator Create1WSS_Drop() Create1WRS_Drop() Create2WRS_Drop() Create1WRS_Hidden() Create2WRS_Hidden() CreateFlatPlate() …
1..1
clsAnalysis
SlabSystem: String DesignParam: Object OptimalCost: Single … SaveOutPutFile() SortResultsByCost() SortResultsByType() ….
clsMember
1..1
1..*
BeamCaption: String BeamWidth, Area, Ixx, Iyy, Izz: Double NumSec: Integer OwnWeight():`Double …
1..*
Set/GetWidth() CalculateArea(): Double CalculateIzz(): Double Get/SetBending() CopyMe() …
Fig. 4. Class diagram of the proposed system.
development. In it programmers were expected to plan 100% of a program before writing the code. This heavy pre-code work may lead to good documentation but not necessarily great design [13]. Although the use-case of a program appears almost the same for both development philosophies, the modules decomposition and the internal interaction of the system are totally different. In structured development the representation of entities is oriented towards arrays rather than objects. For example, all the section properties are typically
stored in one array, while material constants are stored in another. Each row then corresponds to a structural member; it is thus required to construct a bookkeeping matrix to track the data indices. Working with parallel arrays complicates the application; since it is always required to search the index of each element to access its appropriate location in another matrix. Some programmers used the defined data type (DDT) to solve the problem of the parallel arrays. Defined data type is a fixed-length record that holds a number of defined types of variables (see Fig. 6). How-
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
:Central Controller
:System Generator
:clsElement
:clsDesign Parameter
:Optimization
:Analysis
:clsDesign
749
:clsResults
Actor Set Design Parameters
New Store
Set Geo. & Slab Sys.
Solve [Check Data]
Generate Beams & Finite Elem.
new
Store
Optimize
Acquire
Acquire
Analyze
Design
Store
Iterate
Check Opt. Criteria View Output
Display
Save
Fig. 5. Sequence diagram of the proposed system.
Type member Caption As String * 20 E As Double Ixx As Double Area As Double Width As Single … End Type … ReDim Elements(NumOfElem) As member Elements(1).Area = .002 Elements(1).Width= .5 …
Fig. 6. Define data type.
ever, although this approach reduces part of the programming and the machine efforts it does not totally eliminate the need for using the parallel array approach, and is not without limitations, such as the limitation of holding arrays as a field in the record. Unlike the DDT, each entity in the OOP can hold indeterminate lengths of arrays, and could be linked to other entities. Changing a certain variable such as the member’s width causes changes in other properties of the member such as the cross section area and inertia. In structured programming the programmer should be aware of this and should thus recalculate the member properties each
750
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
time the dimensions of the section change. This requires invoking the appropriate functions to carry out this task in many different places in the program. On the contrary in OOP the object itself handles the problem. Fig. 7 shows an abbreviated code of the ‘‘member class’’ module (clsMember). The code shown is written using the Java language. The Public ‘‘SetWidth( )’’ method passes new value of ‘‘beam width’’ attribute. This ‘‘method’’ checks the width value and stores it in the private variable ‘‘myWidth’’. Then, the method itself recalculates the other variables that are related to the width, such as the cross section area and the inertia that belong to that member, i.e., updating the private variables myArea, myIxx, myIyy,. . . etc. The same idea is applied on other variables such as the loads. In the current program when ‘‘Set_ Uniformly_Distributed_Load ( )’’ procedure is invoked the fixed end forces are automatically updated correspondingly. It is seen from the above discussion that the structured development depends on creating strong coupling among the program components, which increases the agreed upon rules and complicates the software. In contrast, OOP eliminates these complications, simplifies software design, and makes it more readily upgradeable.
public class clsMember{ /** Private Attributes**/ private float myWidth, Length, myHeight; private float myFlangeWidth, myFlangeThickness; private double myIxx, myIyy , myIzz , myArea; … /** Methods**/ public float width(){ return myWidth; } public void SetWidth(float newWidth){ if (newWidth>=0){ myWidth=newWidth; SetArea(0); SetIxx(0); … } } public void SetArea(double newArea){ if (newArea>0){ myArea=newArea; } //T-Section else if (myFlangeWidth*myFlangeThickness>0){ myArea=myWidth*(myHeight-myFlangeThickness)+ (myFlangeThickness*myFlangeWidth); } //Rectangle else{ myArea=myWidth*myHeight; } } public double Area(){ return myArea; } } …
Fig. 7. Member class module.
10. Possible extensions to the program Currently, the program is not devised to find the geometry of the structure. For example, span length and spacing between spans should be directly fed by the user. However, it is easy to introduce a new class module that describes each joint location, and then link it to the ‘‘clsmember’’ class module via the ‘‘clsSystemGenerator’’ class module to find the geometry of each member. This evolution is quite possible here, in OOP, however it could be complicated to implement in the structural programming. Other possible improvement in this regard is to devise more than one design code class module and add them to the system. The new class modulus should have the same interface used in the current design code class module ‘‘clsDesign’’ see Fig. 4. The clsController passes a message to the clsOptimization to instantiate the required design code class module. Since each slab system has different requirements, each one of them is considered as different class module. This reduces the programming effort and adds powerful features to the program. For example, the user can solve the same slab system using different design variables or parameters. This also supports the prospect of applying concurrent (parallel) processing, such that each slab system with its parameters is considered as a separate problem. Although the use-case of a program appears almost the same for both development philosophies, the modules decomposition and the internal interaction of the system is totally different. It is seen from the above discussion that the structured development depends on creating strong coupling among the program components, which increases the agreed upon rules and complicates the software. In contrast, OOP eliminates these complications, simplifies software design, and makes it more readily upgradable.
11. Case study The program is developed with the intention of obtaining the optimal system and member sizes for any particular layout where column locations are predetermined. A large number of test cases were studied first to verify the functionality of the program and then to examine real life problems [12]. A sample is given here of a study that was made to find the optimal slab system for a regular layout. In this case one condition was imposed on all candidate systems and that is to have no drop beams. In other words the soffit of the slab system is flat. Cost of material, labor and plant have all been taken from the local, Jordanian, market and are consistent with common norms of pricing by contractors. The studied systems include: (1WRS-X-HB) one way
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
joist slab with concrete blocks as formers, (1WRS-XPoly) same but with polystyrene block formers and (1WRS-X-Waffle), one way waffle or trough. The next three are the same but are two way joists (2WRS-HB), (2WRS-Poly) and (2WRS-Waffle). Finally (Flat Plate) is studied. Superimposed dead load of 4 kN/m2 , live load of 3 kN/m2 and self weight are allowed for. In this particular study concrete and reinforcement properties are held constant throughout. Design variables include width and depth of beams and depth of slabs/joists. In this case joists and beams have the same depth. Magnitude of reinforcement, including bar selection, comes as a by product of the design constraints. Many other contributors to the over all design are constants held in the program database such as waffle sizes, concrete and polystyrene blocks sizes, bar diameters, etc. The system under investigation is square in plan, with four equal bays in each direction. The spans are held at 4 m while the optimal solution is determined and then the process is repeated for 5.5, 7, 8.5, 10 and 12 m bay widths. The normalized cost for each system for every span width is shown in Fig. 8. It is evident that all systems are feasible at short spans while only a few are for longer spans. It is also clear that the cost effectiveness of these systems vary from one span width to another. The optimal system for short spans is the one-way ribbed slab with concrete hollow blocks. This is consistent with the fact that this is by far the most prevalent system for such spans in the local industry. Variations were made on the pricing database to reflect other hypothetical regions and as expected the optimal systems were different than those identified for the Jordanian market emphasizing the point for the need to investigate the suitability of systems based on local data and using a methodical optimization techniques. Furthermore, the cost effectiveness of one solution over the other may vary with
3.00 1WRS-X-HB
Normalized Cost
1WRS-X-Poly
2.50
1WRS-X-Waffle 2WRS-HB 2WRS-Poly 2WRS-Waffle
2.00
Flat Plate
1.50
1.00 4
5.5
7
8.5
10
Span (m)
Fig. 8. Results of optimization study.
12
751
time depending on cost of material and labor at that particular time thus underscoring the advantage of the versatility of the developed program and the approach on which it is based.
12. Conclusions 1. To be effective in structural engineering practice, the problem of optimization needs to be applied to a whole system rather than a section or an element. In this case, a software package was developed to find the optimal solution for the structural system of a whole floor. 2. Farkas’ method for discrete nonlinear optimization proved to be quite effective in dealing with the problem of slab systems. Limitations of some other techniques were illustrated. 3. Object-oriented programming has been applied effectively and its advantages have been emphasized particularly as they relate to software development for structural design problems. 4. Particular conclusions were derived in regards to the optimal systems in the Jordanian market. These were consistent with common practice for low spans design. For longer spans, decisive choices in the industry are less obvious. 5. It is emphasized that optimization outcome is highly dependent on the prevalent prices in any particular region at any particular time. The selection of the most suitable system is thus not necessarily an obvious exercise and the developed approach and software in this paper facilitates the expedient and effective selection of systems and dimensions.
References [1] Balling R, Yao X. Optimization of reinforced concrete frames. ASCE J Struct Eng 1997;123(2):193–202. [2] Ramm E, Bletzinger K, Reitinger R, Maute K. The challenge of structural optimization. Civil-Comp Press; 1994. p. 27–52. [3] Choi C, Kwak H. Optimum RC member design with predetermined discrete sections. ASCE Struct Eng 1990;116(10):2634–55. [4] Fox R. Optimization methods for engineering design. 1st ed. Massachusetts: Addison-Wesley; 1971. [5] Gallagher R, Zienkiewicz O. Optimum structural design. 1st ed. New York: J.W. Arrowsmith; 1977. [6] Kirsch U. Optimal structural design. New York: McGraw Hill; 1981. [7] Reddy R, Gupta A, Singh R. Expert system for optimum design of concrete structures. J Comput Civil Eng 1993;(April):146–60. [8] Sarma K, Adeli H. Cost optimization of concrete structures. ASCE J Struct Eng 1998;(May):570–9.
752
A. Al-Assaf, H.S. Saffarini / Computers and Structures 82 (2004) 741–752
[9] Templeman A. Optimization methods in structural design practice. ASCE J Struct Eng 1983;(Oct.):2420–32. [10] Farkas J. Optimum design of metal structures. Chichester: Ellis Horwood Limited; 1984. [11] Belegundu A, Chadrupaltla T. Optimization concepts and applications in engineering. New Jersey: Prentice Hall; 1999. [12] Al-Assaf A. Optimization of reinforced concrete slabs, Master’s degree thesis, University Of Jordan, Jordan, 2001. [13] Cavaness C, Friesen G, Keeton B. Special edition using Java 2. Indiana: Que Corporation; 2001. [14] Coad P, Yourdon E. Object-oriented analysis. Englewood Cliffs, NJ: Prentice-Hall; 1990. [15] Robinson J. Hierarchical object-oriented design. Englewood Cliffs, NJ: Prentice-Hall; 1992. [16] Graham I. Object-oriented methods. 2nd ed. Wokingham: Addison-Wesley; 1994.
[17] Rumbaugh J, Jacobson I. The unified software development process. Reading, MA: Addison-Wesley; 1999. [18] Sommerville I. Software engineering. New York: AddisonWesley; 2001. [19] TriReme courses, UML Tutorial, 2001, TriReme International Ltd., Available from: http://uml.tutorials.trireme.com. [20] Archer GC, Fenves G, Thewalt C. A new object-oriented finite element analysis program architecture. Comput Struct 1999;70(1999):63–75. [21] Mackie R. Using object to handle calculation control in finite element modeling. Comput Struct 2002;80:2001–9. [22] Hadi M. Neural networks applications in concrete structures. Comput Sturct 2003;81(2003):373–81. [23] Tabatabai S. Object-oriented finite element-based and progressive steel weight minimization. Finite Elements Anal Des 2002;39(2002):55–76.