or 

Last Major Updated: 10/11/03;  3/27/06
Under Development; still only a draft/prototype

LEARNING MODULE VIII
OVERVIEW OF
OBJECT ORIENTED SOFTWARE DEVELOPMENT (OOSD)

Throughout the preceding learning modules we have been learning how to implement the OOSD constructs using Java, and to a lesser extent, C++.  This really implies that we already know how to develop OO software, and, indeed, the prerequisites to this course is a knowledge of OOSD using C++ Java.  However, too often, students learn to develop OO software in a 'bottom-up" strategy, i.e. they learn how to implement the details of algorithms and OO models before really considering the development of software architectures consisting of related classes.  Therefore, in this LM, having covered all the OOSD constructs and their implementation in Java, we attempt to synthesize and generalize all of the OOSD techniques we have been using up to now.  To start, we should review the basic ideas of OOSD.

Software development in an object oriented environment is more complicated that the traditional structured program development strategies because OOSD is a super set of structured program development, i.e. the "programming" is relegated to defining the operations that specify the behavior of each class.  Before defining behaviors, one must create "templates" for each abstract objects that have these behaviors.  Therefore, one has to first create a software architecture of encapsulation constructs (                      (1a),                       (1b),  and                       (1c)) and define the relationships (                      (2a),                       (2b),                        (2c),                       (2d),                       (2e),  and                       (2f)) between these constructs before defining the operations that specify the object's behaviors.  Thus, from the simplest viewpoint, one can say that OOSD involves designing a         ____        (3a) of         ____        (3b), then                       (3c) these constructs, and                       (3d) associated with these constructs.  To do this in a, standard language-independent way, one should:

1. use the UML to develop the architecture of your software (Note that the UML does NOT include strategy for software development - on purpose; it was designed to be applicable to any strategy.  However, there is a  Rational Unified Process (RUP), designed by Ivar Jacobson that specifies a strategy for OOSD that complements the UML.) and
2. use structured algorithm development techniques, e.g. SACs, flowcharts, pseudocode, etc.)  to develop the operations that define object behaviors

OOSD includes all of the ideas of structured programming plus new OO facilities for                       (4a),                       (4b),                       (4c), and                       (4d); review the Introduction of LM I.  LM VIII is a summary of OOSD as part of system development with an emphasis on the new features of OOSD that have been added to those of traditional (structured) program development.

If you are an independent learner (not enrolled in the current class COSC 390 at FSU), then, before proceeding, consult the study guide for this module.

The objectives of this learning module are:

1. Summarize the overall strategy of system development, of which software development is a part
2. Survey the fundamental concepts of OOSD
3. Introduce the Rational Unified Process (RUP), the OOSD complement to the UML

The sequence of presentations in this learning module is as follows.  You can click on any link to jump directly to that section.

1. THE SYSTEM DEVELOPMENT LIFE CYCLE INCLUDES SOFTWARE DEVELOPMENT
2. FUNDAMENTAL CONCEPTS OF OOSD
3. SOFTWARE DEVELOPMENT CYCLE
4. OBJECT ORIENTED ANALYSIS AND DESIGN
5. GENERIC PHASES OF SOFTWARE DEVELOPMENT
6. GUIDELINES FOR DEVELOPING AND RELATING CLASSES

1. Software development is a part of the System Development Life Cycle.
2. When produced in-house, initial software development occurs in the Systems Development Phase of the system development life cycle.
3. Software development, in practice, does not end with the completion of the Systems Development Phase but is an unending cycle occurring within the Systems Maintenance Phase; see section 2, below.

