CS302: Software Engineering

Object orientation, based on the contents of tables and diagrams, provides a detailed, reasonably complete view of an application. Exceptions to this view are human interface design and specific attention to database, input, and output design. Object-oriented design is distinguished by three characteristics: detail, all potential environments are accommodated, and the need for an object-oriented implementation environment to obtain the payoff from the exercise.

The extensive detail generated in object-oriented design leads directly to module specification which should be straightforward since the definition of process details, the class/object data, constraints, and message communications are all completely defined.

Object orientation, as seen by the exercise in the chapter, can accommodate even nonobject-oriented environments. The benefit of OOD's ability to accommodate any application environment is that, for on-line, object application environments, the methodology does lead to information hiding, minimal coupling, and maximal cohesion by virtue of the thinking processes. Object orientation requires good understanding of operating system concepts, object thinking, and interactions between services and applications. The design process, as the chapter appendix shows, requires iteration and proto typing to get required levels of detail and to ensure efficient processing of message traffic. Most important, object thinking IS NOT the same as entity thinking or as process and data methodology thinking. Object orientation requires a paradigm shift to be done correctly.

Object orientation is not very object-oriented in an SQL implementation environment. The choice of SQL changes the entire design from what it would be in an object environment to be object-based. Like COBOL, the methodology can be made to do anything. Is this the best use of OOD? Not in my opinion. Unless an application is at least on-line and will be in an object-oriented environment, the work required for object-oriented design is not worth the effort. Especially with a fourth-generation DBMS, like SQL, the undesign that must be done wastes tremendous time and could result in a worse design than use of some other methodology. While this compromise is acceptable for a small, on-line application such as ABC, it would not be acceptable for applications with real-time or more complex processing requirements. Much of the effort to develop an object-oriented design is wasted when the implementation environment is not object-oriented. Therefore, the choice of methodology should be driven by the expected implementation environment.