Untitled

The purpose of this chapter is to present the basic O-O entities and models in O-O modeling. We will present the basic entities, e.g. system, class, object, attribute, operation, and relationship. We use these entities in creating O-O diagrams, text specifications, and code. We will present the basic models. A model is a collection of diagrams, text specifications, and code to describe certain O-O entities. We have system level models which consist of diagrams and text specifications describing a system as a whole. We have class level models which consist of diagrams, text specifications, and code describing classes and objects within the system. Most important, we have three basic points of view (models) to describe a system and classes: object model, dynamic model, and functional model. These models are described in detail in Object-oriented Modeling and Design by James Rumbaugh et. al. [Rumbaugh-91]. The object model provides a static or structural point of view to describe the system, classes, and relationships. The dynamic model provides a stimulus response time based point of view to describe events, messages, and states. The functional model provides a transformation point of view to describe the transformation (changes) of inputs to outputs.

Three major entities in O-O modeling are system, class, and object as described below.

A system is an entity that can be treated as a unit. A system is composed of simpler components that work together to perform a function. 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. A small system (or subsystem) consists of classes and objects that work together as a unit. A system may consist of 10 to 100 classes as a rough order of magnitude. A system interacts with other systems in a system environment. In C++ a project groups together a set 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. We model a system with a class diagram showing all the classes in the system. In this tutorial we will use the term system to refer to either a small system or to a subsystem. A sample system in this tutorial is the TV Control System which consists of approximately 15 classes in a single executable program.

A class is a description of a group of objects with similar attributes, common operations, common relationships (association, aggregation, interaction, and generalization specialization) and a common semantic purpose. In S/W a class is a module. An attribute is a characteristic or property of an object. An attribute typically holds an atomic object, e.g. an integer, a float, a character, etc. For example, an attribute of a car is gasQuantity which is a float. However, an attribute can hold a structured object or collection object to implement a relationship. For example, an attribute of a car could be currentPassengers which holds a set of current passenger objects. An attribute can hold a set of literals, e.g. a string of characters. An operation is a function, action or set of actions. For example, an operation of a car is to "set gas quantity" and "start". A relationship is a connection or link between classes or between objects. The primary relationships are association ("has a"), aggregation ("part of"), generalization specialization ("is a"), and interaction ("calls or communicates"). 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. An interaction relationship (messages) exists between objects of the Car Class and objects of 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. We model a class with a class diagram and a class specification.

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 Car11 with the attribute value of gasQuantity of 14.2 gallons. In execution an object responds to messages. We model objects in message scenarios. There are three major forms of objects:

A relationship is a link or connection between two classes or between two objects. As described below there are four major O-O relationships: association, aggregation, generalization specialization, and interaction.

Association is a link between classes that is a general mapping between the classes. An association relationship may be described as "has a", "associated with", or "knows about". For example a car "has a" cellular phone. An association has a cardinality or multiplicity. This is the number of objects on one side of an association that may be associated with an object on the other side of the association. For example, one car has one cellular phone. This is an example of a 1 to 1 association. If a car has many passengers, then there is a 1 to many association between car and passenger. The association symbol is a solid line between classes with the cardinality shown on each end of the solid line.

Aggregation is a link between classes that is an association with "part of" semantics. An aggregation relationship may be described as "part of" or "bill of materials" between an assembly (whole) object and part objects. For example, a car "has a part" motor. A part object is an intrinsic part of an assembly object. When an assembly object is created, copied, or deleted, then the part object is created, copied or deleted. An aggregation relationship has a cardinality or multiplicity. This is the number of objects on one side of an aggregation that may be associated with an object on the other side of the aggregation. For example, a car has one motor. This is an example of a 1 to 1 aggregation. The aggregation symbol is a diamond with a solid line between classes with the cardinality shown on each end of the solid line.

A generalization specialization relationship indicates a commonality between a superclass and subclasses. It indicates that the superclass and subclass have common attributes, operations, and relationships. It indicates an "is a" or "type of" relationship. For example, a vehicle superclass may define common attributes, operations, and relationships for a car subclass. A car "is a" vehicle. The generalization specialization relationship is implemented in programming languages with inheritance. The generalization specialization symbol is a triangle on a solid line.

