Modeling Classes and Objects in the Object Model

The purpose of this chapter is to describe how to model the system and classes in a system. The basic topics are:

In this chapter we will describe the an instructional Car Simulation System. We will describe the system consisting of a car class, motor class, and other classes. We will use diagrams, text specifications, and C++ code. In the later chapters we will describe the relationships between the classes in the Car Simulation System with diagrams, text specifications, and C++ code.

First, the system object model is a description of the system as a whole. It consists of diagrams and text specifications at the system level. It is important to understand the system as a whole first, before you model the classes and object inside the system Next the object model is a description of classes and objects in a system. The object model is like a still photograph of a house, park, tennis court, etc. It captures the static structure of a system. It is like an electronics wiring diagram that shows the structure of electronic circuits in a VCR, radio, or television. The key question to create the object model is "What are the classes, objects, and relationships in the system?"

The object model is a description of the static structure of the system and classes and objects in a system. A system is an entity that can be treated as a unit that is composed of simpler components that work together to perform a function. A subsystem is a system that is a component of a larger more complex system. The term system is a general term that may refer to a very large system with smaller subsystems or to a small system without subsystems. Examples of physical systems are a house, a ship, an airplane, a shopping maul, and a hospital.

In software, a small system (or subsystem) may consist of 10 to 100 classes as a rough order of magnitude. In some C++ development environments, such as Borland C++ and Microsoft Visual C++, a project groups together a set of files of classes as a system. For execution, a system is an executable program (.EXE file), a dynamic link library, a process, or other executable entity. In this tutorial we will use the term system to refer to a small system or to a subsystem. Sample systems are the TV Controller System or the Automatic Teller Machine System which consist of 10 to 15 classes. A simplified diagram of classes, objects, and relationships in a system is shown below.

The first system that we will examine is a very simple Car Simulation System. This is for instructional purposes only. It is instructive to examine a real world, physical system in terms of classes, objects, and relationships. Later we'll examine typical software information systems like a TV control, coffee machine control, automobile cruise control, and currency control system.

The Car Simulation System is a simulation of a car with a motor, tires, passengers and a cellular phone. It has the stimulus response behavior to respond to events (stimuli or commands) such as start car, add passenger, and make phone call. In this example, there will be no graphic user interface.

In modeling this system we will use the "O-O Modeling and Prototyping Roadmap" in a previous chapter. We will create numerous diagrams and text specifications.

There are many documentation products to describe the system in the system object model. As shown in the figure below, the system object model consists of the following documentation products: requirements statement, drawing, block diagram, system diagram, and system specification. We will create these documentation products for the Car Simulation System.

Step 1 - To start, create the system requirements statement and system use case descriptions stating what the system as a whole must do.

Step 2 - Create the system drawing to pictorially describe the system as a whole.

Step 3 - Create the system block diagram to show the system with interacting systems.

Step 5 - Create the system diagram. This diagram uses the class diagram format and will be described in a later chapter.

The system requirements statement describes the system and its functionality. It is often referred to as the charter, functional requirements, or problem statement. The system requirements statement may be created with any text editor or word processor. A CASE tool includes a simple text editor that can be used to create the requirements specification. The system requirements statement may describe use cases presented in the dynamic model.

The "Car Simulation System requirements statement" is as follows: The system shall store car information such as gasQuantity. A user shall be able to start the car, operate the car, stop the car, add a passenger, remove a passenger, make a cellular phone call and receive a cellular phone call.

The steps to create the system requirements statement using a CASE tool or text editor are listed below.

The drawing is a graphic, visual representation showing user and other entities listed in the system requirements statement, interviews, and other information. The drawing for the Car Simulation System is shown below. The dotted line shows the system boundary.

- helps define links (communications) between the system and H/W and S/W systems,

- helps define input and output objects that are passed to and from the system in events,

- provides an excellent "starting point" because it is easy to understand and discuss with the client and users.

