Introduction to Object Oriented Methodologies - Appendices - Software Engineering: A Methodical Approach (2014)

Software Engineering: A Methodical Approach (2014)

PART G. Appendices

This final division contains additional information that the more curious reader may peruse. It includes additional topics in OOM, excerpts from the initial system requirements, the requirements specification, and the design specification for an inventory management system. The chapters are:

· Appendix 1 — Introduction to Object-Oriented Methodologies

· Appendix 2 — Basic Concepts of Object-Oriented Methodologies

· Appendix 3 — Object-Oriented Information Engineering

· Appendix 4 — Basic Guidelines of Object-Oriented Methodologies

· Appendix 5 — Categorizing Objects

· Appendix 6 — Specifying Object Behavior

· Appendix 7 — Tools for Object-Oriented Methodologies

· Appendix 8 — Excerpts from the ISR of the Inventory Management System

· Appendix 9 — Excerpts from the RS of the Inventory Management System

· Appendix 10 — Excerpts from the DS of the Inventory Management System

Appendix 1. Introduction to Object Oriented Methodologies

This chapter contains:

· Software Revolution and Rationale for Object-Oriented Techniques

· Information Engineering and the Object-Oriented Approach

· Integrating Hi-tech Technologies

· Characteristics of Object-Oriented Methodologies

· Benefits of Object-Oriented Methodologies

· Summary and Concluding Remarks

A1.1 Software Revolution and Rationale for Object-Oriented Techniques

One serious anomaly in information technology is the advancement of hardware technology disproportionately to software technology. We are in the sixth generation of computer hardware; we are in the fourth generation (perhaps the fifth depending on one’s perspective) of computer software.

Software generations include the following:

· Machine code

· Assembly language

· High-level languages; databases based on hierarchical and network approaches

· Relational systems, 4GL’s, CASE tools, and applications

· I-CASE, object-oriented techniques, multi-agent applications, and intelligent systems

One urgent concern in the software industry today is to create more complex software, faster and at lower costs. The industry demands at reduced cost, a quantum leap in:

· Complexity

· Reliability

· Design capability

· Flexibility

· Speed of development

· Ease of change

· Ease of usage

How can the software engineering industry respond to this huge demand? How can software engineers be equipped to produce software of a much higher quality than ever demanded before, at a fraction of the time? A few years ago, companies would be willing to invest millions of dollars into the development of business applications that took three to five years to be fully operational. Today, these companies demand immediate solutions, and they want more sophistication, more flexibility, and more convenience.

As the software engineering industry gropes for a solution to the demands of 21st century lifestyle, a principle worth remembering is, “Great engineering is simple engineering” (see [Martin, 1993]). Object-oriented (OO) techniques simplify the design of complex systems; so far, it is the best promise of the quantum leaps demanded by industry. Through OO techniques, complex software can be designed and constructed block-by-block, component-by-component. Moreover, tested and proven components can be reused multiple times for the construction of other systems, potentially spiraling into a maze of complex, sophisticated software which was once inconceivable to many.

OO methodologies (OOM) involve the use of OO techniques to build computer software. It involves OO analysis and design (OOAD), as well as OO programming languages (OOPLs). It also involves the application of object-oriented technology (OOT or OT) to problem-solving.

A1.2 Information Engineering and the Object-Oriented Approach

Traditionally, software systems have been developed through a life cycle model approach of investigation, analysis, design, development, implementation and maintenance. These activities were separate, often done by different people. Further, systems were developed in a piecemeal fashion — roughly on a department-by-department basis. This traditional approach still prevails in a number of organizations.

Information engineering (IE) is about looking at the entire enterprise as a system of interrelated sub-systems, then proposing and engineering a strategic information system that meets the corporate goals and objectives of the enterprise. It is more dynamic, challenging and rewarding than the traditional approach. As an illustration, the CUAIS (college/university administrative information system) information topology chart (ITC) of Figure A1-1, provides excerpts from a comprehensive, integrated information system for a college/university, as opposed to a department-wise automation.

image

Figure A1-1. Information Topology Chart for the CUAIS Project

Whereas the traditional approach is usually managed at the middle management level, enterprise-wide engineering must be managed at the executive level, if it is to be successful. The information technology (IT) professional in charge must be very experienced, well versed in information systems, and able to inspire confidence at all levels of the organization.

