1. CSE687 – Object Oriented Design
Class Notes
Chapter 1 - Modules
Jim Fawcett
copyright (c)
Chapter 1 - Modules

2. Definition
Module:
A module
Chapter 1 - Modules

3. Limitation of Single File Program
What’s wrong with a single file program?
nothing, but as programs grow larger, this format becomes very limiting
all functions are at the same (global) level; that’s what C does, you don’t have a choice
programs grow too large to comprehend as a single entity
eventually, as file size grows, the compiler can not swallow the whole file
Chapter 1 - Modules

4. Limitation of Single File Program
Solution:
break programs up into modules
In C++ each module consists of two files:
a header file contains all public declarations so other modules know how to use this module’s services
an implementation file contains all data and function definitions; that is, it provides the services that the header file announces
Chapter 1 - Modules

5. Modularity Client Chapter 1 - Modules
“In object oriented languages classes and objects form the logical structure of the system; we place these abstractions in modules to produce the system's physical architecture.” Grady Booch, Object Oriented Design with Applications, Benjamin/Cimmings, 1991
Modularization consists of dividing a program into modules which can be compiled separately. C++ performs type checking across module boundaries, using included header file declarations.
Modules in C and C++ are simply separately compiled files.
We place module interface declarations in header files.
Module implementations are placed in separate files which include the header file at compilation time via a preprocessor #include “mod_name.hpp” directive.
Public Interface
header file
mod_name.hpp
Client
Implementation
client_name.cpp
Module
Implementation
mod_name.cpp
#include “mod_name.hpp”
...
#include “mod_name.hpp”
void main() {
... }
#ifdef TEST_mod_name
void main() { ... }
#endif
client_name module
mod_name module
Chapter 1 - Modules

6. Information Cluster Model Type: abstract system model Logical View:
An information cluster encapsulates complex, sensitive, global, or device dependent data, along with functions which manage the data, in a container with internals not accessible to client view.
Public access is provided by a series of accessor and mutator functions. Clients don’t have access to private functions or data.
Implementation:
C module using file scope for encapsulation. All private functions and global data are qualified as static.
C++ class using public, protected, and private keywords to implement public and protected interfaces. Each class (or small, intimately related group of classes) should be given its own module.
Each module implementing an information cluster contains a manual page and maintenance page which describe the logical model for the cluster and its chronological modification history.
public functions
private functions
private data
Chapter 1 - Modules

7. Module Implementation
With two C files:
Implementation file (with extension .c) contains all definitions of functions and data. Global data and all private functions are qualified with the static keyword.
Every server module has a test stub in the implementation file (usually embodied in a main function) which is conditionally compiled when testing the module in isolation.
Header file (with extension .h) which contains the declarations of all public functions, data structures, and macros. No data elements should be public.
or with two C++ files:
Implementation file (with extension .cpp) which contains definitions of member functions and static member data.
Server modules have test stubs incorporated in their implementation files. Application modules contain a main function for the application and do not need a test stub.
Header file (with extension .h) which contains class declaration(s). Public Interface functions go in the public sections of the declaration. Protected and private functions go in the corresponding sections. All data is defined as private member data in the private section of the class declaration.
Chapter 1 - Modules

8. Module Implementation
Each module begins with preprocessor guard statements which prevent multiple declarations, e.g.: #ifndef MODNAME_HPP #define MODNAME_HPP : header body : #endif The endif statement is the last in the header file.
The test stub is the last part of implementation file and is also guarded to permit compilation without the stub:
#ifdef TEST_MODNAME int main(int argc, char* argv[]) { : return err_code; } #endif
Each module’s header file begins with a manual page and maintenance page:
Manual page describes the logical view of module and provides brief descriptions of all public services provided by the module
Maintenance page provides a chronological record of changes to the module since its creation, cited by version number.
Either header file or implementation file may also contain a design notes page which describe the organizing principles, major data structures, and key processes which set the course of the module’s design.
Chapter 1 - Modules

9. Module Structure Header File: modname.hpp #ifndef MODNAME_HPP
#define MODNAME_HPP
- manual page goes here
- maintenance page goes here
- declarations go here
#endif
Implementation File: modname.cpp
- prologue goes here
#include “modname.hpp”
- function definitions go here
#ifdef TEST_MODNAME
void main() {
- test code goes here }
Chapter 1 - Modules

10. What goes in a Module’s Files?
Elements of header file:
Manual page
Maintenance page
Declarations of the module’s public classes and public global functions
Definitions of inline functions, e.g., inline function bodies
Function bodies of public template-based member functions and global functions
Definitions for public constant data items
Includes of other header files with declarations of types used in this header – no other files should be included.
Elements of Implementation File
Prologue, e.g., top part of the manual page, listing file name, platform, and author.
Includes of header files declaring types needed by the code in this implementation – no other files should be included.
Test stub – a main function which tests each function implemented in this file. It is also used to illustrate how a client would use the module and what its outputs look like.
The test stub must be enclosed by compilation guards which enable compilation only when TEST_MODNAME is defined.
Chapter 1 - Modules

11. Incremental Development Model
Begins with requirements analysis, development of architecture and preliminary design. Result should be a design concept and partitioning into modules. As soon as modules are defined, one is selected that has no dependencies on other modules (at least one almost always exists). This module’s development proceeds by implementing one or two functions, adding tests of the new capabilities to the test stub, and verifying nominal operation.
This process continues iteratively until module is complete. Detailed unit test then begins. Its goals are to exercise all paths and predicates in code to find all latent errors, correct them, and verify. Next a module is selected which depends at most on the tested module. It is subjected to same process to develop a complete and verified module. It is then integrated with the first module.
This continues until all the modules have been integrated. Development completes by carrying out qualification test to demonstrate that software meets all its contractual obligations. The outstanding virtue of this approach is that only a small amount of new code is brought into a throughly tested baseline at each stage of development.
Chapter 1 - Modules

12. Incremental Development
Req. Anal.
Preliminary Design
Design
Design
---
Design
phases
Code & UT
Code & UT
---
Code & UT
partially tested
code
Integration Test
partially tested
code
correct code
Integration Test
correct code
Integration Test
modules
Qualification Test
Chapter 1 - Modules

13. Modular System Model Type: abstract system model Logical Model:
collection of information clusters communicating through public interfaces.
Implementation:
One application module and a series of server modules.
One C or C++ server module for each major program activity.
The application module is the executive coordinator.
Each server module has:
an implementation file containing a test stub, with conditional compilation controls for stand alone testing.
a header file which announces the module’s services to clients, e.g., the other servers and/or the application module.
application.cpp
server#1.hpp
server#2.hpp
server#1.cpp
test stub #1
server#2.cpp
test stub #2
Chapter 1 - Modules

14. CATALOG Modules
Chapter 1 - Modules

15. Limitations of Modules
What’s wrong with modular decomposition?
nothing, but this format is not very flexible
modules are defined statically (at compile time)
new instances can not be created at run time
this means that the flexability afforded by run-time creation of data does not extend to modules which contain both functions and data
Solution:
classes support declaration of objects which can be defined either statically or dynamically
classes define both functions and data. An object, which is simply an instance of a class, can be defined statically in static memory, in local memory (on the stack), or dynamically on the heap, just like any intrinsic data type
a program can define as many objects as it needs up to the amount that your computer memory can hold
The classes you define will, of course, be packaged in modules.
Chapter 1 - Modules

16. Module Example
In the following pages we present the source code for fileInfo, one of the CATALOG program’s modules.
Chapter 1 - Modules

17. CATALOG Classes
Chapter 1 - Modules