The system block diagram is a graphic, visual representation showing the system and interacting systems. An interacting system may be an actor from the use case description or may be equipment, devices, or S/W programs that the actors uses to interact with the system. The block diagram has a box for the system being modeled and a box for each interacting system. The system block diagram shows a very high level view of the system. It shows the context and boundary of the system. Optionally, the block diagram may show information that is passed between the system and interacting system. For example, status and speed information are passed between the Car User and the Car Simulation System.

The steps to create the system block diagram using the CASE tool are listed below.

The system diagram (OMT Notation) is a graphic representation of the system and interacting systems. This diagram shows the system with its attributes, operations, and relationships. See the section "Creating the Class Diagram" later in this chapter for instructions on how to create this diagram shown below.

This system diagram (OMT Notation) shows that the Car Simulation System with seven system operations: start, operate, stop, makePhoneCall, receivePhoneCall, addPassenger, and removePassenger.

The system table for the Car Simulation System is shown below. This table shows the system and interacting system information.

System Name	System Attribute Names	System Operation Names
CarSimulationSystem	speed gasQuantity	start operate stop makePhoneCall receivePhoneCall addPassenger removePassenger
CarUser	--	showStatus

System Name, System Attribute Names, System Operation Names SCRIPT_NOREPEAT_HEADER_END

The system specification lists key information about the system as a whole. We will first present a CASE tool specification input form, define the information, and present a sample report. To create the system specification, start with the system requirements statement and system block diagram. The steps to create the system specification using a CASE tool are listed below.

>> Select "Generate - Generate Class Report" and select a system specification report script, e.g. RPTSYS.SCT

This specification form is based upon Grady Booch's Object-Oriented Design with Applications [Booch-94]. He presents a useful system specification for the "Class Category Specification". The following is the key information.

To access the system specification information, you need to know the script variable for each piece of information in the system specification input form. The following are sample script variables from the system specification in a CASE tool. A brief description states what occurs when the script variable appears in a script. For example, when the script variable SYSTEM_NAMEappears in a script, then the actual value of the variable is printed out, e.g. Car Simulation System.

System Description: The Car Simulation System is a simulation of a physical car as a simple object-oriented system. The system responds to the following user commands: start, operate, stop, addPassenger, removePassenger, makePhoneCall, and receivePhoneCall.

The abbreviated script (RPTSYS.SCT) to generate this report is shown below. This script consists of literals, e.g. System Name, and variables, e.g. SYSTEM_NAME. The CASE tool script interpreter uses "text replacement". It prints each literal. It replaces model information for each variable and prints the value of the variable. For example, the variable SYSTEM_NAME is replaced with value Car Simulation System in the output report.

The object model corresponds to the OMT Object Model. The major question is "What are the classes in the system?" We are concerned with O-O entities, basic building blocks inside a system, e.g. class and object. We are concerned with O-O relationships, links or connections between O-O entities, e.g. association, aggregation, and generalization specialization. As described below the object model consists of the following documentation products: class diagram and class specification. A prototype may be created.

In the object model, we define the static structure of classes. We define what is the composition of a class in terms of attributes and operations. We specify the relationships between classes, e.g. association, aggregation, and generalization specialization. The interaction relationship is specified in the dynamic model. We specify constraints which are rules that restrict or limit the values that objects, attributes, and relationships can have. A constraint is that a car can only have one motor and that the gasQuantity has a minimum and maximum value.

The most important aspect of the object model is to describe classes and objects. Modeling classes and objects consists of identifying, describing, and coding. In this section we will define a class and object and then present how to identify classes and objects.

The object model is "snapshot" of a class at a point in time. For example the object model of a Car Simulation System consists of a class diagram, class specification, and data dictionary as shown below.

The object model is important for several reasons. First, it identifies the key entities and relationships in a system. Classes and relationships between classes are the building blocks and connections in a system. Second, it provides the framework of classes to build the system. Third, it ties together all the models. Fourth, a CASE tool can generate an extensive amount of code based upon the object model. The CASE tool generates code from the class diagram and class specifications in the object model.

