1. THE SOFTWARE CRISIS

The phrase software crisis alludes to a set of problems encountered in the development of computer software during the 1960s. Within this period the software industry unsuccessfully attempted to build larger and larger software systems (to match advances in hardware technology) by simply scaling up existing development techniques. As a result:

1. Schedule and cost estimates were often grossly inaccurate.

2. Productivity of programmers could not keep up with demand.
3. Poor quality software was produced.

To address these problems the discipline of software engineering came into being. The term (coined by a NATO study group in 1967) is intended to reflect the idea that the practice of building and maintaining software systems should be as rigorous as that found in traditional engineering disciplines.

2. SOFTWARE ENGINEERING

We can define software engineering as follows:

(Software engineering is) the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.

This embodies a number of themes:

1. It is a discipline to help produce programs that are:

	Correct
	Efficient
	Understandable
	Satisfy their specification

2. It describes a multi-stage process in which the output from one process becomes the input to the next - known as the software life cycle.
3. It encourages the use of tools and techniques.

3. THE SOFTWARE LIFE CYCLE

From the above one of the key themes of software engineering is that, like any other commercial product, software has a life cycle associated with it. Figure 1 shows the principal stages that comprise this life cycle. These are the standard stages that we can expect to be associated with the development of any software system (not necessarily a OO system).

Figure 1: Processes associated with a general model of the software life cycle.

Software development encompasses the middle four stages: system analysis and design, software design, implementation and unit testing, and system testing. The individual phases of the above life cycle are briefly described below.

Requirements analysis and specification. Work begins by establishing and analysing the requirements of the procurer (usually the end user), i.e. determining the nature of the system to be built (in terms of hardware and software). Requirements analysis usually results in a requirements specification document or (for small software systems) a requirements specification statement. This specification then defines the "product", and thus must be accepted by both the customer and the developers. In other words it has some legal standing. Requirements analysis and specification are beyond the scope of COMP101.

System Analysis and Design. The second phase is to analyse the requirements and produce a "high-level" design of the proposed system (again in terms of hardware and software). There are many approaches to system analysis and design.

Software Design. The third phase is to produce a detailed design of the desired software sometimes referred to as a software specification. The idea behind a software design/specification is that it is (implementation) "language independent". You should be able to give the design to different programmers to implement in different languages and get a working result in all cases. The detailed design can be thought of as a "model" of the system that is envisaged, and its implementation its physical realisation.

To determine whether you have produced a good design or not you should ask yourself the following, "if I gave this design to one of my colleagues would they be able to produce the software that I envisage?" If the answer to this question is "No" then you should reconsider your design. Again there are many approaches to design/ specification. We will be using diagrammatic techniques (Nassi- Shneiderman charts and control flow diagrams) supported by data tables to design our software.

Unit Testing and Implementation. During implementation the design is translated into a machine-readable (and consequently executable) form. Some "unit" testing normally takes place as the implementation progresses. By unit testing we mean the testing of sub-assemblies of the program.

Testing. Once the implementation has been completed it must be tested to ensure that all parts of the program behave in the manner that they are expected to behave. One straight-forward approach in which software can be tested is to identify "meaningful" test cases with which the software can be run. The results produced can then be compared with the expected results and appropriate conclusions drawn. On completion of testing the product is delivered to the customer.

Maintenance As with any other commercial product, software must be maintained once it has been delivered. We can identify three categories of maintenance:

	Corrective maintenance - correction of errors that were not discovered earlier on in the development process.
	Adaptive maintenance - modification to accommodate changes in the software's external operating environment.
	Perfective maintenance - inclusion of additions functionality not originally identified during requirements analysis and specification, i.e,. extending the software beyond its original requirements.

Maintenance, although perceived as being unglamorous, takes up a considerable amount of the total effort expanded throughout the software life cycle. It is difficult to quantify the amount of effort involve, but some authors claim between 50% and 70% of the total effort depending on the nature of the application. A primary aim of program development should therefore be to reduce the effort required for maintenance by designing the code with a view to "easy maintenance".

Essentially the maintenance task is greatly eased by writing code that can easily be understood by persons not involved in the original production of the software. Thus anything that enhances the readability of software, and consequently its understandability is a good thing.

4. THE OBJECT-ORIENTATED METHODOLOGY

A systematic approach to software engineering (i.e. a methodology --- a way of doing things) simplifies the process and results in software which is understandable, verifiable and reliable without stifling the creativity of the software engineer. One such methodology is the Object Oriented approach (Booch 1982), usually referred to by the acronym OOAD (Object Oriented Analysis and Design). OOAD "dove-tails" nicely with the use of object-oriented languages, such as Java, as the implementation language. Object-oriented languages encourage (enforce?) the OOAD paradigm.

Thus, unlike other programming language paradigms the object-oriented paradigm is both a programming style (Object-Oriented Programming --- OOP) as well as an approach to software engineering.

The principal features of the methodology are:

1. Flexibility and adaptability
2. Software reuse and extension
3. Information hiding
4. Consistent notation and integration of the various software engineering phases.
5. Reliability

So what is "object orientation"? The key element of the Object Oriented methodology, as the name suggests, is the object. An object is some real world entity which a programmer wishes to "model". In Figure 2 an "object", let us call it bob (object names, by convention, commence with a lower case letter) is shown. It has many characteristics (attributes) including: 6 sides to its body, 2 arms and 2 legs. Let us also say that this particular object's function is to add up pairs of numbers.

Figure 2: A "cube" object.

In Figure 3, a similar object, let us call it mary, to that presented in Figure 2 is given (except that it has 4 legs).

Figure 3: Another "cube" object.

