|
Engineering Principles and The Object Oriented Methodology
|
|
Contact
Community |
By D. Bruce McCowan, P.Eng.
The computer programmer's Object Oriented methodology is an attempt to model discrete aspects of the real world according to a strict set of principles. The current "state" of a real-world "Object" is fully described in terms of its "attributes" or properties, which, in turn, are represented in the object-oriented paradigm by the software data variables. The objects attributes -- and the state of the object -- can only be changed through the implementation of the object's own precisely defined behaviour patterns or methods, represented in the object paradigm by modules of program procedure code. In some models, when in a certain state, the object may only be "changed" by a certain subset of it's methods. The "Object" encapsulates its attributes and methods together. This isolation of an object from external influences permits a simple model to be abstracted from a more complex real-world phenomena. The object-oriented model requires that each object have an identity that distinguishes it from all other objects. Specialized objects can inherit both attributes and behaviour from more fundamental generalized objects - thus providing a hierarchy of "classes" of objects. Objects within a system can communicate with one another by passing "messages" back and forth requesting that certain actions be taken. Finally, an entire system can be described in terms of its component objects in communication with one another. The system changes its state as its component objects change their own state by invoking their personal behaviour methods. It must be stressed that object-oriented analysis and programming involves much more than the organization of so-called "objects" on a graphical user interface using "object-based" development tools. Engineers, too, think in terms of discrete objects as they model physical systems, processes and load / reaction phenomena. For example, one valuable concept in the engineer's toolbox is the notion of equilibrium of a rigid body. A rigid body is in equilibrium when all external forces acting upon it comprise a system of forces equivalent to zero. The actual tool that the engineer uses in the "system analysis" is the "free body diagram" . Like the Programmer-Analyst, the engineer must first clearly determine just what constitutes the free body -- or object -- of interest. The engineer then detaches the free body from the ground and from all other bodies. Any connections to the ground or to other bodies are effectively replaced by the forces acting on the free body. The engineer thus isolates an object, reducing its environment to the simple system of forces that act upon it. This notion of analyzing a body in isolation can be extended from rigid bodies to deformable bodies. The magnitude, orientation and points of action of the various forces acting on a deformable body can be simplified and manipulated mathematically. The geometric distribution of the materials that make up the body, together with the strength properties of those materials, generally describe the resistivity of the body structure to the shear, bending and torsional components of the simplified forces or loads. Thus, the engineer's deformable body or "object" is described in terms of its materials and the distribution of those materials in space. Like the programmer's object, the engineer's object can only be modified - sheared, deflected or twisted - by the loads or forces to which he or she has conceptually connected it. This object approach is extremely useful to the engineer in structural design situations. Over many decades, engineers have conducted load tests on thousands of samples of structural members, each having its own characteristic shape and material composition (given the tolerances associated with its particular designation). The familiar steel "I-beam", for example, has numerous geometric configurations, for which maximum allowable loads (of various configurations) have each been tabulated. In design work, structural members - or "objects" -- are selected on the basis of having shape and other properties that adequately resist expected environmental loads. These applied environmental loads themselves are simplified representations of what could actually occur in real life. It is important to note that such structural members are not generally selected following structural analysis and design from first principles, but rather, by using the empirical data collected through years of "Object" research and development by engineers. It is crucial to point out that very extensive "testing" of structural objects must be conducted before engineers publish related empirical design data. The public safety is of paramount concern to the engineer. Hence, whether designing structures or safety-related software, the engineer must be fully satisfied that prevailing standards and design goals for safety, including consideration of tolerance stackups, system redundancies and factors of safety, have all been met. For safety-related software development, it is important that engineers be members of the development team. |