There are many documentation products to describe classes and objects in a system in the object model. As shown in the figure below, the object model consists of the following documentation products to describe classes and objects: requirements statement, drawing, class diagram, class specification, and prototype. We will create these documentation products for classes in the Car Simulation System.

A class is a description of a group of objects with similar attributes, common operations, common relationships (association, aggregation, and generalization specialization) and a common semantic purpose. An attribute is a characteristic or property of an object. An attribute is typically an atomic literal, such as integer, float, character, etc. or a set of literals, such as a string of characters. For example, an attribute of a car is gasQuantity which is a float. An operation is a function, action or set of actions. For example, an operation of a car is to "set gasQuantity" and "start". A relationship is a connection or link between classes or between objects. The primary relationships are association ("has a"), aggregation ("part of"), and generalization specialization ("is a"). For example, the car class has an association relationship with the passenger class. The car class has a generalization specialization relationship with the vehicle class. The car class has an aggregation relationship with the motor class. The semantic purpose of a class is the reason for being or existence of objects of the class. For example, the semantic purpose of objects of the car class is to provide transportation to carry users from one location to another. Examples of classes include customer, product, order, and account.

We model a class with a class diagram, a class specification, and code as shown in the figure below.

An object represents a person, place, or thing. An object is an instance of a class. An object has an object name (ID) and a value for all attributes and associated objects. For example an object is Car1 with the attribute value of gasQuantity of 14.2 gallons. In execution an object responds to messages. We model objects in message scenarios. Objects may be diagrammed as shown in the figure below for instructional purposes or for message tracing. The Rumbaugh OMT graphic notation for objects is shown below. The Coad/Yourdon graphic notation has a symbol for "class&objects". This represents the class and all objects of the class. The Booch graphic notation has a object symbol to represents objects to show the execution of messages between objects.

How do you identify classes and objects in a system? Classes define objects. Objects represent people, places, and things. The initial question is: What are the people, places, and things in the system? It is easy to identify physical, tangible things in a system. A drawing helps to identify physical, tangible things. In the small Car Simulation System the following are the physical, tangible things: a car, a motor, a cellular phone, tires, and passengers. We start with modeling physical, tangible things first because they are the simplest to identify and to understand.

It is more difficult to identify intangible, abstract things. Ask the following: What is the important information in the system? For example, accounts are important in a bank system. What are the important forms that collect information? For example, an account creation form is important in a bank system. What are the important reports that collect information? For example, a bank transaction report is important. What is the logical grouping of data? For example, an invoice groups together customer and product data items.

There are several techniques to identify classes and objects. The simplest technique is to ask the question "what are the major things in this system". Another technique to identify classes and objects by extracting the major nouns in the requirements statement. Wifs-Brock suggests the use of class - responsibility - collaboration (CRC) cards [Wifs-Brock-90]. Identify the major things (objects) in a system. Assign a person to represent each major object. Walk messages through the system and identify additional objects. Then, describe the class of each object on the CRC card.

Step 1 - Start with the system requirements statement, system block diagram, and system drawing to understand the system as a whole.

Step 2 - Create the class diagram. The class diagram is a visual, graphic representation of classes showing attributes, operations, and relationships.

Step 2a - Identify classes. A class defines objects that represent people, places, and things in the system.

Step 2b - Identify attributes. An attribute is a characteristic, property, or component of an object. An attribute consists of an attribute name, type/class, and value.

Step 2c - Identify operations. An operation is an action, algorithm, or set of steps that typically uses or modifies an attribute value.

Step 2d - Identify the relationships for association, aggregation, and generalization specialization. These relationships represent a connection or link between two classes. Defer identification of interaction relationships (events or messages) until the dynamic model.

Step 3 - Create the text specifications for each class, attribute, operation, and relationship. Generate reports to display or print out the text specifications.

Step 3a - Create the class specification. The class specification provides text information about the class. Class information should include class description, superclasses, access, cardinality, concurrency, transformations and correctness assertions and other information necessary for programming or documentation. Document constraints in the class specification.