An interaction relationship is a call or communication between objects. An interaction relationship may be described as "calls", "interacts", or "communicates with". For example, the object car1 "calls" the object motor1.

Interaction involves stimulus response behavior with an event or message. An event is an occurrence at a point in time that is a stimulus for a system or an object. The term event is very general and refers to any stimulus for a system or an object. There are several forms of events representing an interaction relationship:

The three primary views in O-O modeling are the object model (OMT Object Model), the dynamic model (OMT Dynamic Model) and the functional model (OMT Functional Model). These three views give us a framework to model systems and classes. They require us to examine a problem from different points of view. They help us achieve quality software that is correct, reliable, and modifiable. All O-O methodologies use these three views in some form with different diagrams and text specifications.

The picture above shows the three points of view in O-O Modeling. First we look at a problem from the object point of view (Object Model). We are interested in the static structure of the entities in the problem. It is like taking a photograph of a entity like a car. The photograph shows the static structure of the car, e.g. body, doors, wheels, etc. In modeling terms we are looking at a the static structure of a system, classes, and relationships. Second we look at a problem from a dynamic point of view (Dynamic Model). We are interested in the stimulus response behavior of entities in a problem over time. It is like taking motion picture of an entity like a car. The motion picture shows a driver opening the car door, starting the motor, and go forward. In modeling terms we see the stimulus response behavior of the car over time. We see the car responding to the driver events (stimuli) of "open door", "start motor", and "go forward with the appropriate responses. We see the stimuli and responses over time. Third, we look at a problem from a functional point of view. We are interested in what is transformed or changed in the problem. It is like looking at the problem in terms of a pepper grinder. Something go into the pepper grinder (pepper corns), there is a transformation of the inputs (grinding), and there is outputs (ground pepper). In modeling terms we see the transformations of inputs to outputs in operations.

In O-O modeling we have system level and class level points of view. Initially we describe a system from an external point of view (system level) to determine overall system requirements, boundary, interfaces, and behavior. Then describe the system from an internal point of view (class view) to describe classes, objects, and relationships within the system. This is describing a system with different levels of abstractions. The highest level of abstraction is the system view which is very general. The lower level of abstraction is the class view which is more detailed. For example, in the Car example, we model the Car Simulation System first, then model the Car as a class in the Car Simulation System. In the TV Controller example, we model the TV Control System first, then model the TV Controller class inside the TV Control System.

To rapidly model and prototype O-O systems, it is desirable to focus on a single system within a large system environment. With this focus we can model and prototype this single system with a dedicated team of developers, then integrate this single system with other systems. In the real world to construct a house, it is desirable to focus on a major component of a house, for example, the roof, with a dedicated team of workers. In S/W it is desirable to partition a large S/W system into manageable subsystems that can be linked or connected together. The purpose of this section is to present a "how to" focus on a single system and to model the system within its environment.

In the system view we create diagrams and text specifications for the system as a whole without looking inside the system. We have an external point of view. Key questions are: What is the system? What is the system boundary? What is the system behavior? What events does the system respond to? What are the inputs and outputs (objects) that are passed into or from the system? In the system view we use the object, dynamic, and functional points of view. From the object view, we identify the key entities that the system interfaces with. We identify other systems that are associated with the system. From the dynamic view, we identify the time based behavior of the system. We identify input events, output events, and states for the system. From the functional view, we identify input objects, output objects, and system operations (transformations).

In the class view we create diagrams and text specifications for classes and relationships in the system. We have an internal point of view. Key questions are: What are the classes in the system? What are the relationships between the classes in the system? What are the interactions between objects in the system? What are the states of objects in the system? What are the transformations of objects performed by class and object operations?

This table shows the key diagrams and text specifications by taking a system and a class view.

	System Level	Class Level
Object Model	Display entities in system requirements statement, system drawing, system block diagram, system diagram, system specification	Display entities in class diagram and class specifications
Dynamic Model	Display interactions and states in system interaction diagram, system interaction scenario, and system state diagram	Display interactions and states in object interaction diagrams, object interaction scenario, and state diagrams
Functional Model	Display transformations in system operation table and system operation specification	Display transformations in operation tables and specifications

Note - The data dictionary listing and describing terms should be updated in each model.

