Object-Oriented COBOL Programming Using the .NET Framework
- Componentware, Cognition, and Software Development
- Object and Cognitive Activities
- What Is an Object?
- What Is a Software Object?
- Object-Oriented Programming with COBOL
- COBOL Classes and Language Interoperability
- COBOL Classes and the .NET Base Classes
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.1 Componentware, Cognition, and Software Development
It has often been said we humans make artifacts in our own image. As we gradually rise out of the current quagmire of software development, we are starting to create software along the mental model of how we think. Although human-to-human communication is not perfect, it is amazing how well we interface together. A key element is the mental objects, defined pretty much the same from human to human. We have general agreement on the idea content of each of these objects (messages) we are moving between us. This mental model has been at the core of the rise of object-oriented programming in all its forms.
The specification of software, both functionally and detail design wise, is one of the most critical steps in the creation of a new software project. Unfortunately, these specifications are often ill defined and are one of the more subjective areas currently involved in the intelligent and profitable creation of new software. Currently the human elements of background experience, personality traits, and motivation heavily bias the specifications and subsequent creation of the software. Each human brings to the project table a different set of expectations, capabilities, and desires. The current "software crisis" is influenced heavily by the human psychology profile differences in the team mixture. Of course, the increasing complexity of software is more and more becoming the amplification factor of these human traits.
One of the forms that object-oriented programming is taking is the creation of standard objects we can share between the human programmers and other project team members. Now we are starting to create software objects that will serve the same type of communication and control functions as mental objects, with well-defined behavior to offset a majority of all the bad human traits currently involved in software creation. The creation of these mental/software objects will aid the programmer in establishing more cognitive awareness of the structure and content of the program. Why does the programmer need more cognitive contact with the software? Because the programmer is the cognizer of the software. It is the programmer's mental functions that are being imposed upon the creation of the software. It is the programmer's understanding of the software goals that will direct the creation of the software.
The human learns early on as a child to recognize objects. A child learns to abstract objects very early. For example, a child will understand the abstract object chair, but realizes that there are many derived chair types. Finally, this object learning paradigm has made its way into software development. We are able to create an abstract object class and then, via inheritance, derive a specific object from it. We are able to encapsulate involved functionality with the object. The cognizer then is able to start thinking about domain-specific needs and goals in terms of these abstract and derived objects. The cognizer can conceptualize and create on a much higher level of mental activity due to the object characteristics.
We focus in this book on the Microsoft .NET Framework base classes and their use with COBOL. Microsoft created the base classes to allow the new software technologies of object methodology to be standardized, to greatly enhance the overall software development cycle. The base classes encapsulate the large set of Application Program Interface functions (Win32 APIs) that are used to dialogue with the Microsoft Windows operating systems. They also handle all communication with the Common Language Runtime (CLR) that does the interface with the Win32 APIs. These predefined base classes will allow us to develop functional and detailed design specifications based upon standard objects prespecified for behavior. This greatly facilitates human communications in the software development process because all project team members can review the standard specifications. These new concepts in software development give the project team a great deal of potential technical continuity from the front end of the project to the back end of the project.
For the first time these base classes, along with the CLR, give us language interoperability so that team members working in different languages have a common foundation upon which to communicate with other team members. Fujitsu COBOL, Microsoft C#, Microsoft Visual C++, and Microsoft Visual Basic are major languages for the creation of software objects and components. The .NET Framework is one of the first major cohesive object software sets that has the scope and depth to have a major impact on current and future software development. A great deal of the large fluctuations between individual programmers is eliminated by the standardization achieved by the use of this collection of software objects. To take it one step further, it is a major cornerstone in the Microsoft Application Framework. Again, the purpose of this application framework is to allow well-defined objects, behaving in well-known ways, to be used by unwell-behaved programmers, which will result in the creation of a better-behaved software development cycle. The Microsoft Visual Studio.NET development environment has extended its philosophy of having software development wizards aid in the creation of software to also having software development wizards to aid in the development of components.
Many current books on objects and components tell programmers how to create objects and components for inclusion in other programs. Some books mention the usage of ActiveX controls as the building blocks for creating whole applications. Not many current books take the viewpoint of the programmer as well as other project people wanting to use rather than develop objects and components. Constructing computer applications by assembling prebuilt software objects (and now components) has long been a goal of software engineering. With the advent of software (mental) objects, as defined in object-oriented programming, and the definition of components, we are starting to put in place the concepts and software tools for fulfilling this goal. But just what are the overall application project design issues raised when applications are created by assembling objects and components? What impact does this have on the cognition of understanding the software goals and design steps? There are architectural questions, like the division of functionality and location of the User Interface (UI) code. What are some of the implementation issues with the .NET Framework, when integrating many assemblies?
So, just how do the programmer and other project people go about using these new software objects? Just what are they currently, and how do we interface them to solve new software applications? What kind of a mental model should the programmer look to develop for the expected software development? This book is going to address such issues. It will cover how we may construct new software applications by assembling prebuilt software objects. It will cover the issues of constructing applications using software objects when the applications are distributed over a network. We will always keep in mind the recent advances in cognitive science to gain an appreciation of how the work in cognitive science and object methodology is starting to form a symbiosis to aid the software developer.