Step 3b - Create the attribute specification. The attribute specification provides text information about each attribute. Attribute information includes type (integer, float, string, etc.), access (private, protected, public), initial value, minimum value, maximum value, constraints (rules), and description.

Step 3c - Create the operation specification. The operation specification provides text information about each operation. Operation information includes the return type or class, input parameters, access (private, protected, public), preconditions, postconditions, transformation, exceptions, and description.

Step 3d - Create the relationship specification. The relationship specification provides text information on each relationship such as its name, constraints (rules), and implementation features. For association and aggregation relationships, the cardinality (1 to 1, 1 to many, many to many) is shown.

Step 4 - Create or update the data dictionary. The data dictionary lists the terms and a brief description of each term used in the model, e.g. system and classes.

Step 5 - Check and update consistency with other models, e.g. the dynamic model and functional model. Check all diagrams and text specifications for the consistent spelling, capitalization, and meaning of all names.

Step 6 - Generate the prototype - C++ source code with the CASE tool. Compile and execute the program in the C++ development environment.

Step 7 - After modifying the C++ source code in the C++ development environment, reverse engineer the updated C++ to create an updated class diagram.

The class diagram is a graphic representation of classes and relationships. For each class it shows attributes, operations, and relationships. There are several graphic notations to diagram classes that are available in CASE tools. A primary notation is the Rumbaugh OMT notation. The class symbol is a box with three sections: class name, attributes, and operations. The figure below is an initial class diagram of the Car Simulation System showing the car, motor, and passenger classes. The car class has two attributes, gasQuantity and speed. It has three operations, start, operate, and stop. The motor class has two attributes, rpm and displacement. It has three operations, start, operate, and stop. The passenger class has two attributes, name and seatBeltStatus. It has two operations, fastenSeatBelt and unfastenSeatBelt. Relationships will be shown in a subsequent chapter.

Creating a class diagram is an iterative process of starting with a very basic diagram and then adding more and more details. The following are the general steps to create a class diagram.

Step 3 - Enter a few operations, e.g. start, operate, and stop in the Car class.

Step 4 - Enter a few relationships, e.g. aggregation between the Car class and Motor class.

Step 5 - Repeat the process adding more classes, attributes, operations, and relationships.

In creating a class diagram with a CASE tool, information may be entered directly on the diagram or into a class form as shown in the figure below.

The class diagram is the single most important diagram in O-O modeling. It graphically shows the classes and relationships in a system. It should be understandable to developers and programmers. It is the basis to automatically generate source code. It shows the structure of a system. It is useful to evaluate the software quality factors of correctness, reliability, modifiability, and reusability. It is useful to show the client and describe the system in terms of classes and relationships. The complete class diagram for the Car Simulation System is shown in Chapter 3.

The class specification lists important text information for each class. It is a key documentation product to document a class. Its purpose is to state adequate information to document and to program each class. We will first present a CASE tool specification input form, define the specification information, and present a sample report. The steps to create the class specification using a CASE tool are listed below.

>> Enter class documentation, e.g. description, access, concurrency, cardinality, persistence, etc.

>> Select "Generate - Generate Class Report" and select a report script, e.g. RPTCLASS.SCT or TABCLASS.SCT

The class specification is important to capture and organize important information to document the system. It requires that you examine each class from many points of view, such as access, cardinality, persistence, etc. that you might overlook without the class specification. It assists you to investigate these different aspects, such as access and persistence. It promotes communication with the client to resolve ambiguous requirements.

The figure below is a sample class specification input form from a CASE tool for the Car class.

The description of the each information item is listed below. form of the class specification used in this tutorial is adapted from the Booch class specification presented in Object-Oriented Design with Applications by Grady Booch [Booch-94].

The following are additional information items that may be collected for each class.

To access the class specification information, you need to know the script variable for each piece of information in the class specification input form. The following are sample script variables from the class specification in a CASE tool. A brief description states what occurs when the script variable appears in a script. Class variables access class information.