We can apply OOM to information engineering in a way that enables users to conceptualize an information system as a set of interacting, inter-related component objects. At the highest level, the entire system is a large object. The component objects encompasses encapsulated states (data), methods and means of communicating with each other as well as with other external objects, all this being transparent to the end-user.

When OOM is applied to information engineering, the process becomes more effective and rewarding. We use the term OO information engineering (OOIE) to describe this scenario. In OOIE, the modeling process is more integrated, involving the previously disjointed activities of investigation, design, development, implementation and maintenance — assuming the use of OO-ICASE tools (which will be discussed in Appendix 7).

Another term that you will hear bandied around is OO enterprise modeling (OOEM). Some authors like to parse and dissect and come up with differences between OOIE and OOEM. This course makes no such distinction. OOIE and OOEM essentially describe the same thing. Use of one term over another is a matter of personal preference. Appendix 3 will revisit the topic and provide more details.

A1.3 Integrating Hi-tech Technologies

OO analysis and design (OOAD) is not OO programming (in the early days of OOM, the two were mistaken to be the same). Any high-level language can implement an OO design, some more elegantly than others. An OO high level language (which will be subsequently discussed) facilitates easy implementation of certain of OO concepts, for example: class, inheritance, encapsulation, etc. So do OO-CASE tools.

OOAD facilitates the integration of a number of leading technologies (so called hi-tech) towards the generation of complex systems, with a number of advantages as spin-offs. The technologies include:

· CASE and I-CASE

· Visual Programming via OO programming languages (OOPLs)

· Code Generation

· Repository and Class Libraries

· Repository-Based Methodologies

· Information Engineering

· OO Databases

· Non-procedural languages

· Formal (Mathematically-Based) Methods

· Client-Server Technology

According to Martin’s prediction, “the sooner OOAD becomes widespread, the sooner software creation will progress from a cottage industry to an engineering discipline” (see [Martin, 1993]). We are in the midst of that transformation.

A1.4 Characteristics of Object-Oriented Methodologies

Figure A1-2 provides some fundamental characteristics of OOM: These characteristics lead to various benefits as mentioned in the upcoming section.

image

Figure A1-2. Characteristics of OOM Summarized

A1.5 Benefits of Object-Oriented Methodologies

Object technology offers many benefits to the software engineering industry and the business environment. The more prominent ones are mentioned in Figure A1-3. Indeed, OO methodologies have become commonplace in the software engineering industry. To attempt software engineering in a manner that is oblivious to these methodologies would be at best extremely risky.

image

Figure A1-3. Benefits of OOM

A1.6 Summary and Concluding Remarks

Let us summarize what we have covered so far:

· There is a disproportional advancement in computer hardware when compared to computer software. Nonetheless, the software engineering industry has made quantum leaps and has achieved an astounding lot over the past five decades.

· To write quality software in the twenty first century is a very challenging experience: Users are demanding more complexity, flexibility and functionality for less cost and within a much shorter timeframe. Because of this, software engineering via traditional methods is an early non-starter. OOM and OOSE present the opportunity to meet the demands of the current era.

· Information engineering (IE) is the act of engineering the information infrastructure of an organization via OO methodologies. The result is a more efficient organization and information infrastructure.

· OOM facilitates the integration of various technologies for the more efficient operation of the organization.

· OOM brings a number of significant advantages to the software engineering industry and the business environment.

Against this background, we may now proceed to a discussion of the fundamentals of the OO approach to software engineering. This will be done in the next chapter.

A1.7 Recommended Readings

[Due, 2002] Due’, Richard T. Mentoring Object Technology Projects. Saddle River, New Jersey: Prentice Hall, 2002. See chapters 1 and 2.

[Lethbridge, 2005] Lethbridge, Timothy C. and Robert Laganiere. Object-Oriented Software Engineering 2nd ed. Berkshire, England: McGraw-Hill, 2005. See chapter 1.

[Martin, 1993] Martin, James and James Odell. Principles of Object Oriented Analysis and Design. Englewood Cliffs, New Jersey: Prentice Hall, 1993. See chapters 1 and 3.