In OO parlance the characteristics or attributes of an object (i.e. the "number of legs" in the example given here) are referred to as its fields, and its functions (i.e. "adding up pairs of numbers" in the example given here) as methods. Collectively fields and methods are referred to as members.

The characteristics (nature) of objects are defined by what is termed a class. In the case of Bob and Mary they might both belong to a class called CubeObject. The class CubeObject might then be described as shown in Figure 4. (Note: the form of table presented in Figure 4 is known as a class diagram and is a common diagrammatic technique used in object oriented software engineering.)

Figure 4: Class diagram for the class CubeObject.

So object-orientation is a mechanism for modelling problems in terms of things known as objects which are in turn defined in terms of a class.

The stages involved in the object-oriented approach can be mapped on to the stages associated with the general life cycle given in Figure 1. A suggested mapping is presented in Figure 5. Note that the diagram includes some techniques that we will be adopting (more on this later in the text). The key difference between Figure 5 and 1 is that the implementation has been divided into a class branch and an application branch. If the class part already exists (having been previously developed as part of some other application) then we can omit this branch. The class concept allows us to do this.

It is this distinction between classes and applications that results in the first three of the above listed features of the methodology.

Flexibility and Adaptability, and Software Reuse and Extension: Classes can be associated with many different applications (and vice-versa) and can be worked on (altered, refined or updated) in isolation.

Information Hiding: A programmer working on an application need not be concerned with detail of the operation of particular classes.

The fourth feature (Consistent Notation and Integration) is self-evident, unique to the OO approach and results in the fifth feature (Reliability) --- although this last is of course a claim made by all software development methodologies!

Figure 5: Refined software engineering life cycle model for the object oriented paradigm (reference to specific tools to support the process are included in parenthesis).

5. UNIFIED MODELLING LANGUAGE (UML)

In the 1980s as increasing numbers of organisations started to convert to the OO paradigm and developed their own OOAD methodologies and procedures each using dedicated languages and notations. This proliferation of OOAD languages and notations meant that there were no standard OOAD tools available, and personnel required retraining whenever they changed organisations. By the early 1990s it was clear that a standard OOAD language and notation was needed.

In 1994 the Object Management Group (OMG), a non-profit making Organisation seeking to promote the use of the OO paradigm, invited submissions for a common modelling language. A group of corporations, known as the UML partners (HP, IBM, Microsoft, Oracle, Rational Software), developed UML version 1.1 through a process of unifying a number of existing techniques, and submitted it to OMG. The submission was accepted in 1997 with OMG taken on the responsibility, as a non-profit making organisation, for its further development. Version 1.4 was released in 2001.

UML does not define any particular methodology for OODA, but instead defines a set of twelve types of diagrams that can be used to support methodologies in a commonly understood manner (it is not necessary to use all 12). The available diagrams are divided into three categories:

1. Structural Diagrams to represent the static structure of an OO software system:
   1. Class Diagrams (see Section 6.1 below)
   2. Object Diagrams
   3. Component Diagrams
   4. Deployment Diagrams
2. Behavior Diagrams to represent different aspects of the dynamic behavior of a software system:
   1. Use Case Diagrams
   2. Sequence Diagrams
   3. Activity Diagrams (see Section 6.3 below)
   4. Collaboration Diagrams
   5. State chart Diagrams
3. Model Management Diagrams to represent ways of organising and managing applications:
   1. Packages
   2. Subsystems
   3. Models

The lack of an accompanying UML methodology has been the cause of much academic criticism. however UML is fast becoming (summer 2002) the industry standard.

It is not the intention for COMP101 students to become fully familiar with UML, this is done elsewhere, however we will be using some UML notation where appropriate. In particular we will be using Class and Activity Diagrams.

6. THE COMP101 OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD) METHODOLOGY

We have seen that the software analysis and design process comprises four stages:

1. System analysis and design,
2. Software design,
3. Implementation and unit testing, and
4. System testing.

We commence the COMP101 OOAD methodology with an analysis phase where the software engineer identifies the classes/objects required by a particular application and the relationships between them. There are many techniques available to support this process. One of the most straight forward is to build a class diagram as prescribed by UML (see example in Figure 4), i.e. a diagrammatic representation of the classes required by an application and their interconnectivity.

During the software design phase the algorithmic aspects of a software system are considered. An algorithm is a "precise and unambiguous sequence of steps that must be followed to solve a problem". The term is derived from Al-Khwarizmi (Figure 4); Mohamed ibn Musa Al-Khwarizmi was an Islamic (some would argue Persian) mathematician who wrote a treatise (in about 825 A.D.) called "Hisab al-jabr w'al-muqabala" (the science of reaction and calculation), and consequently gave rise to the word algebra ("al-jabr").

Many techniques exist to support the design of algorithms. In this text we will be using Nassi-Shneiderman (NS) charts. This is a a graphical design tool whereby algorithms are defined in terms of sequences of one or more "boxes". NS charts predate UML; essentially NS charts belong to another programming paradigm known as the imperative paradigm. However, at the most detailed level of software design the OO and imperative paradigms come together.

The sequence where by a program is executed is referred to as the flow of control. This is generally conceptualised as starting at the top of a program and flowing down to exit at the bottom. A complex program may incorporate many choice points and loops whereby flow of control is not immediately obvious. UML activity diagrams are a graphical method of indicating the flow of control through a software system. (A similar style of diagram is found in the imperative paradigm known as Control Flow Diagrams or CFDs.)

Figure 4: A conjectured drawing of Al-Khwarizmi taken from a Russian stamp (REF: "http://jeff560.tripod.com/khowar.jpg).

7. GLOSSARY