Class Description: Car Class stores car information for a user to start a car and get and set car information.

An abbreviated script (RPTCLASS.SCT) to generate this report from the class diagram is shown below.

The following is sample additional information that could be collected for the Car class. This information could be stored in the Class User fields.

Applicable Documents: Block Diagram - c:\car\carblock.omt; Class Diagram - c:\car\car.omt; State Diagram - c:\car\carstate.sm; C++ source code c:\car\car.cpp and c:\car\car.h

The table listing classes, attributes, operations, and relationship traversal names is shown below.

Class Name	Attribute Names	Relationship Traversal Path Names	Operation Names
Car	gasQuantity speed	--	start operate stop
Motor	rpm displacement	--	start operate stop
Passenger	name seatBeltStatus	--	fastenSeatBelt unfastenSeatBelt

The script (TABCLASS.SCT) to create this table from the class diagram is shown below. This generates a comma delineated text file to be imported into a Windows word processor.

Class Name, Attribute Names, Relationship Traversal Path Names, Operation Names SCRIPT_NOREPEAT_HEADER_END

CLASS_NAME,[NO_RETURN ATTRIBUTE_NAME],[NO_RETURN ASSOCIATION_ONE_NAME][NO_RETURN ASSOCIATION_MANY_NAME][NO_RETURN AGGREGATION_ONE_NAME][NO_RETURN AGGREGATION_MANY_NAME],[NO_RETURN OPERATION_NAME]

The data dictionary lists and describes key O-O entities and terms. The purpose of the data dictionary is to aid the model builder or model user to lookup and understand names and terms used in the model. As a minimum the data dictionary lists and describes the classes in a system. The data dictionary may list and describe all modeling entities in the system including classes, objects, attributes, operations, relationships, etc. The data dictionary listing terms may be created using the CASE tool or any word processor. The steps to create the data dictionary listing terms using a CASE tool are listed below.

>> Select "Generate - Generate Report" and select the data dictionary report script, e.g. DDCLASS.SCT

>> Select "File - Edit File" and enter the report name to view the data dictionary

>> If desired, import the report into a Windows word processor to sort and format the report.

The initial data dictionary for the Car Simulation System is as follows. Updates to the data dictionary will be provided in each of the models.

Entity Name	Type of Entity	Enclosing Class	Entity Description
Car	Class	--	Car transports people and items.
gasQuantity	Attribute	Car	Amount of gasoline in the car available for use.
speed	Attribute	Car	Velocity of the car.
start	Operation	Car	Starts the car.
operate	Operation	Car	Operates the car at a speed.
stop	Operation	Car	Stops the car.
Motor	Class	--	Motor runs the car.
rpm	Attribute	Motor	Revolutions per minute.
displacement	Attribute	Motor	Size of motor.
start	Operation	Motor	Starts the motor.
operate	Operation	Motor	Operates the motor at a set rpm.
stop	Operation	Motor	Stops the motor.
Passenger	Class	--	Passenger in the car.
name	Attribute	Passenger	Name of the passenger.
seatBeltStatus	Attribute	Passenger	Status of the seat belt - fastened or unfastened
fastenSeatBelt	Operation	Passenger	Fastens the seat belt.
unfastenSeatBelt	Operation	Passenger	Unfastens the seat belt.

The abbreviated script (DDCLASS.SCT) to generate the data dictionary from the class diagram is shown below. This script prints out class, attribute, operation, and relationship information from a class diagram. Literals are lower case. Variables are upper case. The repeat [ ] operation is to repeat printing multiple values.

In this tutorial there will be a separate data dictionary script for each major model. To create a system wide data dictionary, you must consolidate the separate data dictionary reports into a single file in a Windows word processor. The following are the various data dictionary reports used in this tutorial.

