Text that is violet, underlined, and in italics, will be replaced by blanks, that the reader is asked to "fill in", e.g. class will be replaced by _______ in the final version of this document.
{Coin the term "TCMD" for "Tony's Class Modelling Diagrams" and use in sections 2 and 3; convert to UML in section 4.}

PRACTICAL GOAL OF THIS PRESENTATION: Be able to answer

Last  : 1/21/06; 10/5/06; 8/31/07
UNDER RECONSTRUCTION
The URL of the online version of this document is:
http://faculty.frostburg.edu/cosc/htracy/UML/Intro_OOSDwithUML.html

AN INTUITIVE INTRODUCTION TO
OBJECT ORIENTED SOFTWARE DEVELOPMENT (OOSD)
USING THE UML
(This version assumes that this whole document has been read before its oral presentation.)
(It is recommended that first-timers, read the summary and conclusions before beginning this presentation.)

NOTE:  green colored text designates critically important concepts in this presentation.

The object oriented paradigm ("Paradigm" means a way of thinking, an overall approach.) has replaced the structured programming paradigm as they optimum strategy for developing modern software.  This means that the "old fashioned" way of developing software, "programming",  has been superseded by the "object oriented" approach .  Unfortunately, many current textbooks do not effectively present the object oriented paradigm, probably because they are written by authors who were schooled in structured programming and have not made the necessary transition to the "new way of thinking".  The following presentation attempts to address this problem by introducing the fundamental ideas of OOSD via an intuitive approach (based on common sense) and contrasting the older programming paradigm and the newer object oriented paradigm.  Specifically this intuitive introduction to the object oriented paradigm has the following goals:

1. to present an intuitive foundation to OOSD,
2. to emphasize that software development has shifted from a "programming" paradigm to the "object oriented" paradigm (based on the "class" construct and a "modeling" approach) and to provide a warning that thinking in terms of "programs" can mislead, or at least blur the focus of novice software developers,
3. to introduce all the fundamental features of the object oriented paradigm, and
   
4. to introduce the UML (Unified Modeling Language) , THE standard representation of object oriented software.  (Note that the UML 2.0 has thirteen types of diagrams; however, in this presentation we use only the most fundamental type of UML diagram, the "class diagram"; it is used to represent the static, structural view of software. Consequently, it is important to acknowledge the modifier "class" when it precedes "diagram".)

If you are an FSU computer science student, please read the Tony's specification of your objectives when studying this presentation.  To pursue these goals and objectives, this presentation has the following sequence:

1. representation of OOSD as a contrast to "programming" (See the following table.),
2. discussion of the evolution of programming through "structured programming" to OOSD,
   
