This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 Object and Cognitive Activities
Intellectual activity is a creative endeavor; it is a function of innate skills, experience, motivation, and focus. It is well known that we humans can conceptualize very complex ideas, without any real understanding of the immense detail needed to implement those ideas. Software development then depends on our abilities to implement the complex ideas we have conceptualized. So the first thing that happens is that we run head on into the immense details needed to implement our idea(s). It has been known since Aristotle's time that we can best handle complexity using the divide-and-conquer method. This is fine for the human mind, which is an outstanding analytical engine. But what about expressing and understanding a meta-representation of this immense detail, in a foreign language, on a deterministic analytical electronic calculating engine?
Structured Methodology has taken the idea of divide-and-conquer to handle complexity to a much higher level of accomplishment in software development than ever before. However, even this has not provided the overall improvement in production, accuracy, and cost-effectiveness that must occur in software development. Instead of the divide-and-conquer approach, we must group the immense details into functionally intelligent agents. These agents can operate on behalf of the software developer in implementing the developer's conceptualized idea. In the creation of any software solution, for any idea, there is a great deal of repeated techniques used from other solutions or experiences.
As we mentioned above, this brings us to the next big paradigm shift in software development, "Object Methodology." The creation of objects, where any one object represents some functionally intelligent grouping of details, gives the software developer a higher meta-level upon which to base the solution creation. The developer can now start to think in terms of object behavior, without worrying about how this behavior is implemented or handled. They can develop clusters of objects in relationships that solve various functional requirements of their conceptualized idea. The human mind does just this type of object clustering and management in solving various mental problems.
What we are looking for in the use of objects and components in software development is a technology that will empower individual programmers with a greater and quicker ability to create. We thus want to change the software development process by empowering programmers through object and component assembly technology. The current software development process will not evolve past its current state of crisis by using the same techniques that have created the situation. So the programmer must shift to a more natural way of thinking, one in terms of objects (components) to solve and create software. It was Einstein who recognized, "The world will not evolve past its current state of crisis by using the same thinking that created the situation." There is no greater possibility for software development than the continual, successful reduction of the rich complexity of software to simple objects, comprehensible to all programmers. We must shift from "a view in which the accent has been on parts and elements, to a configuration view, with the emphasis on wholes and patterns." Rather than beginning with the pieces of a puzzle and proceeding to construct the puzzle, we begin with a picture of the puzzle and place each piece (object) by constantly referencing the whole.
One of the new software books, Design Patterns, Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995), shows the increasing interest and understanding in the holistic view of software development. Design Patterns is a significant text because it classifies class relationships without presenting a grand methodology. On the other hand, it is generic, with no reference to any particular scheme. In this book we are going to show how the programmer's cognitive understanding of the objects in the domain greatly influences the subsequent creation of the software. This understanding will also greatly influence the programmer's selection and use of the base classes (objects) in the actual creation of the software. We will continue to get more pragmatic the deeper we get into this book.
So, having said all of that, just what is this chapter all about? It's about what "Object Methodology" and the .NET Framework base classes do, and what possibly they can do, to aid the software developer. This chapter also touches upon cognition and its role in the problem-solving paradigm of software design. It's about how we can use COBOL.NET and assemble existing objects to solve our software development problems. It's about how we create new objects, for continual reuse, in our ongoing need to develop software. It's about the current techniques used in the Visual Studio.NET COBOL development environment. It's about the Fujitsu object-oriented language COBOL compiler and its capabilities for creating new .NET Framework software applications. We will later be covering how COBOL legacy code can be converted and used in the .NET Framework.