• Incorporate Bruegge  & Dutoit's UMLs of (1) Software Engineering Concepts and (2) S.E. development activities?
  
• 13 UML 2.0 Diagram types, from VP-UML 5 documentation.
  
• Using interfaces effectively implements information hiding, i.e. the separation of declaration and definition.
  
• pink text needs to be modified, updated, etc.
  
• Incorporate FIB, below, for sections already covered in the OUMLCD, e.g. section 4?
  
• Incorporate more on visibility and its categories or leave this to OUMLCD.
• Add patterns and frameworks to software architectures (Use Comm. of ACM, Oct 2000).  Booch: A component is "a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces", and a framework is "an architectural pattern that provides an extensible template for applications within a domain."
• Expand treatment of nested/inner classes.

Major reorganization completed: 1/24/03; major update started 2/12/05; 2/20/06
This Learning Module will probably be permanently under reconstruction!
However, as of the above date it is the most current version and is complete  except for
a few links, assessment tools, and study guide facilities.

LEARNING MODULE I
OVERVIEW OF
OBJECT-ORIENTED SOFTWARE DEVELOPMENT

"Many people tell the story of the CEO of a software company who claimed that his product would be object-oriented
               because it was being written in C++ [Java, Smalltalk, etc.]. Some tell the story without knowing that it is a joke."
-Adele Goldberg

"We can write good or bad programs with any tool.
Unless we teach people how to design, the languages matter very little."
-David Parnas

Java is programming language that implements (1) the Object Oriented Software Development (OOSD) paradigm and (2) other modern  facilities such as distributed processing, concurrency, exception handling, etc. Therefore it is essential to have a fundamental understanding of the basic concepts of OOSD before studying Java!  This first Learning Module provides a global context within which Java will be subsequently presented, in this course, as a specific implementation of the OOSD  pardigm.  This introductory learning module presents a summary of the concepts on which the OOSD paradigm is based.  It endeavors to illustrate how current OOSD environments are the result of an evolution of programming techniques from their machine-oriented origins ever closer to human-oriented thought processes.  This Learning Module is being rewritten in preparation for students from the new FSU curriculum (COSC 101, 240, and 241), whose background will be in Java, not C++ (the language of previous prerequisite courses) who (hopefully!) should have a better introduction to OOSD using UML class diagrams (UMLCD).  To optimize this, the learning module will be edited, placing a review of prerequisite material in Concise Introduction to Object Oriented Software Development, which is a "interface" for three presentations:  

1. Modularization of Software, Structured Programming vs.Object Oriented Paradigms, which introduces modularization of software as the foundation of all software development and compares the two ways to do this, structured programming and OOSD.
   
2. Intuitive Intro. to OOSD Using the Unified Modelling Language (UML) is a gentle, common sense introduction to the UML, the only international standard for describing and representing OOS.
   
3. Abridged Overview of the UML Class Diagrams, a review/summary of the fundamentals of class diagrams (the only part of the UML essential to introductory courses); this prerequisite document has an expanded version, Overview of the UML Class Diagrams, required for this course
   

In the future, it will be "required" that ALL students will have "MASTERED" the fundamental concepts of these documents.  They can not proceed until they have demonstrated that mastery by understanding 100% of the Preleminary Evaluation.  

The goals of this learning module are:

1. to provide a review of the language-independent specification of object-oriented concepts.  (This is the fundamental context within which Java is presented, i.e. the implementation of OOSD facilities in Java is the main subject of this course.)
2. to illustrate how OOSD is simply the latest stage in the evolution of "abstraction" in software development techniques.
3. to identify reasons that OOSD is needed.
4. to introduce two language-independent software development "tools", Structured Algorithm Charts (SACs) and the Unified Modelling Language (UML).  (These two tools are covered in separate documents.)
5. to survey other object-oriented programming languages (OOPL), especially C++, so that Java can be compared to them.
6. to empahsize the frustrating inconsistencies in the OO termanology and specify a consistent termanology, based on the UML (Unified Modeling Language) to be used throughout this course.
7. to illustrate the techniques for studying this online, independent learning course.