Model	Diagram	Script
System Object Model	System Diagram (OMT Notation)	DDSYS.SCT
System Dynamic Model (Events)	System Interaction Diagram	DDSYSIN.SCT
System Dynamic Model (States)	System State Diagram	DDSTATE.SCT
System Functional Model	N/A	N/A
Object Model	Class Diagram	DDCLASS.SCT
Dynamic Model (Messages)	Object Interaction Diagram	DDOBJ.SCT
Dynamic Model (States)	State Diagram	DDSTATE.SCT
Functional Model	N/A	N/A

In this section we will present C++ classes and objects. We'll present how to generate C++ code with a CASE tool. Then we'll present how to compile, link, and execute the C++ source code in a C++ development environment. To understand C++, we need to transition from the O-O modeling terms to C++ terms. The table below is the comparison of the O-O modeling terms and C++ terms.

A program in C++ consists of a single main function with preprocessor directives (include statements), global variable and function declarations, and classes. The simplest C++ program is shown in the listing below. Later we'll show many programs with classes.

#include <iostream.h> //preprocessor directive to include the file //iostream.h this file is required for C++ //input and output with

A class in C++ is an entity that encapsulates data members and function members. A data member implements an attribute or an association/aggregation relationship. A function member implements an operation. The C++ form (syntax) of data members and function members will be presented in the next chapter.

A class in C++ consists of a class declaration and a member function definitions. A class declaration introduces data members and function members. It is typically placed in a header file (.h file). A member function definition is the complete C++ source code for the function. Member function definitions are typically placed in a source code file (.cpp file). CASE tools generate function definitions for very simple functions such as functions to get and set attribute values. CASE tools generate a fill-in code template for other function definitions. A programmer must fill in C++ statements to complete the function definition. The form of a class declaration is as follows.

The class name identifies the name of the class, such as Car. The class declaration has data members to represent attribute and function members to represent operations. Data members and function members have private, protected, or public access (visibility). A private member declaration may be a data member representing an attribute or function member representing an operation. A private member is accessible from within the class only. "float gasQuantity" is a private data member for the attribute gasQuantity. A public member is accessible from outside the class. A public member may be a data member or a function member. "start ()" is a public data member that is accessible both inside and outside the class. A protected member is accessible from within the class or from a subclass.

A C++ class has two special types of member functions, constructors and destructors. A constructor initializes an object of a class. It is invoked whenever an object of the class is created. The constructor has the same name as the class, such as Car (). A destructor deletes an object. A CASE tool generates default C++ constructors and destructors.

A C++ object is an identifiable region of memory that can hold a value or set of values. An object has a name (ID), a data type or class, and a value or set of values. The following are examples of objects of fundamental data types such as integer, float, and character: int anInterger, float aFloat, char aCharacter. The following are examples of objects of user defined classes: Car car1, Motor motor1, Passenger passenger1.

There are three primary ways to create an object in C++: automatic (local) object, dynamic object, and static object. An automatic C++ object exists within a scope of an enclosing block ( {} ), function, class, or file (global). Memory is allocated as soon as the object is created. Memory is deallocated automatically when the object goes out of scope. This occurs when the execution of the program leaves the enclosing block ( {} ), function, class, or file. An automatic object is the simplest to create. It is also known as a local object. The guideline is to create an automatic object unless you specifically require a dynamic or static object. For example, use a dynamic object not an automatic object if you need to dynamically create and delete objects at runtime. An automatic object declaration has the following form (syntax) with examples:

The second way to create objects in C++ is to create dynamic objects. A dynamic C++ object is an object with a pointer identifier. The object name is a pointer. A pointer is a C++ variable that stores the address of an object or other stored entity. The pointer points to the object (region of storage) that it identifies. Dynamic objects are important to be able to create and delete objects at runtime (dynamically) during the program execution. For example, a car may have one to six passengers. Using dynamic objects, we can create each passenger as needed during program execution. A dynamic object declaration has the following form (syntax) with examples:

The programmer has the responsibility to allocate and deallocate memory. Allocation is done with the new keyword. Deallocation is done with the delete keyword. An example of deleting a dynamic object is delete passenger2;