1. The practical goals of OOP are:
1. to maximize developer efficiency via the reuse of code.
2. to maximize robustness via access control and information hiding.
3. to facilitate portability via encapsulation.
4. to encourage generality in programs via polymorphism, etc.
2. The most fundamental tasks of OOSD are the decisions:
1. what classes to use, i.e. identifying the objects that must be modelled with class constructs,
2. what to include within each class (                      (5) of                       (6) and                       (7)) in order to implement a software architecture of highly                   (8) classes.  (In Java this is extended to considering what classes should be                (9) within what packages.)
3. what protection (visibility) to associate with each property (                                 (10)),
4. and how to relate classes ( according to __________, __________ ,or                       (11)) while implementing a                (12) collection of classes and packages
3. In developing relationships between classes, there is a fundamental OOA/OOD choice between (1) inheritance and (2) "incorporation" (Tony's word used to include association/aggregation/composition, and dependency).This is complicated by the fact that:
1. there are, at least, two ways that inheritance is manifasted
1.                (13) ., i.e. defining a class-superclass relationship (using one heading with inheritance specifiers)
2.                (14), i.e. inheriting the responsibility to define members declared in abstract classes or interfaces.
2. there are at least five ways a class can incorporate another class (complicated by the difference between aggregation/composition and dependency!), as:
1. an attribute, i.e. a class is used to declare the                (15) of an attribute,
2. an argument, i.e. a class is used to declare the                (15) of a method argument,
3. a return type, i.e. a class is used to declare the                (15) of the quantity returned by a functional method,
4. a local variable, i.e. a class is used to declare the                (15) of a local instance (within a class method), and
5. the address of a pointer (not in Java because java uses declaration by reference as a default).

3. SOFTWARE DEVELOPMENT CYCLE:

3.1 PHASES OF SOFTWARE DEVELOPMENT:
 

1. Regardless of whether software is developed commercially or as part of the systems development life cycle the strategy involves the following generic phases

1. Analysis of the task Note: some versions call this stage "specification" and combine analysis with design, but the terms used here are more common conform to the Ration Rose diagrams shown in Figures OOSD-2 and OOSD-3. )
2. Design of the Model that represents the task execution.
3. Implemention of the design in code (construct the software)
4. Testing (debugging the software, its architecture, and its implementation)
5. Documention
6. Deployment (Evaluation and Maintainence)
2. The Objectory, designed by one of UML's three amigos, Ivar Jacobson and sponsored by Rational Rose, has basically the same ideas (called "workflows") that sequenced in four phases, inception, elaboration, and construction.
1. The objectory is based on three key ideas.  It is:
1. use-case driven,
2. architecture-centric, and
3. systematically tested.

THE RATIONAL UNIFIED PROCESS SOFTWARE DEVELOPMENT LIFECYCLE Distribution of Workflows (Vertical) In Relation to Phases (Horizontal)

from The Unified Modeling Language, by Booch, Rumbaugh, and Jacobson, Addison Wesley, p34.




1. The Objectory takes new requirements as input, and produces artifacts in the UML as output.  The work to produce a new release is divided into four phases:
1. Inception establishes core architecture, identifies and reduces critical risks, and assures feasibility.
2. Elaboration establishes mainline architecture, identifies and reduces signiicant risks, and plans and estimates the construction phase.
3. Construction builds product in a series of iterations, resulting in increments or builds.
4. Transition moves the product into the hands of users.
2. Within each phase, architects and developers carry iterations through a set of workflows.
1. Modeling
2. Requirements capture based on use cases (producing, primarily, UML use case diagrams)
3. Analysis and design, including an architecture (producing, primarily, UML class diagrams)
4. Implementation
5. Testing and debugging
6. Deployment
3. For an introductory summary to RUP (from which the preceeding discussion comes), see the handout, Objectory Is the Unified Process, by Ivar Jacobson, Object Magazine, april, 1998, p. 72.
3. Note that modern strategies for software development are NOT linear, i.e. the preceding phasess (both generic and Objectory) are not performed in a strict sequence, like the "waterfall method" (See the top illustration in Fig. OOSD-1.).  Instead they are part of an iterative process (involving nested, repetitive subphases containing some or all of the preceding phases) conducted on each independent part of a software application. (See the bottom illustration in Fig. OOSD-1.) However, these phases are all essential to software development and are performed, usually in an iterative manner, in all states of software development.

3.2 STRUCTURED PROGRAMMING PHASES (These still apply to Operation/Method development in OOSD!):

1. In the structured programming approach to the phases of software development the developer must:
1. Analyze the Task and specify its Input/Output requirements.
1. Specify the required input data and its mechanism, e.g. CLI, GUI, files, etc. (In operations/methods these would be arguments.)
2. Specify the output information and how it is to be presented
3. Specify the operations that process the input into output (Note that this functional/procedural approach is fundamentally different than an object oriented approach)
2. Design the Logic, using a top-down strategy (using SACs, flowcharts, pseudocode, etc.; see section 3.2.B, below.).
1. Define first level module (the program)
2. Refine the design, stepwise, by modulariation (organizing self-contained logic in highly cohesive procedures and functions).
3. Deskcheck (trace) and debug the various possible program threads
3. Implement the logic, top-down, in code using a computer language.
1. Code the program and its modules (procedures and functions) using "stubs" for untested modules
2. Test and debug with each newly coded module
4. Test and debug
5. Document (This important phase is often omitted, as in the illustrations below, but should not be ignored by the software developer!)
6. Evaluate and Maintain
2. This "programming" is based on algorithm development in the analysis and design phases.  This is illustrated in the most basic of computer algogrithms, the Input-Proces-Output sequence, presented by the following flowchart.

 