To model and prototype a system, we will create diagrams, text specifications, and code in three general models shown below. These models group and organize the diagrams, text specifications, and code. First, the system models have information on the system as a whole, such as the system requirements and system drawing. We model the system from the three points of view: object view, dynamic view, and functional view.

Next, we model classes, objects, and relationships in the system. We create class diagrams and class specifications for classes within the system. We model classes, objects, and relationships from the three points of view: object view, dynamic view, and functional view.

After the system is modeled and prototyped, we then take an implementation view to design the implementation system. Here we must update or modify all diagrams, text specifications, and code for the implementation configuration. We provide for the user interface, persistent storage, distribution, and connectivity. For example, we update or add new diagrams, text specifications, and code based upon a "multi-user PC Windows NT system". In this tutorial, we are assuming a very simple implementation configuration of a PC with text input and output or a Windows GUI. The implementation phases are based upon Coad and Youdon's components [Coad-91] and the architecture components presented in Yourdon's Mainstream Objects [Yourdon-95].

To model and prototype a system, we are going to apply the three primary views of O-O modeling to create documentation for the object model, dynamic model, and functional model. The first training objective is to model a car where a user can start the car, operate at a speed, and stop the car. In the object model, we will make a drawing of the user and the car. Then we'll make a class diagram showing attributes, operations, and relationships. In the dynamic model, we'll create a system interaction diagram and an event scenario listing input and output events from the user to the car, and a state diagram. In the functional model, we'll list the transformations and correctness assertions for the operations in the car class.

To model and prototype a class we will view the class from the three points of view. In the object model we will create the following: system requirements statement, drawing, class diagram, and class specification. In the dynamic model we will create the object interaction diagram (messages) and state diagram. In the functional model, we will update operation specifications with transformations and correctness assertions. We will automatically generate C++ source code using a CASE tool and then update the source code with messages, transformations, and correctness assertions for an executable prototype. Using these three points of view, we'll first model a car to provide a physical example. A physical example is easiest to understand the basic concepts. Then, we'll use these three views to model a TV Control System for a more detailed and complete example.

In this tutorial we will present an O-O modeling approach based upon the Analysis Model of the Rumbaugh OMT. For the various examples we will progress through the following stages or models:

In modeling a system, we will generally document each major aspect of the system with diagrams, text specifications, and C++ source code. The table below lists the documentation and code products to describe a system. The figure below (roadmap) provides a graphic view of the documentation and code products.

-------------------------------------------------------------------------------------------------------------------------------

Object Interaction Diagram Object Interaction Scenario & Specification Generated Code

In O-O modeling we create a large number of diagrams, text specifications, and code. The roadmap below graphically shows the various documentation products. Key questions are: Why do we create so many documentation products? Are all these documentation products really needed? We need documentation products because we are modeling a system and classes from the following points of view:

When we examine a system and classes from these various points of view we see the system and classes differently. It helps us to create better, more complete, and more accurate models. These lead to better, more complete, and more accurate end products. Some of the documentation below can be eliminated. For example, you could eliminate some text specifications, the data dictionary, and state diagrams. Some documentation can be very brief or informal. For example, you could do an object interaction diagram "on the back of an envelope". The important thing is that you completely describe a system or classes from multiple points of view leading to a effective end product (software).

The following is a suggested roadmap of diagrams, text specifications, and code for an O-O project. This roadmap should be evaluated and updated for each specific project. Step by step instructions will be provided to create each of these diagrams, text specifications, and code.

There are major O-O entities and relationships to model. An O-O entity such as class and object is a basic building block to describe a system. A relation, such as association, is a link or connection between two or more O-O entities. We desire to describe each O-O entity with a diagram, a text specification, and C++ source code. Each of these O-O entities and relationships will be described in detail in later sections. The table below lists the major O-O entities and relationships that are used in O-O modeling. We will progress through the various models numbered 1 through 6 in the previous table. In each of these models there are key entities and relationships. For example, "4 - Classes and Relationships - Object Model" has the following key entities: classes, attributes, and operations. It has the following key relationships: association, aggregation, and generalization specialization. For each basic entity and relationship, there is one or more diagrams to graphically show the entity or relationship. There are one or more text specification forms to textually describe each basic entity or relationship. There are one or more C++ implementation features for each entity or relationship. The figure below shows the major O-O entities and relationships in the various O-O models.