The third way to create objects in C++ is to create static objects. A static object exists for the duration of the program. Memory is allocated as soon as the object is created. Static objects are used to create class attributes which store information applicable to all objects of the class. A static object declaration has the following form (syntax) with an example:

A CASE tool may be used to automatically generate class declarations (.h files) and fill-in templates for function member definitions (.cpp files). A CASE tools greatly facilitates coding because it generates the C++ class declarations and fill-in code templates for function member definitions. A CASE tool uses the class diagram and class specifications to generate the code. The steps to generate C++ code with a CASE tool are as follows:

To code a class in C++ code the class declaration in the header file, code the function definitions in the source code file, and code a main (test) function in a source code file. The listing has an #ifndef conditional directive that was generated by the CASE tool. The #ifndef directive tests whether an identifier is currently in force. These directives are required for compilation to avoid "multiple declaration" compilation errors. In the diagram below, key aspects of the class declaration are shown on the left. This information class diagram shows that a class declaration should have a #define statement, a class name, data members, a constructor, function members, and a destructor. The class diagram on the right shows sample C++ identifiers that are also in the code listings.

- provide #ifdefs, #define, and #endif compiler directives to avoid multiple class declarations, e.g. #define __CAR_H,

- define a default constructor to initialize an object with default data member values in the initializer list, e.g. Car () : speed (0) { }

In the function definitions, define functions, e.g. void Car::operate (int aSpeed) { speed = aSpeed; }. In the main (test) function definition, define a main (test) function to include the class declaration header file, create an object of the class and to invoke an operation. The complete code listing is shown below.

//////////////////////////.h file//////////////////////////////////////////////

//////////////////////////.cpp file//////////////////////////////////////////////

//////////////////////////main.cpp file/////////////////////////////////////////

The CASE tool generated two files from the class diagram: car.h and car.cpp. The car.h file contains the car class declaration with the data member speed and the function member operate. The car.cpp file contains the function definition for the operate function member. It is a fill-in code template that may be updated with C++ statements. A CASE tool is helpful for generating class declarations (.h files) and fill-in templates for function member definitions (.cpp files). However, it is just a start. All the algorithmic details must be coded in function member definitions.

To generate the C++ class declaration and function definitions, we used two scripts. A class declaration script generated the Car.h file and a function definition script generated the Car.cpp file. We created the main.cpp manually. The two scripts are shown below.

//////////////////////TRUNCATE_EIGHT$CLASS_NAME.h file/////////////////////////

class CLASS_NAME[NO_RETURN NO_REPEAT: NO_REPEAT public BASE_CLASS ,DELETE_LAST_SYMBOL]

[NO_RETURN NO_REPEAT: ATTRIBUTE_NAME(ATTRIBUTE_INITIAL_VALUE),DELETE_LAST_SYMBOL]

////////////////////TRUNCATE_EIGHT$CLASS_NAME.cpp file///////////////////////////

Once the source code has been automatically generated, then the source code can be compiled, linked, and executed in a C++ environment, such as the Borland C++ environment. With this environment it is necessary to create a project file which is a list of the source code files (.cpp files) in the program. Some CASE tools automatically create the project file. A simple project file consists of the main.cpp and car.cpp files.

The steps compile, link, and execute the program in a C++ environment (Borland C++) are as follows:

>> Check the environment options - directories to ensure all included files can be accessed.

>> Update the generated C++ code as required to add function calls, other #include directives, member function definitions, etc prior to compiling.

Some CASE tools automatically generate a project file or make file. A project is a set of files needed to create an executable file. With Borland C++ you must have a project file when you have multiple source code files (.cpp files). The project file is the list of the source files (.cpp files) in the project. In the very simple program below, the project file has car.cpp and main.cpp in it. Projects that use the Borland ObjectWindows Library (OWL) must have owl.def in the project file. Projects that use resource files (.rc files) from a GUI builder such as the Borland Resource Workshop must have the resource files (.rc files) in the project file. Resource files are used to create GUI elements such as dialog boxes.

After automatic code generation, the C++ code must be updated to execute in a C++ development environment. A main function must be added and the function definitions must be updated with C++ statements.