INPUT-PROCESS-OUTPUT ALGORITHM in Flowchart form

The programming cycle is, conceptually, separated into a language independent phase (analysis/design) and a language dependent phase (implementation and testing/debuging). (This separation is irrelevant to the Documentation phase.)

(Compare the specifices of the following phases with those of section 3.2, above and Figure OOSD-2.)

1. Analyze the Task and specify its abstract objects and their interrelationships (Compare with the Analysis subcycle of Figure OOSD-2A.)
1. Identify the conceptual objects (distinct, highly-cohesive components) that represent the task domain and the roles of each object. (Utilize the uses case diagrams of the UML)
2. Identify the conceptual object elements that specify its state (UML attributes) and behavior (UML operations)
3. Identify the relationships between conceptual objects that facilitate a loosely coupled architecture of classes.
2. Design the Software Architecture, using the UML using a top-down strategy.  (Compare with the Design subcycle of Figure OOSD-2B.)
1. Develop a model that implements the specifications from the Analyze/Specify phase.
1. Define first level
1. classifiers  (modules, i.e. classes, interfaces, and packages.)
2. relationships between classifiers
3. Specify classifier details
1. declare attributes
2. define methods (UML operations) that represent behavior
3. declare relationships that minimize redundancy (efficiently reuse classes and their elements), e.g. inheritance.
243. Refine, stepwise, the architecture by repeating the first level activities for other classes and packages.
     
2. Deskcheck (trace) and Debug
3. Implement the architecture, top-down, in a computer language.
1. Code classifiers using "stubs" for untested classifiers and/or methods
2. Test and debug with each newly coded classifiers
4. Test and debug
5. Document
6. Deployment (Evaluation and Maintainence)

3.4 DIFFERENCES BETWEEN STRUCTURED AND OO SOFTWARE DEVELOPMENT:

1. The phases in development of OO software are a superset of the phases of structured programming, in which analysis and designed are focused on objects rather than operations. The traditional sequential ("waterfall") approach to writing programs has been largely replaced by an iterative modules for analysis/design followed by implementation. See Fig. OOSD-1.
2. The life cycle still (conceptually) separates into a language independent phase (analysis/design of a model) and a language dependent phase (implementation/testing/debugging). See Figure OOSD-2A.
1. The analysis/design strategy is illustrated in Figure OOSD-3.
2. The language-independent tools used in this course include:
1. The Unified Modeling Language (UML) is used to develop software architectures of                                  (16) classes that are                                  (17) via inter-relationships.
2. Structured Algorithm Charts (SAC) are used, by Tony's protégés to develop the structured algorithms of methods.

4. OBJECT ORIENTED ANALYSIS AND DESIGN:

4.1 The Analysis/Specification Phase:

1. Identify the task and decide whether or not a computer approach is required.
1. If a task is to be carried out only a few times the time and effort of developing a program probably is not warranted.
2. Tasks that are to be repeated many times with different data or conditions are ideal candidates for computerization.
2. If a computer approach is to be chosen, software specifications must be made, i.e.
3. use cases
4. {continue}