3. identification of the fundamental concepts (and the terminology representing them) of the OO paradigm  (The style of presentation is an intuitive development of the concept of an " object architecture" consisting of related objects each with encapsulated attributes and operations that specify, respectively, each object's state and behavior),
   
4. representation of the preceding object architecture using the UML , the universal standard for representing the OO paradigm.  (Note that there are, currently, thirteen different types of diagrams in the UML , but we cover the most fundamental, UML class diagrams, in this presentation; class diagrams are, by far, the most useful in representing the structure of object oriented software.), and
   
5. summary

The key problem that this presentation attempts to address is that current textbooks do NOT effectively present the foundation of modern software development, the object oriented paradigm.  Instead, too many still utilize the old fashioned, "programming" paradigm or, what is almost as bad, try to present object oriented paradigm with programming terms, e.g. even the term "object oriented 'programming'" is misleading,  because "programming", by definition is "algroithm oriented".   (Note that programming is sometimes called the "classical" paradigm.)  You should note, however, that OOSD is a superset of Structured programming; this is explained later.  The following table emphasizes the necessary shift in terminology required to transition from structured programming (SP) to object oriented software development (OOSD).  (Notice that the word "programming" does not even appear in my presentation of the OO paradigm.  The reason I abandon "programming" is because it represents the "do this" approach to software development,   The OOSD paradigm is a "model this" approach , a fundamental reorientation of the strategy IN software development. WARNING; typical current textbooks still use "programming" so you should be careful to remember the word's meaning has to change dramatically to apply to OOSD.)

This table is the foundation of this presentation, and it attempts to concisely relate some of the most important concepts in computer science, so take time to analyze the table.  If you are a beginning software developer, you can not fully understand all of it, but don't let that worry you; you should return to this table frequently as your experience with OOSD expands.  (Hopefully, if you are a computer science student, by the time you graduate, you can draw your own table, because you "understand" all these ideas and won't need "Tony's representation of them" anymore!  The tabular format provides a memorable structure that helps you organize and focus your thinking on the essential features of OOSD.  Therefore,

• try to "visualize" the 4x3 format of the table and remember that its primary purpose is to compare two paradigms (ways of thinking) of software development.
• Also note that the bottom two rows take you, left to right, from an "abstract foundation" of the paradigms through tangible "representations" (illustrations) of that foundation to the "implementations" (software) of those representations.  The first column simply distinguishes the two paradigms.  The second column identifies the fundamental concepts on which each paradigm is based.  The third column presents a tangible (but language independent) way of representing the task to be accomplished by our software. To "communicate" the idea of the Abstract Foundation
• to another human we write/draw the Abstract Representation  (If we communicate this accurately we can work as a team to develop software.)
• to a computer we write a Software Implementation.  (The "software implementation " is the code that implements the "abstract representation " in a particular programming language.)

SAQ1: ( A SAQ is a "Self Assessment Question", that may be skipped on a first reading, but should be adequately answered before concluding the study of this presentation.)    In the preceding table, what is the most important difference in the items in the last column (Software Implementation) and all those to their left?
SAQ2: What is the primary (a) similarity and (b) difference of the abstract foundations of the programming paradigm and object oriented paradigm?

2. THE EVOLUTION OF SOFTWARE DEVELOPMENT FROM PROGRAMMING TO OOSD:

The OOSD paradigm is the latest stage in what has been a continuous evolution away from the concept of one big "program" .  The very first software, machine language programs written in binary code ("1s" and "0s"), were called "programs" to reflect the fact they were a single, long sequence of machine language instructions, i.e. a program of instructions, like a recipe.  These "programs" evolved from machine language programs through assembly language programs to programs written in high level (English-like) languages.  Finally, in the structured programming paradigm (still the focus of many text books), the big program was subdivided into "miniprograms' called " functions " and "procedures ".   The replacement of detailed instructions with meaningfully named modules (the "miniprograms") is called " abstraction ".   This modularization of programs was the first step in the transition from "structured programming" to "OOSD".

• The collection of functions and procedures that are essentially unrelated in structured programming are, in OOSD, associated with unique abstract objects called "classes"; the functions and procedures are called "operations" (UML term for the abstract concept) or "methods" (code) in OOSD.   By definition, operations/methods are "encapsulated", along with attributes (which specify data) within classes; the attributes define the state of the class, and the operations/methods declare its behavior..
• Finally, the individual abstract objects (represented by unique classes) are linked via specific relationships to other classes thus creating an "object oriented architecture", the modern replacement of an algorithm or program.

SAQ3: "Encapsulation" is a fundamental feature of OOPL.  What is encapsulated in what?

3. FUNDAMENTAL CONCEPTS OF THE OO PARADIGM, AN INTUITIVE INTRODUCTION:

Now that we have laid a foundation of the fundamental ideas of OOSD, we are ready to generate the concepts involved in OOSD, we can show how these concepts are represented and a software architecture is modeled.  The following is an intuitive introduction using the best, most concise example (that I can think of) called a "Geometry Application"; I use this to illustrate all the basic constructs of object oriented software design as well as the simple, basic strategy for developing an object oriented software architecture.  Note that in real OOSD, the developer would utilize UML diagrams from start to finish, but, in order to establish an intuitive foundation to OOSD, I use simple illustrations that I later translate into UML class diagrams.  Hopefully, you will see that that OOSD and its UML representation are based on simple, intuitive ideas and common sense reasoning!

1. We begin our simplified project by planning a purposefully simplified "Geometry Application" prototype that (to start with) only analyzes the basic properties of a circle, its location and area.  Instead of treating this as an algorithm, i.e. a sequence of operations on data, we create an "object representation" that models an abstract circle .

 

REPRESENTATION OF A CIRCLE AS AN ABSTRACT OBJECT

 
2. To visualize our project we create an object model consisting of abstract objects (Individual objects are "highly cohesive", i.e. self contained.) and their relationships (Related objects are "loosely coupled", i.e. as independent as possible).  To begin, we recognize the fact that we have to provide some way for a human user to interact with the Circle object , i.e. some mechanism to allow input to and receive output from that object.  (This is something we have to provide in EVERY software architecture.)  To handle this we do the following.
1. We define a new abstract object called UserI/O , which will be the key input/output object of our object model.
2. The UserI/O object must use a "real" version of the abstract Circle object.  (Real objects can have actual values for it's properties, e.g. radius, but abstract objects can not.)  Let's call our real circle "testCircle".  (In OOPL terminology, the creation of a real circle object is called creating an "instance" of Circle or " instantiating" Circle.)  Thus UserI/O "uses" a testCircle of "type" Circle .  By doing this we have created a "relationship" between our two abstract objects, called the "uses-a " relationship , because UserI/O "uses-a" Circle in its geometry application .  We represent this uses-a relation as an arrow showing the direction of the relationship.
   

A CONCEPTUAL "OBJECT MODEL" OF THE  FIRST DRAFT OF OUR SIMPLE GEOMETRY APPLICATION

This is equivalent to the UML class diagram introduced in MODULARIZATION OF SOFTWARE.

TPQ1: ( A TPQ is a "Thought Provoking Question" that you probably don't have enough info to answer completely.)  What is the significance of "highly cohesive" and "loosely coupled" characteristics of abstract objects?  ( Note that these fundamentally important concepts are often mentioned but seldom explained or exemplified in typical OOSD textbooks.)( Note that his is a "TPQ", an example of Tony's "thought provoking questions" rather than an "SAQ" because, if you have not had an introduction to OOSD, you will not "know" the answer to the question; however, even if you don't "know" the answer, it is good to "think" about this fundamental feature of OOPL.  I will discuss some of this in the hints and answers to this question.)

3. In the preceding abstract object model we have distinguished the two essential "members" of any abstract object, its "state" (defined, in the UML, by the object "attributes ") and its "behavior" (defined, in the UML, by the object " operations").  In order to create an abstract object we must be able to model, not only the object, but its state and behavior as well.  Note that behavior is the way that an object alters its state.
1. Note that we use only one object, testCircle , in the main program of the UserI/O object, but we could have used as many as we desire.  Each would be an "instance " of the Circle object.  However, to keep things as simple as possible (so we can focus on illustrating concepts) I have used only one real object, testCircle.
2. The <I/O components> in the state of the UserI/O object means that the details of how the input/output (I/O) is left unspecified.  These would depend on whether the UserI/Oobject was a GUI (graphical user interface), a CLI (command line interface), an audio interface (I/O by voice), etc.
4. In this model we have added some detail by specifying the "type" of the Circle object attributes , e.g. center is of type Point and radius is of type Number. (We could have defined the circle's center with coordinates x and y, but instead, realizing that the center is, in the real world, a "point" in two dimensional space, we "choose" to define center to be of type Point .)   All software development languages have several built in number types so we can choose any one of these to specify radius .  However, Point is not a built-in type.  So what do we do?  (Think about this!)   ----- You got it; create a "new type" (a developer defined type) by modeling a real world point with an abstract object called "Point "!   ( We could continue creating other objects, but we have what we need to illustrate many of the fundamentals of OOSD , so let's look at the relationships between Point and the other objects in our abstract object architecture.)

3. Now, looking at our object model , we see that Point and Circle are related two ways (See the following illustration.):
1. Circle has a Point (its center) so we relate Circle to Point with a  "has-a" relationship.  Note that the has-a relaionship is permanent , i.e. as long as the Circle object exists, its center, a Point , exists.
2. A Circle can be moved ( defined by the move(center, dx, dy) behavior where dx is the amount we move in the x direction and dy is the amount moved in the y direction); this requires the previously mentioned "uses-a" relationship, introduced, above, in section 2.B .  However, this uses-a relation is slightly different than that between UserI/O and Circle; the relationship between Circle and Point occurs because Circle's move behavior uses the Point object, i.e. to move a Circle we move its center (a Point ).   In other words, the move behavior of the object Circle uses a Point object to carry out this operation so we say Circle uses-a Point.  Note that we can't use the (permanent) has-a relationship to describe this because the relationship specified by move is only temporary , i.e. only "active" for the duration of the move operation.  (Note: It is critical that you realize that all the relationship we define are relationships between abstract objects, NOT relationships between members of that object.  In this case we say Circle uses-a Point, NOT move() uses-a Point, although conceptually this is also true)

4. Now we have a complete object model that thoroughly specifies
1. the properties of each object as well as
2. the relationships between the objects:

A CONCEPTUAL "OBJECT MODEL" OF OUR SIMPLE GEOMETRY APPLICATION

Notes: (1) Number is a built-in type , but Point is not, so Point has to be defined by the developer, as a separate, unique abstract object.  (2) The reason that Circle uses-a Point is because center, an argument of  move, is of type Point.



3. Note that both Circle and Point have move behaviors.  This is an example of the object oriented feature of "polymorphism " which allows the same name to be used for behaviors of different objects .  In other words, just as in natural language expressions, the meaning of a word depends on the context in which is is used , i.e. it is understood that moving a circle is different than moving a point.  In non-OOPL one would have to use something unnatural like "moveCircle" and "movePoint" to distinguish the different operations so that the computer would not be confused about which operation to perform.  However, in OOPL, polymorphism allows the computer to distinguish the two different " move" operations. Polymorphism is a broader subject than presented here, but this, at least, introduces this fundamental OO feature.  (Introduction of all the major features of OOSD is a primary goal of this presentation.)  For a more complete discussion of Polymorphism in OOPL see LMVII of COSC390, section 1.

1. To represent our abstract object model in a "standard" way we choose the UML (Unified Modeling Language) and represent our abstract objects with  "classes" ( THE essential OOSD construct) and refine some of our prototype specifications to conform to UML terminology.  The UML equivalent of the preceding CONCEPTUAL "OBJECT MODEL" is:

UML Class Diagram Equivalent to the Preceding Object Model Prototype Architecture for a Geometry Application

The solid line link between Circle and Point represents the  "has-a" relationship; in UML terminology this is called "association".  The dashed link between classes represents the  "uses-a" relationship; in UML terminology this is called "dependency".  Note that UserInterface uses-a Circle because the method main() contains a local variable, testCircle (not shown), that is declared to have a type Circle.

1. The UML equivalents of the concepts introduced in our Object Model include the following.
1. The UML "class" is equivalent to our abstract object.  It is normally represented by a rectangle with three subdivisions; the top contains the class name; the middle contains the attributes , and bottom contains the operations (also called "methods", especially when implemented in code) of the class.  Additional subdivisions are allowed and all but the name can be omitted for brevity. Note that the UML terms "attributes" and "operations" are what we used, all along, to specify the "members" of a class.
1. The UML attribute specifies the state of our model
2. The UML operation specifies the behavior of our model.  ( Operations become methods when implemented in an OOP language, OOPL.)
2. The UML relationship of "association" is equivalent to our "has-a" relationship; it is represented by a solid line with an arrow indicating the directionality of the relationship.  This relation between a class and the classes it "contains" is, unlike dependency (below) is a permanent relationship , i.e. the relationship holds from creation to destruction of a class. Actually, the association relationship has two special cases called aggregation and composition, but the distinction between association, aggregation, and composition is beyond the scope of this presentation.
3. The UML relationship of "dependency" is equivalent to our "uses-a" relationship.  It differs from aggregation because it is a transient relationship that exists as long as a class uses an instance of another class or "calls" other classes with it's operations/methods.  It is represented by the arrow-headed, dashed link between classes.
4. The UML relationship of " generalization"  is equivalent to the "is-a " relationship, which we introduce in the next section.  It, like aggregation, is a permanent relationship between classes .  It is represented by the triangle-headed, solid line link between classes; see the next diagram.  (We include generalization here for completeness, i.e. association, dependency, and inheritance/generalization are the primary relationships between classes; actually there is another relationship, "realization", between a class and a construct called an interface, but this is beyone the the scope of this introductory presentation.)
   

2. The "+" preceding the operations indicate  that they are "public", i.e. can be accessed from other classes.  "Public" is a category of of the UML concept of " visibility" which allows the developer to control the access to class members (attributes and operations), i.e. how they can be used by other classes. There are other categories of visibility including "private", "protected", and "package", but they are beyond the scope of this introductory presentation.

2. To extend our introduction of OOSD concepts we consider expanding our Simple Geometry Application by adding a Square class.
1. Obviously, Square, like Circle, has-a center of type Point.  In fact, if we wanted to specify the corners (for example to specify the square's orientation) we would define them as points as well.  If we look ahead to other two dimensional objects, e.g. triangle, rectangle, etc., we realize they all would have to be defined in terms of points.  OO technology allows us to avoid the redundancy (of each shape defining its own center, corners, etc.) by defining a "superclass ", and placing all the redundant properties, one time, in this class.  Then  "subclasses" can "inherit" the properties of the superclass .   In our example, 2DObject is the superclass, and  we define its center to be of type Point.
2. The OOSD relationship of "generalization" allows us to omit the declarations of the centers of Circle and Square, and, because a Circle "is a" 2DObject and Square "is a" 2DObject , we can "generalize" Circle and Square into 2DObject which means Circle and Square can both use all the public attributes and operations (methods) of 2DObject.  Thus generalization implements the "is-a" relationship between classes , e.g. circle is-a  2DObject and Square a  is-a 2DObject.  Makes sense, doesn't it? 
   
1. Note that "inheritance" is often used as a synonym for "generalization", but, actually, inheritance is a feature of OO programming languages that allows the developer to "implement" generalization (the UML term for an abstract concept) in code.  
2. Also the term "specialization" can be used instead of "generalization", but specialization is the inverse of generalization, i.e. you generalize by creating a superclass of several similar subclasses, or you specialize by creating subclasses from a single superclass.  Therefore "generalization" and "specialization" are two ways of looking at a "single" relationship, depending on whether you "start" with a subclass or a superclass.
   



Limited UML Class Diagram showing only the distinctive elements for an Expansion of Geometry Application Architecture

The triangular arrow represents the "is-a" relationship between classes; in OOPL terminology this is "inheritance"; in UML terminology it is "generalization".  Italics represent an "abstract" class that can not be made into a real object.

3. 2DObject is an "abstract' class " which means it can not be instantiated, i.e. real objects can not be created from abstract classes.  ( "Abstract", here, is used in a subtly different way than before; this can cause dangerous confusion.  Remember that classes themselves are "abstract constructs" that implement the "abstract object" concept we used in the intuitive development above.  "Abstract class" are something else.)
1. If you think about it, the term "abstract class" makes good sense because a 2DObject, by definition, is abstract, i.e. a 2D object is not a distinguishable quantity like a circle, triangle, etc.  In other words you can draw a circle or a triangle, but you can NOT draw a 2D object because it could be a circle, triangle, square, etc.
2. In the UML, abstract class names are written in italics.
4. Note that, as mentioned previously, there is a fourth relationship defined in the UML; this is "realization" which can be characterized as the "inheritance of responsibility" to define abstract (virtual) operations/methods of class-like constructs called "interfaces".  (These, however, are beyond the scope of this intuitive "introduction".)

Complete UML Class Diagram for the preceding Expansion of a Geometry Application Architecture

Note that this UML class diagram represents a "limited model", i.e. our model does not include everything about two dimensional objects.  It is important to realize any software architecture only models things that are relevant to the current task.1

4. Note that the area() operation of 2DObject is an "abstract operation ", denoted by being written in italics.  This reflects the fact that a two dimensional object can not have a well-defined area, i.e. a single formula can not be defined to calculate the area of any object.  Therefore, we declare area() to be an abstract operation of 2DObject which means that area() MUST be specifically defined by any class derive from  2DObject, i.e. area() must be defined, separately,  in both Circle and Square.   
5. On the other hand, perimeter(side[]) CAN be defined in 2DObject , i.e. it is simply the sum of the sides of the object. Similarly, move(center, dx, dy) can be defined in 2DObject. Thus, 2DObject has two regular operations (perimeter and move) and one abstract operation, area().  (Of course, since Circle doesn't really have a "perimeter", one would simply set its value equal to that of circumference(radius) for completeness.)
1. The utility of declaring perimeter(side[]) in  2DObject, instead of in Square, is not obvious in this simple architecture,  However, if you anticipate expanding this architecture to include other  polygons, e.g. triangles, rectangles, pentagons, etc. you will realize that they all have perimeters so declaring perimeter(side[]) in  2DObject avoids redundency of declaring it in all polygons; instead all polygons inherit the operation, defined once in 2DObject.
   
6. Note that if a class has at least one abstract operation it is, by definition, an abstract class, and can NOT be instantiated.  This should be intuitive because a single abstract method makes it impossible to instantiate a class (because that operation is undefined); a real object can not be created from such a class.
7. The naming of the different elements of this software architecture is another segue to the naming guidelines introduced in MODULARIZATION OF SOFTWARE.  In the above class architecture illustration, we see there are two types of operations, ones that return values via their names (like area()) and ones that pass values via their arguments (like move(center, dx, dy).  It is intuitive to add to the naming guidelines, e.g.
1. Classes should be named with nouns.  (This is the same as in MODULARIZATION OF SOFTWARE.)
2. Procedural methods, those that "do" things or pass values via arguments, e.g. move(center, dx, dy), should be named with verbs.  (This is an extension of the naming of procedures in MODULARIZATION OF SOFTWARE.)
3. Functional methods, those that return values via their name, e.g. area(), should be named with nouns.  (This is new!  Take time to think about it.  Although it is not obvious from the preceding discussion, functional operations are like variables or attributes in that they can be used as part of an expression like totalArea() = circle1.area() + circle2.area(); clearly these are "things", i.e. nouns.  If this is not clear, don't worry about it; just keep it in the back of your mind so you will recognize it when you encounter naming conventions again, in AN ABRIDGED OVERVIEW OF UML CLASS DIAGRAMS.)
   
8. ¹Virtually all software applications are limited models of a real world system that they are designed to represent, i.e. software architectures model only those aspects of the real world system that are relevant to the application.   In the example above, our model does not include everything about circles and squares, e.g. their color, orientation, etc., much less everything about all two dimensional objects (e.g. elipses, triangles, rectangles, etc.).  It is important to realize any software architecture only models things that are relevant to the current task.  (However, it is equally important to make it possible to expand or modify the model at a later time; this is a powerful facility of OOSD.)
3. Uses of UML class diagrams: The UML class diagrams are typically used, in OOSD, in four ways:
1. development (the most important, fundamental use) of language independent software architectures, i.e. drawing a schematic of the prototype architecture to be implemented in software.
2. documentation of existing OOS, to illustrate the static structure of the code.
   
3. debugging software designs, e.g. by generating, from source code, the associated UML class diagram, an comparing it to the UML prototype created during the modeling phase, and
4. analysis of code, e.g. a reader may "reverse engineer" software code by generating the equivalent UML class diagrams.  This can be done manually or, if the source code is available in digital form, by using software development tools that provide UML features.

5. SUMMARY (Critically important concepts are colored green.):

1. The object oriented paradigm has replaced the structured programming paradigm as they optimum strategy for developing modern software.  The distinction between these paradigms is presented in the COMPARISON OF THE OBJECT ORIENTED AND PROGRAMMING PARADIGMS, which shows:
1. The object oriented paradigm is based on modeling (whereas programming paradigms are based on developing algorithms)
2. The object oriented constructs are represented by UML diagrams (whereas programming constructs are represented by flowcharts, pseudocode, etc.)  The methods of the classes in OO software do implement algorithms, so the flowchart, pseudocode, etc. can be used to represent operations/methods.
   
3. Implementation of object oriented models produces software architectures (whereas implementation of algorithms produces programs)
2. The evolution of software development strategy has been away from computer oriented, big programs towards human oriented software models.
3. The fundamental construct of OO models is the intuitive idea of an "object" which is represented by the abstract software construct called a "class".  Collections of highly cohesive objects/classes are loosely coupled via relationships in software architectures which represent the software model of a real world system.
1. Classes are abstract software constructs that, when instantiated, become objects, i.g. real entities (that can be seen on the computer monitor) when the software is executed.  (In other words, software developers create classes, computer, when executing instantiated classes, create objects.)
   
2. All classes encapsulate two kinds of members:
1. attributes which specify the state of the class
2. operations which specify the behavior of the class.  ("Operation" is the UML term; when implemented in a language, operations are called "methods".)
3. The developer can control the access to encapsulated members by specifying their visibility as private, protected, package, public, or other, non standard categories.
4. Relationships between objects/classes specify the actual structure of an OO architecture, i.e. the interlinking of classes.  There are four fundamental inter-class relationships.
1. Association ( the has-a relationship) which is implemented by declaring the type of an attribute to be a class.
2. Dependency ( the uses-a relationship) which is implemented by declaring an Identifier in an operation (argument, local variable, or return type) to have a type of a class.
3. Generalization/specialization (the is-a relationship) which is implemented by declaring a class to be a subclass of a parent class using the inheritance facility of OO programming languages..
4. realization (the realizes-a relationship) which is implemented by declaring a class to be an implementation or realization of an interface. (This is beyond the scope of this presentation.)
Note that these are "inter-class" relationships, i.e. relationships between classes, NOT relationships between class members or between classes and members of other classes.
5. Polymorphism, a fundamental feature of the OO paradigm, allows (from a simplified viewpoint) a single name to be used in different contexts.  This presentation had only a very simple example (the move operation for a class Point as well as the abstract class 2DObject) of one of the many manifestations of polymorphism.
4. The only universal standard for OOSD is the Unified Modeling Language (UML).  This presentation takes the non-standard diagrams (e.g. SIMPLE GEOMETRY APPLICATION) used to intuitively develop the idea of object-oriented architectures and transforms them into UML equivalents (e.g. UML class diagram for the SIMPLE GEOMETRY APPLICATION).  It is important to remember that only class diagrams (of the thirteen different kinds of UML diagrams) were used in this presentation.
1. UML class diagrams have four basic uses:
1. to facilitate the development of language independent models of a software application,
2. to document the code of an object-oriented application,
3. to debug software designs by comparing prototype class diagrams with diagrams the represent final code, and
4. to analyze code by drawing the UML equivalent of existing code.
2. UML diagrams are language independent representations of of software architectures;  a single diagram can be used to generate code in any OOPL, e.g.  Java, C++, Smalltalk, Modula-3, Ada95, IDL, etc.  The thought provoking feature of UML diagrams is that many UML drawing applications can actually generate code from UML diagrams - in several different languages.  (Obviously, if you are only learning to "write code", then you can already be replaced by a computer software; so, instead, learn to solve problems and model real world systems in software!)
3. The OO architecture example generated in the presentation, Expansion of Geometry Application Architecture, is, in my opinion, the best example of an OO architecture possible.  It illustrates, with easily visualized examples, most of the fundamental ideas in OOSD, including all of those summarized in item 5.3, above.

1. OOSD involves the creation of software architectures of specifically related classes, not writing programs.
2. The UML (Unified Modeling Language), is an international standard for modeling in general, not just the modeling of object oriented software; in fact it can be used to represent virtually any system or activity.  It is important to remember this because, since it is used almost exclusively in association with OOSD in our curriculum, it is easy to think it is limited to OOSD.  This is totally untrue; it is not even limited to computer science!  Although it had its birth in OOSD, it can be applied to any engineering activity, any modeling activity, indeed to virtually anything that can be represented schematically.
   
1. Although complex (because of its wide range of application) the UML is really based on common sense. (Ask yourself, if I were asked to design a graphical way of illustrating OO software architectures, would I do it differently?)
2. The UML has two basic features
1. a well defined vocabulary used to describe modelling
2. an extensive set of diagrams (14 in UML 2.1), of which we discuss only one, UML class diagrams (UMLCD) which are, by far, the most important in introductory courses on OOSD.
   
3. The UML is an essential "tool" for object oriented software development (OOSD) and a critical asset for beginning computer science students.  There are many reasons for this, but two primary reasons are that the UML is
1. the only international standard for representing the terms and constructs of OOSD and
2. a language independent, platform independent way of representing OOS and its development.
4. The fact that the UML is THE international standard for representing OO software means that:
1. all OO software developers should use the UML (vocabulary and diagrams) to communicate with each other.
2. all OOSD teachers and students should use the UML vocabulary to describe OO concepts and UML diagrams, particularly class diagrams, to illustrate them - in all their communications, both written and verbal.
5. The fact that the UML is language independent means that
1. the UML user can focus on modeling without having to use an actual programming language (In fact, non-programmers can model software architectures and give them to a software developer for implementation.),
2. the computer science student can learn how to design OO software independently of a programming language (Thus, once a student is an OO designer, he/she can learn the syntax of any language, making the learning of a new OOPL very straightforward!), and
3. the software developer can design OO software that can be implemented on any platform, in any OO language; this can even be done by computers by clicking a button!
6. Education, being an imperfect human institution, will probably continue to use the word "program" as a synonym for "software" and will probably continue to refer to "object oriented programming languages", but if we do, we had better emphasize that the word "programming" has changed dramatically since it was first used to describe machine language programming.  Programming is still the primary strategy of software development when using machine language, assembly language, and procedural languages, but NOT when using OOSD.  OO software developers do program; they "program" the behavior of objects (their methods), but that is a subtask of object oriented software development.  I believe that it would be better to reserve the words "program", "procedures", "functions", etc. for describing procedural programming- however, this is not the "popular view".   In OOSD, although we do program behavior, we should use "class architectures" to describe object oriented software which "model" real world systems and reserve "algorithm", "procedure", and "method" to describe the operations/methods of a class.

To help me critique and improve this presentation, please fill in the Feedback form associated with this presentation and give it to me or to  your teacher who will forward it to me.  If you do not receive a printed copy of this feedback form at the presentation, please print  a copy and submit that.   Remember, your answers on this form will NOT affect your grade in any way, so please be frank (and thoughtful).

If you are interested in learning JavaScript, the language I recommend for novice software developers for 13 reasons , then you might try to work through the JavaScript Thread that is part of my course COSC 330.  I try, very hard, to the focus on "what you are doing (i.e. OOSD)" in my presentation that supplements an over-simplified text.