Additionally, it is necessary to ensure that all the appropriate files are included. To include a file, enter the precompiler include directive such as #include "car.h" in the main function file. The preprocessor removes the #include line and conceptually replaces it with the entire text of the included file at that point in the source code. A CASE tool will automatically generate include directives. However, if you use library functions or classes, then you must enter the appropriate include directive. Examples are #include <iostream.h> and #include <strng.h> to include the appropriate header files. The following are several general guidelines to include files.

Modeling the system and classes and objects in a system is an important part of O-O modeling. A system is an entity that can be treated as a unit that is composed of simpler components that work together to perform a function. A system may have other systems as subsystems. A system has classes and objects. A class is a description of a group of objects with similar attributes, common operations, common relations (association, aggregation, and generalization specialization), and a common semantic purpose. An object is an instance of a class. An object represents a person, place, or thing. An object has a value for each of its attributes. Modeling classes and objects consists of creating documentation products including a drawing, data dictionary, class specification, class diagram, and source code. A CASE tool is useful to create documentation products and to generate the initial source code. With C++, the generated source code must be updated with main function and C++ statements in function definitions.

free cialis submit=free cialis cialis com cialis order java.js buy cheap cialis online cialis exchange link cialis tadalafil american express viagra cialis buy cialis link mycialsnowprohostingcom onlinehtml cialis impotence drug eli lilly co cialis without prescription in detroit area why cialis buy cialis link onlinehtm pharmacyrxfreewebtoolscom cialis in south africa do u take cialis everyday add cialis url cialis and manufacturer cialis muncie indiana how to stop viagra cialis spam black buy casino cialis diet followup gambling jack low online order phentermine poker post viagra cialis comparison levitra cialis online sales mexican cialis boelolokeepkidshealthycom cialis link cialis day next cialis purchase mixing cialis with effexor bulk cialis and viagra sold world wide on line cialis discount save cialis story safest of cialis levitra viagra buy cialis href newopasblogdrivecom cialis en venezuela cialis western open tee times viagra and cialis cheap buy cialis link onlinecolnu cialis europe viagra cialis submit=cialis should i buy cialis online buy cialis amsterdam cialis dose cialis tablet sildenafil cialis generico buy cialis cialisfunsurforg onlinehtml cialis drug impotence cialis testimonials sitemap1 buy cialis no prescription cialis for order cialis side effects order cialis buy cialis dreampharmaceuticals cialis drug cialis peak serum time half life pill cutters for cialis blindness cialis cialis dysfunction erectile cialis pill low cost generic cialis blogid buy casino cialis inurl order phentermine poker viagra cialis compare viagra cialis soft tabs den haag results of comparisons of viagra and cialis buy cialis in uk cialis en espanol cialis prescriptions map buy cheap cialis cialis link onlineinfo cialis cost low cialis online sale mixing viagra and cialis black buy casino cialis diet followup gambling jack order phentermine poker viagra cialis cheapest online prices cialis news information about cialis and livetra black buy casino cialis diet gambling jack online order phentermine poker tag viagra xhtml cialis class action suit cialis open ticket western order cialis online black buy casino cialis diet holdem jack online order phentermine poker tag texas viagra xhtml cialis comment info personal remember cialis order in south africa is cialis over the counter drug black casino cialis diet followup gambling health jack phentermine poker viagra cialis company cialis on line generic soft tab cialis better erections by combining cialis and viagra cialis attorney ohio cialis melt tabs how does cialis work black buy casino cheap cialis diet followup gambling health jack online order phentermine poker viagra cialis black box warnings cialis mexico online how to get best results with cialis archive buy cialis cialis discount generic cialis online purchase how viagra cialis levitra work black buy casino cialis diet followup gambling jack online order phentermine poker viagra cialis cedar park cialis mg index best cialis generic price cialis and no prescription required cialis link pharmacyrawcsorg generic cialis online best place to get totally free viagra or cialis samples cialis and venous leak