1. Before writing a code one must develop the step by step logical process that will accomplish the specified tasks.
1. A common mistake of novice programmers is beginning to code (write the program instructions in a programming language) before they completely understand the task and the method of accomplishing it.
2. The design should NOT be done using the programming language. In fact, unless one is using computerized software design tools, e.g Rational Rose or an IDE like JBuilder, one should design the software architecture away from the computer in order to resist the temptation to code parts of a program before the design is complete and debugged.
2. Modern programmers used structured techniques (See section 3, below.) and object oriented programming (OOP) techniques (See the Learning Module, Programming Languages.) to construct modular software components by using only:
1. structured logic constructs of sequence, selection, and repetition and
2. modular constructs: In structured programming, procedures (in which data is passed to the main program via "parameters") and functions (in which data is returned via the function name) are used to modularize the program design. In the more modern OT, classes (in which data and operations are "encapsulated" together) are designed; these become "templates" for the actual objects used in a program.
3. Program design tools are usually utilized to help the designer to think through the algorithm. The following are presented in more detail in following sections.
1. Structured programming tools include structure charts, flowcharts, and pseudocode.
2. OOP tools are still evolving; one such tools is the Unified Modeling Language or UML.  (See section 5.D, below.)
4. Rather than developing applications "from the ground up" using the basic constructs of traditional programming languages, many standard applications can be created quickly using special purpose facilities such as VHLL, CASE, application generators, etc. When planning to use one of these facilities, one can assume a wider range of more sophisticated constructs from which to create an application thus avoiding many logic details.
5. Debugging can be facilitated several ways:
1. Utilizing use
2. Tracing of method algorithms means working through all the paths of the logic using pencil and paper and the simplest set of complete test values for attributes and method arguments. Debugging means correcting each logic fault that is discovered.
It is a common failing of novice programmers to rush to the coding phase before thoroughly checking the structure (highly cohesive and loosely coupled) of their architecture model and the logic of the operation algorithms.

    Analysis and design are fundamentally different in sturcutred programming and OOSD.  However the subsequent phases, __________(), __________(), and __________(), are not different enough to warrent describing in separate sections.  In fact their similarities outweigh their differences so they are presented in generic forms below.

5.1 The Coding Phase:

1. Coding is implementing the architecture model in an object oriented programming language.  When using the UML, this involves two distinct tasks:
1. implementing the class diagrams in code.  This can be done automatically by software such as Rational Rose.
2. implementing the operation algorithms in code. When using schematic algorithm representations (like SACs or flowcharts) this can be a routine task that could even done by a computer.  Typically the actual coding of the algorithm instructions in a programming language is accomplished by using the development tools, associated with the language, e.g. the IDE of Borland's JBuilder.
The choice of language in which to code a UML model is very important because different languages have different capabilities; one should try to choose a language which will make implementation as efficient as possible while satisfying other constraints such as availability, your programmer's familiarity with it, etc.
2. Coding should be done top-down, i.e. starting with the main method of the user interface class (or the init method of an applet or C++'s main function), followed sequentially by each class that is instantiated in the main method.  As mentioned in the previous section, if the architecture model is efficiently and correctly designed coding the classes and their attributes is very straightforward that it can be generated by software like Rational Rose.  In fact, if the user interface with the software is a GUI, it can be generated by virtually all modern IDEs (Integrated Development Environments)  However implementing the behavior of the various classes, i.e. defining their methods requires more "hands on" coding by the developer.  In the time-honored strategy of structured programs this should be using a "divide and conquer" approach where each method is develped and debugged in isolation using "stubs" for each untested class or method. Testing/debugging should be done at each stage.
1. "Stubs" are trivial components that consist only of the class constructor name or method name with simple output statements indicating (1) that the class or method has been called and (2) when a response is generated. It is usually helpful to output the values of the important attributes, method arguments, and local variables with each output statement, so that logic errors can be pinpointed when the software is executed.
2. It is critical that the whole program should be tested and debugged when each component is implemented, i.e. when each stub is converted into a fully operational procedure or function. Because this is being done on the computer, more sophisticated test data can be used than during the tracing/debugging of the deskchecking (tracing) phase of the Design phase.
3. The following conventions are used to standardize many of the features of a program:
1. structured constructs in the logic of a program (universally required),
2. naming conventions,
3. documentation (comment) standards, etc.
4. As mentioned above, the following application generators automate many of the tedious tasks of coding and thus greatly increase programmer productivity in applications that have standardized characteristics.
1. a. VHLL (Very High Level languages), including 4GLS (Fourth Generation Languages), are special purpose programming languages that facilitate efficient implementation in a particular (limited) domain of applications (e.g. 4GLs are very efficient to implementing database applications but would be cumbersome, if not incapable, in writing graphics applications, for example).
2. CASE (Computer Assisted Software Engineering) which generate program code directly from specifications thus allowing the developer to avoid worrying about the details of the program logic.
5. Other facilities that increase the efficiency of application development include:
1. Reusable code: Very often a procedure or function can be used in more than one program. In such cases they are placed in code libraries from which they can be "cut and pasted" into various applications. Many standard libraries are supplied with programming languages and public domain libraries can be freely copied. In OOP code reuse is greatly facilitated with "inheritance" by which classes can share the data and operations defined in "parent classes".  (See section 4.1, below.)
2. Data dictionaries (particularly associated with DBMS): These carry a complete specification of the data processed by a program; this can be accessed by programmers to help them in application development. Active (on-line) data dictionaries will give error messages if data is improperly used in a program.
6. Quality assurance is maintained by structured walkthroughs, i.e. a detailed peer critique of program. This team approach encourages egoless software development.

1. Debugging should actually take place continuously during the development cycle. In particular it should be done in both the:
1. design phase: This involves detecting and removing logical errors. It is accomplished by "tracing" the algorithm (penciling through each step); this is also called performing a "walkthrough"
2. Coding phase: This involves removing syntax errors which are mistakes in the spelling and grammar of the particular programming language.
2. After coding, testing and debugging is needed to catch faults that might have slipped through.
1. Testing involves using simple but complete test data specifically chosen to expose possible errors ("bugs");
2. Debugging is the process of removing these errors.

1. Program documentation are explanations that will help a user, operator, or programmer to understand the program or that will help someone to later .
1. User documentation consists of general manuals on how to use the application.
2. Operator documentation consists of technical manuals to help operators to modify or customize the application.
3. It often becomes necessary to modify or update the program itself. Programmer documentation facilitates such "program maintenance". This includes design specifications, logic description (flowcharts, pseudocode, etc.; See below.), the program listing, and I/O specifications.
2. Types of Documentation:
1. External documentation describe overall purpose and design of the program and its components.
2. Internal documentation are comments, inserted directly into the code, that explain the specific parts (components) of the program as well as obscure sections of the code.

1. Programs should grow with the user's needs. If an application is designed so that it can be updated to accommodate changes, then it is "maintainable".

Most companies have "maintenance programmers" whose primary job is to keep the company's applications up to date.

6. GUIDELINES FOR DEVELOPING AND RELATING CLASSES:

1. When should one use classes? Use classes . . .
1. to represent real-world concepts. This usually occurs in simulation or modeling.
2. to encapsulate design decisions that are likely to change. Having these localized in a class makes it easier to control their effects on the rest of the system.
3. to hide complexity.
4. to provide data structures that can be used in more than one application.
5. to supply a user-friendly, object-oriented interface to an existing application.
6. to give access to data via various APIs (application programming interfaces). In fact,one should plan for the future and use classes even if the immediate application only requires a single instance. This may make your program easier to generalize later.g. containing only static members to eliminate global variables.
2. There are two ways to develop a class hierarchy that strategically different (although they produce the same interclass relationship):
1. by specialization (top-down) in which one begins with an existing class and uses it as a base class for new, more specialized derived classes.
2. by generalization (bottom-up) in which one begins with two or more related classes, recognizes that they have common properties, and designs a base class to embody them. The related classes (which become derived classes of the new base class) then share the implementation of these common features by means of inheritance from the new base class.
3. Guidelines for organizing and relating classes:
1. If a group of classes...
1. has one or more attributes in common consider creating a base class containing one declaration of those attributes.
2. share a complex algorithm, consider creating a base class with a method that implements the algorithm.
3. are special cases of a more general concept, consider creating a super class to represent the general concept.
2. If a class represents a general concept, consider implementing special cases of that general concept as derived classes.
3. If a derived class inherits unnecessary properties from a base class, perhaps the derived class should contain the base class instead.
4. Write every class to allow for addition of derived classes in the future.
4. Guidelines for designating access control specifiers: In general . . .
1. declare as public only those members (attributes and methods) which are to be accessed by __________. This is an application of a fundamental security rule called the Principle of Least Privilege.
2. declare as protected all:
1. methods that should be called only by derived classes.
2. constructors of abstract classes.
3. all members of a class that might be later used as a super class. This still preserves access control except where access is explicitly declared using inheritance.
3. declare as private all:
1. methods that client programs can misuse or have no need for.
2. constructors of private classes.
3. inherited methods that a class disables.
4. In Java, declare package...{continue}

 
 

FIGURE OOSD-1: COMPARISON OF SOFTWARE DEVELOPMENT LIFECYCLES

From the pamphlet, "The Rational Approach"

 

FIGURE OOSD-2 THE OOSD LIFE CYCLES

FIGURE OOSD-2A: OOSD Integrated with Language Implementation	FIGURE OOSD-2B: OOSD Subcycles for Analysis and Design

 

FIGURE OOSD-3: OOSD LIFE CYCLE IN THE JAVA ENVIRONMENT

Diagram from the Rational Rose/Java Early -Access Kit.