For example, take the entity attribute such as Car Color. We describe the attribute graphically in a class diagram. We textually describe the attribute in an attribute specification form. We implement the attribute in C++ as a data member in the Car class. Fortunately, CASE tools provide excellent support to create diagrams, text specifications, and to generate C++ code for each of the basic entities and relationships in the table below. A major purpose of this tutorial is to describe each of these basic entities and relationships and to present "how to" graphically display, textually describe, and program in C++ each basic entity and relationship. The table below brings together the basic entities, diagrams, text specifications, and C++ implementation features.

Table Diagrams, text specifications, and C++ features for basic entities and relationships in O-O modeling.

----------------------------------------------------------------------------------------------------------------------------

Input & Output Events Use Case Diagram Use Case Descriptions Objects or Function Calls

Objects & Messages Object Interaction Object Interaction Scenario Function Calls

------------------------------------------------------------------------------------------------------------------------

The table below brings together the basic entities, diagrams, text specifications, and CASE tool scripts. As shown in this table, there is script file for each text specification. There is a data dictionary script for each model.

Table Diagrams, text specifications, and CASE tool script files for basic entities and relationships in O-O modeling.

----------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------

With a scripting CASE tool, you can use or create various scripts to print out model information. As shown below there are four basic outputs from scripts: reports in list format, tables to be imported into a word processor, data dictionary reports listing terms, and code files. The scripts in this table are .SCT text files, e.g. RPTALL.SCT that are used in the With Class CASE tool.

Model	Diagram - .OMT	Report Scripts for list format - .SCT	Table Scripts that create a table - .SCT	Data Dictionary Scripts - .SCT	Sample C++ Gen Scripts - .SCT
System Object Model	System Diagram (OMT Notation)	RPTSYS	TABSYS	DDSYS	N/A
System Dynamic Model (Events)	System Interaction Diagram	RPTSYSIN	TABSYSIN	DDSYSIN	N/A
System Dynamic Model (States)	System State Diagram	RPTSTATE	TABSTATE	DDSTATE.	N/A
System Functional Model	N/A	RPTOPER	TABOPER, TABOPPRE	N/A	N/A
Object Model	Class Diagram	RPTALL,RPTCLASS,RPTATTR,RPTOPER,RPTRELAT	TABCLASS,TABATTR,TABOPER,TABRELAT	DDCLASS	CPPHDMAX, CPPFUMAX
Dynamic Model (Messages)	Object Interaction Diagram	RPTOBJ	TABOBJ	DDOBJ	TABOBMSG
Dynamic Model (States)	State Diagram	RPTSTATE	TABSTATE	DDSTATE	STAHEAD1, STAFUNC1
Functional Model	N/A	RPTOPER	TABOPER, TABOPPRE	N/A

Each major O-O methodology uses all of these basic entities and relationships as shown in the table below. This shows the great similarity of the methodologies. Unfortunately, there is no standard terminology for these basic entities and relationships. For example, Coad/Yourdon use the term service in place of the term operation. In this tutorial we use the terminology from Rumbaugh's Object Modeling Technique [Rumbaugh-91]. However, we extensively use the term "message" to describe the interaction of two objects, such as to invoke an operation.

------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------

The major O-O entities and relationships are used in various O-O languages as shown in the table below. This shows the similarity of these languages. Each of these languages provides a different implementation and different semantics for these entities and relationships. Each of these languages uses its own terminology. For example, an operation is a function in C++, a method in Smalltalk, and a routine in Eiffel. In this tutorial we will primarily use C++ examples and terminology.

------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------

There are several basic entities in O-O Modeling such as classes and objects. There are three basic viewpoints to describe O-O entities, the object model, the dynamic model, and the functional model. These models can be classified as system level models and class level models. To be effective, an O-O modeller should have a good understanding of the basic O-O entities, the three O-O points of view (models), and the distinction between system level and class level models.