TPQ 1: Rewrite the preceding objectives in terms of personal accomplishments to be attained after finishing the study of this learning module.(See the explanation, below, of what "TPQ" means.  Note that this will be a standard exercise at the beginning of each learning module that is very important in order to "get you focused".  For a hint, and link to Tony's answer, click on the link "Hints for TPQs" in the "Navigation Panel" along the left boarder of this Web page; this will be a standard facility throughout the course)

NOTES:

1. TPQs (Thought Provoking Questions) and SAQs (Self Assessment Questions) are learning aids that will be used throughout my notes. Both types of questions are designed to help you focus on the essential characteristics of fundamental concepts. SAQs act as "traffic lights"; if you can't answer one, it is a symptom of a misunderstanding and you should review the notes to correct it. TPQs may have more than one correct answer; they may not even have any correct answer; they are simply there to make you think! You are strongly urged to think up your own SAQs and TPQs, using these as guides. Searching your mind for such questions helps you to identify important concepts and think about them; thought is essential to understanding!
2. Numbered blanks in the text, like the SAQs and TPQs are learning aids. As such, the answers for them should NOT be written in the blanks; that simply turns the learning aids back into normal text (you are a spectator). Instead, if you feel you must write the answer down, place it in the margin or at the end of the chapter; then when reviewing the FIBs (Fill in the Blanks), SAQs and TPQs will stillmake you think. (You become a PARTICIPANT instead of simply a spectator.)

If you are an independent learner (not enrolled in the current class COSC390 at FSU, then, before proceeding, consult the study guide for this module.    In any case, if you haven't already done so, read the Introduction to the Study Guide.

The sequence of presentations, in this Learning Module, is:

1. PROGRAMMING LANGUAGE LEVELS
2. SUBCLASSIFICATIONS OF HIGH LEVEL LANGUAGE TYPES
3. STRUCTURED PROGRAMMING CONSTRUCTS
4. OBJECT-ORIENTED PROGRAMMING LANGUAGES
1. Essential "Constituents"of "Pure" OOSD
2. Characteristic "Features" of OOPL
3. Unique "Features" of OOPL
4. Relationships between classes
5. The UML, the standard, language-independent way of representing OO Software
6. Comparison of OOP with Structured Programming Languages
7. Software Development in an OOP Language
5. SURVEY OF POPULAR HIGH-LEVEL IMPERATIVE OOP LANGUAGES
6. SUMMARY

       Java is a high-level, imperative, purely object-oriented programming language that is designed for efficient software development for a distributed computer environment.  (See Learning Module II, Overview of Java, section 1 for a concise preview of the language.)  Generally speaking, computer "languages" are software _______________(1) (Review the explanation, above, of FIB learning tool.  For a hint, and link to Tony's answer, click on the link "

Hints for FIBs" in the "Navigation Panel" along the left boarder of this Web page; this will be a standard facility throughout the course.) that allow a user to communicate with a computer system; in particular, computer languages allow the user to write computer software. There are three basic categories of programming languages: (1) "low level" (computer oriented), (2) "High level" (task oriented), and (3) "very high level" ( human oriented). High level languages (HLL), of which Java is an example, can be sub-categorized as one of two basic paradigms (models): imperative or declarative. (See Section 2.)  Furthermore, the latest fundamental evolution in HLL design, object oriented software development (OOSD) has introduced another distinguishing feature in object-oriented programming languages (OOPL).   ( Reread the first sentence of this paragraph to see if has more meaning after this explanation.)

        OOSD is a continuation of the trend towards making all software development more human oriented (as opposed to machine oriented). In fact, OOPL and OOSD should be viewed as a subsets of a larger concept called Object Technology (OT) which includes DBMS , component technology, and all OO software development environments, including very high level languages (VHLL). (Component technology is, supposedly, the logical extension of OOSD, where existing, reusable software (the components) are used in software models, along with classes; this is discussed int a Component Primer, but is, currently, beyond the scope of this course.)  However, because Java is a HLL, we will only focus, in this course, on the language characteristics and software development techniques associated with the HLL OOSD paradigm. From this perspective, software development can be viewed as three evolutionary improvements on the basic ideas of HLL programming.

HLL programming, as developed in FORTRAN during the 50's and 60's, was originally only a conversion of assembly language constructs into English-like terms where code was based on "goto" instructions that were analagous to the branching instructions of machine and assembly languages.  This machine-like syntax was subsequently replaced, in the "structured programming" paradigm, with more human-like structured control constructs (selection and repetition) and abstraction facilities (data types and modular constructs like procedures and functions); these were provided in sturctured programming languages like Pascal, C, etc.  Next, the modularization trend was extended to "object based programming" with the introduction of the class construct which allowed modelling of "objects"; the class formalized the  encapsulation of state (data declarations) and behavior (procedures and functions) into one module, the class; modular programming languages included Modula 2, Ada, etc.  Finally the transition to OOSD was completed with the addition of inheritance and polymorphism which minimized redundancies and maximized the human point of view.  The preceding evolution is illustrated in the following schematic.

EVOLUTION OF SOFTWARE DEVELOPMENT

HLL Programming (FORTRAN, BASIC, etc.)  
+ Structured control logic¹ + Abstraction² Structured Programming (Pascal, C, Fortran, Structured BASIC etc.)  
+ Encapsulation³  + Visibility (Access Control⁴) Modular Programming (Modula 2, Ada, etc.); also called "Object Based" Programming.  
+ Inheritance⁵ and Polymorphism⁶ Object-Oriented Software Development, OOSD (Smalltalk, C++, Scheme, Modula 3, Ada95, Java, etc.)

¹Algorithms consist of only three control structures (sequence, selection, and repetition) that completely govrn the logic of program execution..
²Named types replace bits and bytes and procedures and/or functions replaced detailed instructions
³Cohesive members, i.e. attributes (specifying the state of an object) and methods (specifying the behaviour that object), are packaged in named classes
⁴Visibility is the UML term for controlling access to the class members. (Warning: this is sometimes called "information hiding"; however, this "polymorphic word" has different meanings in different contexts.  In the traditional sense information hiding refers to the separation of declarations (e.g. header files in C++) from defintions (where actual implementation occurs); this is also called the separation of specification from implementation.   The isolated declarations (specifications) are  the user interface, allowing the the definitions (implementations) to be hidden from the user. )  "Visibility" (the UML term) and "accsss control", what we refer to here, is a very different concept, that is often not even given a name in some texts! See the study guide comment on this problem.)
⁵Inheritance allows subclasses to be derived from superclasses, consequently being able to use the members (attributes and methods) defined in the superclass.
⁶Polymorphism allows a single name to refer to different objects, depending on the context

SAQ 1: What is the difference between encapsulation and visibility (Access Contorl)? (Review the explanation, above, of SAQ learning tool.  For a hint, and link to Tony's answer, click on the link "Hints for SAQs" in the "Navigation Panel" along the left boarder of this Web page; this will be a standard facility throughout the course)

This three-phased evolution continuously shifts the focus of software development from the machine level (how the computer operates) to the human level (how humans accomplish tasks). {INCERT: illustration of monolithic program vs. modular program vs. software architecture.} This shift is called abstraction, but one must be careful with the use of the word "abstraction" because it has many connotations, especially within computer science. As a preliminary, practical definition we can simply say that abstraction means that we replace detailed instructions with names (for data and the operations on that data), e.g. in structured programming, programs are developed in terms of data types (the names "integer", "character", "string", etc. are used rather than memory addresses) and software modules (named procedures or functions replace detailed instructions in the main program). The final shift to the OOSD paradigm extends this abstraction from data types to classes and from algorithms (procedures and functions) to class/object behaviors (methods); however,this latest evolution reflects a fundamental shift in software development strategy from "programming" to "software development" (in terms of the structure and behavior of data rather than the organization of algorithms)  This is illustrated by comparing the programming and OO approaches to modularization of a simple but fundamental application in MODULARIZATION OF SOFTWARE.   This demonstrates the difference in emphasis between programming and OOSD which is illustrated in the following schematic:

PARADIGM SWITCH: PROGRAMMING TO OOSD

Some say that OOSD is now being superseded by "Component Technology" in which reusable software components (classes) are used with engineering techniques to construct software "architectures", but this is essentially the same as OOSD of objects that are explicitly independent, i.e. have a stand-alone capacity.

SAQ 2: What are the (1) similarities and (2) differences between (a) types and attributes and (b) between operations (cause) and behavior (effect).

The preceeding schematic means that the object oriented paradigm has replaced the structured programming paradigm in modern software development.  The following table empahsizes the necessary shift in terminlogy required to make the transistion from structured programming to object oriented software development.

{Expand/rewrite including "components", "patterns" and "frameworks" (a set of classes that embodies an abstract design for solutions to a number of related problems).-refer to OUMLCD.}
This fundamental distinction between OOSD and programming suggests that OOSD features should NOT be simply added to current programming strategies, as is too often the current practice (C++, Modula 3, Ada 95, Scheme, etc. are extensions of non-OOPL.); OOSD constructs should be incorporated from the very beginning of the software development cycle. On the other hand, it is comforting to realize that structured programmers will not to have to "unlearn" any hard-won software development skills; structured algorithm development techniques are an inherent part of OT. Nor does OT change other categories of programming languages; OT is orthogonal to the classifications of HLL vs. VHLL as well as imperative vs. declarative languages. If you have not already worked through my  INTUITIVE INTRODUCTION TO OOSD USING THE UML, you should do so now; this attempts to lay a common sense foundation to all OOSD.

TPQ 2: If OOSD is "oriented" towards objects, what was OOSD's predecessor, structured programming, oriented towards?

        The advent of networking and, in particular, the Internet has introduced the need for several other language features including distributed processing, concurrency, and security. Languages such as Java have facilities that allow software developers to incorporate these at the code level.

The following presentation, a survey of the characteristics of OOPL, has these objectives:

1. To provide a review/preview of basic features and characteristics of software development constructs..
2. To provide a preview of the OT coverage in this course.
3. To introduce symbolic notation to be used in the course, i.e. the Unified Modeling Language (UML) object oriented development and Structured Algorithm Charts (SAC) for structured algorithm development.

1. PROGRAMMING LANGUAGE LEVELS:

        Programming languages have two primary building blockes, (a) a set of built-in language primitives (data types, operations, procedures, functions, etc.) that may be used to write __________(2) code and (b) a translator (assembler, compiler, or interpreter) that transforms __________(2) code into ________(3) code (machine language equivalent). There are (at least) three categories of programming languages:  (Note that the distinction between the following categories has nothing to do with OOSD; high level languages and very high level languages can be OO or not.  The following distinctions simply refelect the differences of machine oriented languages and human oriented languages.)

1.1 Low Level Languages (LLL) are "computer oriented":

1. A LLL is unique to the CPU on which it is implemented and is, therefore, not portable (i.e. not usable on a computer with a different CPU).
2. There are two categories of low level languages:
1. Machine Language (ML)= binary, octal, hex, etc. code; non-binary code is translated into binary code that is directly executable by the computer. Each instruction corresponds to a machine operation, part of the instruction set characteristic of the CPU. Now machine language is virtually never used by humans.
2. Assembly Language (AL) = mnemonic (abbreviated English words) instructions with a one-to-one correspondence with machine language instructions.  AL programs are translated into ML by an assembler. Assembly language, being machine oriented, is faster and more efficient in the use of hardware than HLL or VHLL (both described in subsequent sections).

1. The words and grammar of HLL are English-like. A HLL language is governed by a strict syntax (set of grammatical rules); if this is standardized, the language is portable (can be used on different computer systems).
2. HLL, like Java, C++, etc., reflect the logic and procedures used in a human algorithm, i.e. the steps in the human description of a task. Thus HLL programming is "task-oriented" rather than "machine oriented" so the software developer is able to concentrate on developing task algorithms (structured programming) or engineering a software model (OOSD) rather than the details of how the computer will carry out the instructions. However, the programmer must still specify a complete set of detailed instructions (unlike programming in VHLL; see Section 1.3, below.)
3. HLL programs are translated into ML by either compilers or interpreters. Most HLL instructions translate into multiple ML instructions.

1.3 Very High-level Languages (VHLL) are "human oriented":

       VHLL (e.g. JavaScript, NOT Java) are new and are still evolutionary. Consequently there is disagreement over terminology at present. Many confuse VHLL with "4GLs" which are actually a subset of VHLL.  (Note that this is NOT Java's category; like LLL, VHLL are included here only to give a perspective of Java as a programming language; VHLL and LLL will not be covered further except as references to Java.

1. VHLL are similar to HLL except they are moresophisticated and easier to learn and easier to use because many powerful primitives are built into the languages. In fact, one of the goals of VHLL is to give nonprogrammers the ability to create computer applications. Some say VHLL are designed to facilitate "end-user programming".
1. VHLL are more sophisticated in that they have, built in, very powerful commands that would have to be created (as complex procedures or functions) in a HLL. Thus VHLL programs are typically shorter and more human-like than corresponding programs in a HLL, i.e. a VHLL does more automatically. This is valuable because if there is less done manually, there is less chance of human error.
2. In a VHLL one can focus more on what is to be done, and less on how to do it.
2. The translation software performs most of the details involved with handling information processing tasks. The commands require only that the programmer specify what tasks are to be performed. This automation, however, removes a great deal of control from the hands of the software developer.
3. VHLL are "special purpose languages", (often associated with specific software packages like a Web page, DBMS, etc.), and thus have limited range of application; however, within this range they are very powerful. This power and ease of use must be balanced by the sacrifices in control over the processing details and access to computer hardware. As long as the task fits the narrow capabilities of a VHLL, coding proceeds quickly and smoothly.
4. There is little standardization in current VHLL (they are usually intimately associated to a particular type of hardware or software). This results in a lack of portability which has restricted their current popularity. However, this is changing rapidly.
5. Examples of VHLL:
1. Markup Languages (e.g. HTML, XML, VRML, etc.) allows text to be "marked up" with tags that specify the appearance of the text when it is displayed by an application that contains an interpreter for the language, e.g. a Web browser.
2. Scripting Languages (e.g. JavaScript, VBScript, etc.), considered by some to be a superset of authoring languages, are a "macro-programming" environment in which end-users "control applications' actions without worrying about programming structures" of HLL.  The most widely used scripting language is JavaScript which, where scripts are embedded within HTML documents to add interactivity and dynamic effects, but scripting facilities are built into a wide variety of application like database management systems and even games.
   
3. Forth Generation Languages (4GLs) are VHLL associated with DBMS that facilitate the manipulation of the language in powerful, user-defined ways in order to develop management-oriented applications. 4GL tools include:
4. Authoring Languages allow nonprogrammers to create interactive "tutorial systems", self-paced learning environments, etc.
5. Visual Programming Languages feature a development environment that is GUI-based rather than ___________(4).  Languages like Powerbuilder and SQLWindows are called "visual" because they are designed to facilitate rapid development of GUI-based applications where only a minimum of code needs to be written.  Ideally, in a "pure" visual programming language, one does not write code at all!
• "Visual" in many cases, e.g. Visual Basic and Visual C++, is misleading because they are not primarily visual, i.e. they provide GUI-based development features but are really viaual programming "environments" that augment the writing of code.  Note that visual programming environments are NOT languages themselves, but provide "drag and drop" components which can be used to create user interfaces to applications developed in HLL or VHLL.  These are now available for virtually all popular programming languages. Many of these now include a new development model called "components" (e.g. Java Beans) which allows programmers to create reusable software components that can then be assembled together using RAD (Rapid Application Development) tools, especially IDEs (Integrated Development Environment). Those available for Java include Borland’s JBuilder, Symantecs Visual Cafe, IBM’s Visual Age for Java, SunSoft’s Java Workshop, Microsoft's Visual J++ , and many others.

2. SUBCLASSIFICATION OF HIGH LEVEL LANGUAGES TYPES:

       Another way of categorizing HLL is as to whether they are imperative or declarative (a general term for functional and relational languages). Programs in Imperative languages specify the algorithm (step by step procedure) for accomplishing a programmed task. Imperative languages are, by far, the most popular data processing languages; examples include Pascal, COBOL, FORTRAN, C/C++, Modula-2/3, Ada, and Java. Programs in Declarative Languages, like Lisp, Logo, and Prolog, define the concept (i.e. "declare" its properties).  For a simple example, to find the sum of n integers in an imperative language, one would write the algorithm for adding to a running total whereas in a declarative language, one would declare what the sum of integers is, adding n to the sum of n-1 integers.  Compare the following pseudocode functions.

In general, declarative languages utilize recursion to "declare" the definition of a process nonproceduurually; see the following SAQs.

SAQ 7: (a)Do a trace of the two forms of the function, SumInts, above.  (b) Distinguish the declarative (using a recursive function) and procedural approaches (using iteration) for determining the factorial of N.

2.1 Imperative (or Procedural) Languages (e.g. Fortran, Pascal, C, C++, C#, Java. etc/):

1. are based on assignment statements, i.e. Variable := Expression.
2. have imperative constructs, e.g.
1. algorithmic control structures; specifically iteration (loops) is the typical control structure for repetition;
2. built in data structures are random access and usually static, e.g. the array and struct (C) (record in Pascal);
3. the characteristic abstraction structure is the procedure. (Although functions are available, they are not as characteristic as procedures.)
4. type declarations are typically (but not necessarily) required and are often highly restrictive (to minimize errors).
3. require a complete algorithm (sequence of statements) to be specified,
4. mirror conventional (Van Neumann) architecture, i.e. they are sequential in nature and thus not inherently suited for parallel processing, and.
5. are most useful in data processing and systems programming.

1. Applicative (or Functional) Languages (e.g. Lisp and Logo):
1. are based on the application of functions, i.e. statements typically consist of a series of possibly nested function calls instead of the  __________(5) calls in imperative languages.  The word "applicative" comes from "function application", i.e. the application of functions to data rather than using the data in operator based expressions of assignment statements. For a very simple (impractical) example the sum of X, Y, and Z would be accomplished by SUM(X,Y,Z) = SUM(X, SUM(Y,Z)); the answer to the preceding SAQ is the classic distinction of imperative and functional algorithms.
2. have declarative constructs e.g.
1. declarative control structures, e.g. recursion is the typical control structure for repetition;
2. built in data structures are sequential access and inherently dynamic, e.g. the list;
3. the characteristic abstraction structure is the  __________(6), which can be used as arguments of other __________(6).
4. variables are typically untyped.
3. programs can be dynamic; therefore programs can change themselves, i.e. they can learn. This is the reason that such languages facilitate AI (Artificial Intelligence) programming.
4. require unique outputs from each function.
2. Relational Languages (e.g. Prolog)...
1. are based on formal logic, in that programs consist of (1) facts and (2) rules which make up a knowledge base. Programs are "run" by asking questions to obtain information from that knowledge base.
2. have a programming style similar to applicative languages. They specify output in terms of a predicate with arguments.
3. Like Applicative languages programs are structured using untyped variables, __________(7a), ________(7b), and __________(7c) although there is a distinction between predicates and functions.
4. programs can be dynamic; therefore, they are ideal for AI programming.
5. unlike applicative languages, relational languages do not require a unique output for each predicate/argument pair, e.g. if there are three brothers Tom, Dick, and Harry then the predicate Brother (Tom, X) has two equivalent values X = Dick and X = Harry.
6. unlike both imperative and applicative languages, do not have sequential execution of instructions; instead "chaining" is built in, e.g. the backward chaining of Prolog which is analogous to that in expert systems..

3. STRUCTURED PROGRAMMING CONSTRUCTS:

       Structured programming, the first fundamental change in programming paradigm, was a disciplined strategy for developing and maintaining efficient algorithms.  It was developed in response to the growing crisis in the programming community in the 1960's, runaway software costs.  This crisis had its roots in inefficiencies that were inherent in early programming languages:

1. poor management of programming projects (misjudged schedules and deadlines),
2. undisciplined program design (resulting in low programmer productivity), and
3. software that was difficult to maintain (modify, update, etc.)

Structured programming addressed strategies for algorithm development; all of these still apply in OOSD, i.e. OOSD expands on the concepts of structured programming.  The foundations of structured programming are based on two fundamental principles, structured control structures (See section 3.1.) and modularization (abstraction) (See section 3.2.). NOTE: language-independent representation of all structured control structures are presented in the separate document

3.1 Three Fundamental Control Structures of Structured Algorithms:

       In structured programming, human-oriented logical operations (control structures) are used (in contrast to the computer-oriented control structures of assembly language, like jumps or branches).  In fact, any software task can be programmed using only three control structures, sequence, selection, and repetition.

1. The sequence, the default order of algorithm execution, one instruction after another.  (This seems trivial, but it is essential to understand that compilers and interpreters assume sequential execution; deviations only occur via the following two control structures.)  Defining sequential execution as the default made it possible to omit the line numbers of earlier HLL that really are a feature of machine oriented languages.
2. Selection allows the algorithm to choose one of two or more alternatives depending on the value of a "selector". After executing one of the alternatives, execution is passed to the instruction following the control structure.
1. The most fundamental form of selection is the if-else (also more descriptively called "if-then-else" in Pascal, Modula-3, and Ada) construct which facilitates selection, based on a Boolean condition, of one of two alternative blocks of instructions that are mutually exclusive.  It is the selection construct from which all other can be created by nesting (See SELECTION: CONCEPTS AND TECHNIQUES, part of STRUCTURED ALGORITHM CHARTING.); therefore, it is THE essential selection construct in any structured programming language.  An example in the Java/C++/C syntax is:
 
if (Grade >= 60)
System.out.println ("Pass.");
  else
System.out.println ("Fail.");


The if (also called the if-then in Pascal, Modula-3, and Ada) is a special case of the if-then-else where the else branch is omitted.

2. The switch construct (also called the "case" construct in Pascal, Modula-3, and Ada) allows more than two alternative selections that are, in Java/C++, not necessarily mutually exclusive.  (This depends on the particular implementation in the programming language.) The switch construct is useful but not essential because the equivalent logic can be obtained using if-then-elses.

3. Repetition of a block of instructions can be achieved two ways:
1. iteration (or looping), the most common form of repetition in __________(8) languages, is the cycling through a block of instruction over and over until a condition arises that halts the repetition.  There are two fundamentally distinct types of iteration:
1. definite loops have a predefined number of repetitions, e.g.
 
for (int i = 1; i <= 10; i++) system.out.println(i); //a Java/C++/C "for loop"


2. indefinite loops repeat themselves while a "looping condition" is true, e.g.
 
while (in.read() != -1) count++; // a Java while loop
do count++ while (in.read() != -1);  // a Java do-while loop
loop if EOF exit; read(Grade); print(Grade); end (* a Modula-2  "loop" *)


Note that the loop statement (not available in Java/C++) is the most general of all indefinite iteration constructs; it can be used to write an infinite loop or the equivalent of while and do-while loops. (See SAQ O11.)  However, the while loop is almost as general and was the first "essential" looping construct of structured programming; it is Java's most general looping construct.  The do-while loop, whose body is always executed once, is not essential, but is sometimes more intuitive than the while loop.

2. recursion, the preferred method of repetition in _________(9) languages (like Logo, Lisp, and Prolog) involves a subprogram invoking itself, over and over, until condition arises that halts the recursion.  Note that recursion has all the utility of an indefinite loop so structured languages need not even have an indefinite loop construct if it provides recursion.  The classic example of recursion is the recursive function factorial, given below in Java:
 
public int factorial (int N){
//a NOT bullet proof example of recursion
if (N == 0)
factorial := 1
  else
factorial := N*factorial(N-1)
}//end factorial

3.2 Modularized "Programs": the Subdivision of a "Task" into Loosely Coupled, Highly Cohesive Subtasks:

1. As we discussed in the programming part of MODULARIZATION OF SOFTWARE, modular "programs" consist of semi-independent subprograms (procedures or functions which, collectively, we call "modules") that perform well-defined, distinct tasks within the program.  Each module is identified and accessed by a unique name.  These modules can be developed, debugged, or modified without affecting each other or the main program.
1. "semi-independent" means that the module is "highly cohesive"  and "loosely coupled".
1. Highly cohesive means that the module is completely self-contained and incorporates nothing other than what is needed to perform its task.
2. Loosely coupled means that although modules can be associated with other modules or programs (via invocations or nesting) they are essentially independent.  In other words one can "cut-n-paste" a structured module from any location to any location.  Of course to be useful, invocations from a new environment must conform to the API (application programming interface) of the module, i.e. its name as well as the name, number of, and types of its parameters (arguments).
2. In structured programming there are two distinct kinds of modules, "procedures" and "functions". (Note that Pascal/Modula/Ada languages distinguish these, but C and its family do not!)  (These two constructs are generalized as "methods" of the class construct in OOPL; see section 4.1.E, below.)
1.  ____________(11) return a single value (number, string, etc.) via its name, i.e. the result of the processing replaces the name in a calling statement; consequently they can be used within a statement just like a variable.  If input values are needed, they are supplied via arguments, located within parenthese following the name.  In languages that use ANSI standard C syntax, function declaration contains the type of the value returned and utilizes the return keyword, e.g.

ave = average(intArray; max);

FinalGrade = Grade + Curve(Grade, average(intArray; max))

2. "____________(12)" (unfortunately, called "null functions" in languages like C) do not return a value via its name; instead they "pass" values via parameters.  Such modules constitute, on their own, a single statement, i.e. unlike ___________(11), they can not be a part of another statement.  Obviously, procedures must be used to implement any algorithm that passes more than one value to the calling statement, but they are also used for passing single values and even when values are not passed at all.  Typically procedural methods perform an action like writing text, reading a file, etc. or perform processing that outputs more than one value, e.g. the classic method swap.
   

3. Note that ______(13a) make good names for procedures, and ______(13b) make good names for functions.
2. Structured programs are normally a hierarchical (i.e. nested) collection of modules  where modules may be nested within other modules (not true in C!).  Each module has only one entry point and one exit point.   (Unstructured modules may have multiple entries and exits, via the infamous goto statement; this can easily result in "spaghetti code")
3. When written in terms of these modules, the main program (or top level module) looks like an outline of the program. This "outline" is also the sequence of development in the "top-down" approach to program development that is characteristic of structured programming. If the names of the modules are chosen carefully, reading through these names will give a summary of the program itself.
4. Because they are self-contained (________ _____________ and _________ ______________(14))  modules can be incorporated into libraries where they act as permanent extensions to the programming language itself.

3.3 SOFTWARE DEVELOPMENT USING STRUCTURED PROGRAMMING

1. The following is a generic outline of the phases in the development of structured programs.  Note that modern strategies for software development are NOT linear, i.e. the following steps are not performed in a strict sequence.  Instead they are part of an iterative (nested looping) development process conducted on each independent part of a software application.  However, the following activities are all essential to software development and are performed, at the the program level as well as at the subprogram level (procedures and functions).  (Note that, although this is THE fundamental strategy for structured programming paradigm, it is also applicable in OOSD because all operations/methods are algorithmic.  Therefore, the following, which refers to "tasks" applies in OOSD; only it has a supplementary role (to modelling class architectures) in OOSD.)
   
1. Analyze the Task and Specify its Input/Output.
1. Identify data to be used.
2. Identify the operations that process the data.
3. Specify the interface to the processing (the I/0 mechanism)
2. Design the program, top-down that implements the specifications.
1. Define the first level algorithm (the program), i.e. the instructions, procedure calls, and function calls, etc.
2. Define lower level modules (the procedure and fuction algorithms).
3. Check (by hand, for errors and the effectiveness of the algorithms) and debug
3. Code (Implement) top-down (iterative approach) in a computer language.
1. Code algorithms using "stubs" (declarations with "signatures" (module names, return types, and arguments/paramethers, but no definition of of subalgorithm) for incomplete modules.
2. Test and debug with each newly coded module
3. Repeat i and ii for each stub until the complete algorithm and all subalgorithms are implemented.
   
4. Test and debug the code
5. Document
1. External documentation assists the software use it effectively
2. Internal documentation describes the purpose and organization of unclear code and the software modules (procedures and functions).
6. Evaluate and Maintain the software.
Notes:
1. The analyze and design phases are language independent, i.e. they are done with flowcharting techniques, pseudocode, or other ways of representing algorithms.  A programming language does not have to be used until the coding phase, when the algorithm is "implemented" in a computer languages.
2. The preceding steps still outline the development of OOS methods (OO equivalent of procedures and functions within classes).  In fact, the steps can be modified to  represent, in an simplified way, the strategy of OOSD; basically this would require replacing "task" with "system, "program" with "software architecture", and "algorithm" with "object model" and rephrasing it; however, since OOSD is a superset of SP, this would be a simplestic view of OOSD strategy.
2. The foundations of modern algorithm design and implementation were formalized in "structured programming".  These have not significantly changed although the strategies and implementations have been generalized in OOSD.  These are previewed here and presented in sections 4.
1. The control structures and their use in algorithm development are substantially the same in OOSD methods as they are in procedures and functions, so it is not necessary for structured programmers to "unlearn" or relearn anything to become object oriented software developers.  They only need to learn a new strategy, modelling with classifiers, and "fit" algorithm development of operations/methods into that.
   
2. The The basic goals of modularization have not changed; however, in addition to method algorithms (replacing procedure and function algorithms) one must specify
1. encapsulation constructs (_________, _____________, and ___________(15) as well as advanced constructs such as patterns, frameworks, and components) and visibility (access control) of their members; these formailze the highly cohesive goal of modularization.
2. relationships between modules (classes and interfaces); these formailze the loosely coupled goal of modularization.
3. It is more effective to discuss the development strategies of structured  programming in comparison with OOSD, so this is deferred until section 4.6, below.

IMPORTANT NOTE:  all the requirements and concepts of structured programming apply to OOP; they completely specify the algorithm development features of OOP that are used to define methods.  OOP has additions to (not extensions of) the algorithm development requirements of structured programming.  On the other hand, although all the modular specifications also apply to OOP, they are extended and generalized to specify class structures in OOPL, i.e. the class construct of OOPL is a generalization of procedures and functions, in which they are encapsulated with the data on which they operate.

3.4. Problems Associated with Non-OOPL:

          Pre-OOP software (developed via structured programming) does not model the real world very well because it is based on algorithms (actions), whereas the real world consists of things (objects) not actions (behavior of objects). This is the fundamental, conceptual weakness, but there are other more specific shortcomings of pre-OOP software which are discussed below. All of these are addressed by the OOP facilities for (1) encapsulation, (2) Access Contorl, (3) inheritance, and (4) polymorphism.NOTE: It will probably be difficult to fill in the blanks of this section until you have read Section 5; it will be a good thought-provoking exercise, so try, but do not worry about getting them correct here. (See the SAQ at the end of Section 5.4.) The main problems with pre-OOP are that . .

1. there is no definable relationship between data and its associated operations (functions and procedures) that can be performed on that data. In other words there is no built-in mechanism (language primatives) to encapsulate (bind together) data and its associated operations.  This is crucial, from the viewpoint of data, because "operations" are actually what specify the data's "behavior", thus in non-OOPL there is no formal relationship between data and its behavior! Therefore, in traditional languages, data is a "second class citizen" because the focus is on "program logic" rather than the effect of the program on its data. The following resulting problems are addressed in OOP by "packaging" data and operations via _______________(16).
1. Since there is no formal structural relationship between data and its associated operations in non-OOPL; data is either global or local to one specific function or procedure. An object, of course can have several behaviors, so data should be associated with as many operations as it has behaviors. What is even worse is the fact that data is associated with procedures/functions, instead of the reverse! This problem is especially severe in C, for example, because C functions can not be syntactically embedded (nested) within other functions. (Nesting is provided by Pascal allowing it some control over data access.)
2. Modification of a data format requires modifications of ALL functions/procedures that access that data. However, in a large non-OOP program, it is difficult to identify all these functions and procedures that are associated with the data and that, therefore, need to be modified, especially if there is no obvious relationship.
3. It is not easy to create new data types comparable to built-in types because one can not "package" the relevant operations with the new data format.
2. it is difficult to control access to (visibility of) specific variables, procedures, or functions. One of the long-standing goals of programming languages has been to prevent the destructive results of "side effects" in which unplanned access to data causes unforeseen consequences. Complete control of data access is facilitated by the OOP feature _______________(17).
3. there is a tremendous inefficiency in non-OOP software development because there is no built-in facility to reuse existing code. One often has to "reinvent the wheel" in order to use it in different environments, or, at best, locate and copy useful code that was not designed to be used in other applications and was written by developers who could not anticipate the use of their code in your program. This weakness is directly addressed by the fundamental OOP facility of highly cohesive ____________(18a)  and of ____________(18b), probably the most distinguishing feature of OOP languages. (Note: non-OOPL do have two forms of reuse in common with OOPL (1) aggregation and (2) dependency; see sections 5.4.Dand 5.4.E.)
4. it is not easy to model things that have similar behaviors. For example, many different types of balls (footballs, ping pong balls, basketballs, etc.) can bounce, but how they bounce differs. In non-OOP programs, one would have to distinguish these procedures with some clumsy naming convention such as Bounce_football, FootballBounce, etc. It would be much easier (and more natural) to simply use Bounce and let the object itself determine how it bounces. This is the essence of _______________(19) in OOP.

4. OBJECT-ORIENTED PROGRAMMING LANGUAGES:

      Object-oriented programming (OOP), now being generalized into a comprehensive term "object technology" (OT), is the modern approach to software development, one that has many diverse applications.  The essential feature of OT is that it "models" physical systems with "software architectures", the OO replacement of "programs".  Smalltalk, Java, and C# are pure object oriented languages. However, object-oriented extensions have been added to most existing languages resulting in imperative OOPL such as C++, Object Pascal, Classic-Ada, Ada 95, Modula-3, etc. and declarative OOPL such as CLOS (object-oriented Lisp), Object Logo, Prolog++, etc.  OT is an evolution of software development strategy whose benefits will range form simplifying the ways both users and developers utilize computers to making code more modular, self-contained, and reusable.  OT architectures can range from a simple collection of classes and interfaces to patterns (a template architecture that can be used various ways) and frameworks (implementations of patterns).  Implementations characterize "Component technology, e.g."JavaBeans" which are reusable collections of executable OO software that are  modular, deployable, and replaceable. Perhaps the most visible impact of OOP has been the graphical user interface (GUIs) of all modern software; however, OT is being currently applied to every aspect of software development, particularly operating systems and DBMS.

WARNING: There is a distressing inconsistency in the use of terminology in different OOPL.  (If you have not already done so, read the online INCONSISTENCIES IN OO TERMINOLOGY.) The following concepts are expressed in the most general sense using the language independent "Unified Modeling Language" ( UML) for software technology by Grady Booch, Ivar Jacobson, and James Rumbaugh. These concepts must be carefully analyzed when applied to specific languages because there are subtle (and therefore, confusing) differences!  Also, because OT requires a "paradigm shift" in thinking, Tony (1) has dropped the term "programming" in favor of the more general term "software development" (so "OOSD" supersedes "OOP"), and (2) uses the term "architecture" instead of "program".

4.1  Essential "Constituents" ( watch out for this Tony's term on assessments!) of "Pure" OOSD:

NOTE: The following was introduced in Overview of the UML CD.

The failure of older languages to associate data and its characteristic behavior is corrected in OOPL. Conceptually, a real world object has an identity and is specified by its state and its behavior. When this real world object is modelled in software, we say we implement the "model" in a computer language.  In an OOPL implementation the identity is specified by a named "object" which is "instance" of a "class" (type), its state is specified by the values of its "attributes" (data), and its behavior is specified by its "operations" (UML term), also called "methods" (programming language term); attributes and operations/methods are collectively called "members" of a class.  Objects interact by sending "messages" to one another and the state of an object can be modified by its response to a message.  A collection of related (interacting) classes forms a "software architecture", the OO term for "program".  Each of these critical terms were defined in the OVERVIEW OF UML CLASS DIAGRAMS and are concicely reviewed below.

1. "Model",  the essence of OOSD is a representation of real world systems in software using related collections of "objects" which interact/communicate via "messages".  This is emphasized by the fact that "modelling" is the center of "Unified Modelling Language", the UML. The various UML diagrams are represent different "views" of the conceptual model.
   
2. OBJECT: An object, in computer science, is a unique quantity with actual values that specify its state and a complete set of operations/methods that specify its behavior.  The "object orineted programming" paradigm is founded on the idea that real world objects are "modelled" in software. In other words,an  object, in computer science, is the result of the execution of software containing a class that is the abstract representation of the real world object and all other objects of the same type.
1. In OT, the "object" is the fundamental element of the software model of a physical system. ; these elements interact by sending messages to each other.
   
2. In general (outside the scope of computer science) objects are the quanties make up a real world system.  The object oriented paradigm in computer science is designed to allow real world objects to be "modelled" in software.
3. WARNING: The word "object" is used in many different contexts in OOSD.  In many texts "objects" are synonymous with "instances".  (See FOLDOC's definition.)  However, this can be confusing when it is necessary to refer to "real world objects", i.e. the things we model in OOSD.  In this course, I try to be very careful with the word object.  The word "object" is a very general term, i.e. ANYTHING can be considered to be an object, even outside the scope of computer science.  On the other hand, "real objects" refers to real world objects, and "computer objects" refer to "instances" of classes;see the comment after section C.
3. CLASSES: The class, the most fundamental concept in OOSD, is a template for objects. The class construct (from which OO software is "constructed") is a formal implementation of the OOSD concepts of "encapsulation" (See section 4.2.A below.) and "visibility (Access Control)" (See section 4.2.B, below.).  In a software architecture, classes are related to each other via semantic relationships (associations, dependencies, inheritance, and realizations). (See section 4.4, below.)
1. The class construct is as a user-defined generalization of the ___________(20a) construct in structured programming languages like C or Pascal and a formalization of the concept of a ___________(20b) structure; it should be viewed as a self-contained, stand-alone entity. It is a construct (a keyword used in writing software code) that encapsulates (1) the attributes that specify the object's ______(21a) with (2) the operations/methods that specify the object's ___________(21b) and that act on the attributes to modify the object's state.
2. A class is an abstraction construct that allows one to represent objects of a similar type, e.g. the class circle represents (is an abstraction of) all the circles that can appear when the software, that contains the class, is executed.   This allows the developer to modularize software into identifiable, manageable components (the classes) in order to reduce the complexity of large systems.  The system can be represented by a software architecture of classes and other constructs thus making such systems easier to understand and model.
3. In structured programming terms, an class is "loosely _________(22a)" (i.e. not dependent on the internal details of other classes to which it is related) and "highly _________(22b)" ( self contained, i.e. containing everything necessary to define the object it models, but nothing more).
4. INSTANCES: A computer object does not really exist until a class is "instantiated", thus creating an instance of that class. This is analogous to the ___________(23) of variables in traditional languages. Creating a computer object (instance of a class) allocates memory to hold the values of the class attributes at the time of execution, not before. A single class may have any number of instances; each instance has storage allocated for maintaining its individual state. WARNING: the word"instance" (unlike "object"; see section A, above.) is very specific and refers the OOSD concept of an "instance of a class".
5. Members: A class consists of two kinds of members, attributes and operations, i.e. they are "members" of a class.  However, it should be noted that the developer only specifies those members that are needed to define the particular view an object necessary to completely model the task being implemented, i.e. members that are not relevant to the software model need not be included.  (This is often referred to as the "limited world" of the mode, e.g. if color is irrelevant to the application, it would be ignored even if it is characteristic of the equivalent real world system.)
1. ATTRIBUTES: Attributes are a generalization of the concept of variables in structured programming languages, i.e. an abstract template for the variables that will be used to store a computer object's current __________(24), Once declared, attributes have the "potential" to be instantiated as actual variables. Unfortunately attributes (a UML term) have other names in most OOPL, e.g. in Java attributes are called "fields", and in C++ they are called "member data".  However, I will not use these terms in this course; instead I will use "attributes", because it is a language independent, international standard term.  In OOPL, instance attributes are always associated with a particular object and i.e.
1. The declaration of an attribute as a class (i.e. a class is the "type" of the attribute) implements the OOP relationship of "association()"  (See section 5.4.D.) between the class and the class in which the attribute is declared. This has the more descriptive name of "has-a" relationship, e.g. the class Circle contains an attribute c