buy cialis cialisfunsurforg cialisfunsurforg onlinehtml site cialis and back pain cialis levitra vs combine viagra and cialis allowed black buy casino cialis diet gambling health jack phentermine poker tag viagra xhtml canada over the counter cialis viagra cialis generic viagra cialis viagra levitra prices women take cialis drug buy cialis tadalafil cialis drinking alcohol cialis online usa levitra vs cialis vs viagra brand name cialis cheapest soft cialis cialis get viagra cialis viagra taking cialis with viagra buy cialis where cialis drugs cialis over dose lowest price generic cialis buy cialis generic ciales web site marketing cialis interaction precautions cialis western open add cialis link new buying generic cialis cialis free cialis suggest url valium detox buy cialis pharmacy cialis experience cialis pills online cialis buy cialis dream pharmaceutical cialis and oral sex cialis lawyer columbus compare viagra cialis levitra viagra cialis levitra buy cialis shop tadalafil cialis fast heart rate cialis online pharmacy online pharmacy cialis seychelles buy cialis ebay find tadalafil cheap cialis cialis injury attorney cincinnati cialis uk similar drugs for cialis buy cialis online submit=buy cialis online cialis dose it work cialis no prescription needed generic cialis muncie indiana buy cialis genericf hostingcom link cialis cheap no prescription cialis injury attorney cleveland cialis versus viagra 20mg cialis canada cialis deals cialis forum cialis free consultation cialis sample price viagra cialis levitra buy cialis link onlineinttc cialis class action lawsuit cialis levitra combine cialis and levitra viagra allowed black buy casino cialis diet gambling jack low online order phentermine poker tag viagra xhtml can cialis and viagra be taken together cialis free sample coupon cialis soft tab online consultation purchase cialis buy cialis online us cialis commercial cialis line differences viagra cialis levitra allowed black casino cialis diet gambling health jack phentermine poker tag viagra xhtml can i get cialis in canada cialis free samples cialis samples sale without prescription cialis in detroit area buy cialis cialis drug prescription cialis on second attempt generic viagra cialis levitra best cialis price canadian perscription of cialis cialis free trial cialis site suggest samples of viagra cialis levitra buy cialis now cialis cheap cialis injury lawyer ohio cialis viagra vs valium buying online buy discount cialis cialis effects side cialis online discount cialis soft allowed black buy casino cialis diet gambling jack online order phentermine poker tag viagra xhtml by cialis comment post posted cialis for sale on line cialis prescription las posas de ciales buy canada cialis cheap generic cialis cialis generic price cialis soft tab prescription cialis on line buy cialis online viagra cialis compare levitra cialis link online suggest discount generic cialis . buy tadalafil cialis cialis for sale cialis open western lowest cialis levitra prices buy cialis dosage effects online side warning cheap cialis generic cialis free sample cialis soft tab online consultation usa side effects of cialis buy cialis link suggest cialis attorney columbus cialis information pamphlet cialis stories viagra cialis generica buy cialis viagra cialis compared to viagra cialis new viagra dangers of taking cialis allowed cialis tag viagra xhtml canada cialis cialis for woman cialis overnight hypertension treatment using cialis buy cheap cialis canadian cialis cialis for women cialis price order cialis submit=order cialis buy cialis in the uk cheapest cialis generic cialis generic cialis sale review cialis levitra viagra buy cialis link onlinenew pharminfo cialis and liver disease cialis how to avoid backache cialis soft tabs penis pump plus cialis buy cialis online cialis comparison levitra viagra cialis icos lily online cialis tadalafil swflash 1.cab buy cialis online dreampharmaceuticals cialis co drug eli impotence lilly cialis julilatiwaveprohostingcom link onlinehtml cialis samples submit=cialis samples mixing cialis and viagra buy cialis without prescription cheap cialis submit=cheap cialis cialis female view cialis review lawsuits involving blindness caused by cialis buy cialis generic online canada cialis line cialis female opinion cialis online submit=cialis online generic cialis submit=generic cialis buy cialis link onlinenettc can you mix cialis and viagra cialis fda approval cialis online buy generic cialis 20 mg best price cialis buy viagra cialis levitra cialis erectile dysfunction cialis official website erection does not go down after taking cialis black casino cialis diet followup gambling health jack phentermine poker post viagra cialis 20mg cialis generic link suggest cialis woman sitemap2 add cialis link buy generic cialis cialis dosage cialis melt packs buy generic cialis online