1. VP-UML CD 1: Reproduce the architecture in the last diagram in the Intuitive Intro, OOSD/UML.
   
2. VP-UML CD 2: Draw the UML CD given in question 44 of the PUBLIC COSC101 EXIT EVALUATION.
3. VP-UML CD 3: Draw the UML CD given in question 45 of the PUBLIC COSC101 EXIT EVALUATION.
   

I created two edited versions, "condensed" (for COSC240?) and "abridged" version (for COSC 101?) (e.g. deleted the items marked with  and in blue. these should be covered in COSC240 or COSC390/301).

Draft!  Created 6/1/02; last  9/22/06
A SIMPLIFIED, PRACTICAL OVERVIEW OF
UML CLASS DIAGRAMS

The UML (Unified Modeling Language) is an essential "tool" for object oriented software development (OOSD) that "models" real world systems 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.

1. OBJECT ORIENTED CONCEPTS
1. Essential "Constituents" of "Pure OOS"
2. Four Characteristic "Features" of OOPL
2. THE UML, THE ONLY STANDARD REPRESENTATION FOR OOSD
3. UML CLASS DIAGRAMS
1. UML Constructs for Class Diagrams
2. UML Relationships for Class Diagrams
4. SUMMARY

For a gentle introduction to OOSD using the UML class diagrams see my Intuitive Introduction to OOSD Using the UML. For a tabulated reference of UML constructs see Allen Holub's OO-Design Workshop; this is an excellent complement to the following presentations so use it frequently, comparing the descriptions and diagram examples.  For a detailed introduction to the UML, I recommend the textbook Pierre-Alain Muller, Instant UML, Wrox Press Ltd., especially for its appendices which show the implementations of UML constructs in Java, C++, IDL, Visual Basic, and SQL.  It should be noted that Muller's current text only covers version 1.1 of the UML;  version 1.5 is the most current one and version 2.0 is being finished; however, from the beginner's point a view there is really no significant difference between version 1.1 and the later versions, so Muller's text is an excellent starting point.  (Some of the following definitions were adapted from the glossary to the Object Management Group (OMG) specification of the UML, version 1.5 (unfortunately only available in PostScript or PDF formats, not HTML); in addition to the UML, it includes terms from the Meta Object Facility (MOF) and related terms from OMG standards.  Where this occurs, I designate the quoted text in pink.)

NOTE: The following is a fairly complete specification of UML class diagrams.  Consequently not every aspect need be mastered by beginners.  Students in COSC 101, COSC 200, and COSC 201 need not worry about advanced concepts; these are distinguished within the text below.  Those aspects that have been omitted, in the abridged/condensed versions of this document (for COSC 101/240/241 students), are designated, below, with a preceeding comment " Advanced subject".

1. OBJECT ORIENTED CONCEPTS

OOSD is a continuation of the trend towards making all software development more human oriented (as opposed to computer oriented). In fact, OOPL and OOSD should be viewed as a subsets of a larger concept called Object Technology (OT) which includes object oriented databases and OO software development environments. From this viewpoint, software development can be viewed as three evolutionary improvements on the basic ideas of programming.  (It is not essential for the understanding this document, but for more discussion of the evolution of OOSD, see the schematic analysis of the evolution of software developments in the introduction to Learning Module 1 for the Course COSC390, "OOSD in a Distributed Environment Using Java".)  It is only important to recognize that the essence of OOSD is modelling, i.e. software developers model real world systems with software architectures.  In this section we survey the basic concepts of OOSD and their associated basic constructs of OO software architectures using the terminology of the UML.

1.1 Essential "Constituents" of "Pure OOS":

"Constituents" is a nonstandard term that I use to designate the things that make up OOS (Object Oriented Software).  I chose the somewhat strange word simply because other, more satisfying terms, would conflict with standard terms, i.e. ones that have specific meanings in the UML (e.g. "elements", "components", "members", and "properties", all of which have specific meanings in the UML or other OOS environments). Essential "Constituents" of "Pure" OOS (These all have specific meanings and unique schematic representations in the UML.) include the following.

1. The essential word in OOSD is "model", i.e. the essence of OOSD is the modelling of real world systems in software using "objects" which interact/communicate via "messages".  This is emphasized by the fact that "modelling" is the center of "Unified Modelling Language", the UML.
   
1. Modelling, in general (beyond the scope of computer science), is a way to deal with complexity by ignoring irrelevant details of the domain. Models allow engineers to cope with systems for which it is impractical to gain first hand experience, i.e. systems that are too large, too small, too complicated, too expensive, etc. to prototype in detail.  Models allow engineers to visualize a system that does not exist.  
   
1. All engineers work with two types of entities: real-world system
   
2. Consequently a model is a limited view of the system, i.e. it represents only those aspects of the system that are relevant to the questions being asked.
3. For example, if one is only interested information about circles and squares, one might model a system of two dimensional shapes, but would omit treatment of shapes (elipses, triangles, quadralaterals, etc.) other than circles and squares.  (Of course, a versitle, forward-looking model would be easily modified to hand extensions, e.g. add triangles to the system model.)
2. According to the OMG Glossary, a model is "an abstraction of a physical system with a certain purpose".   Typically, that "purpose", in a "software" model is to supply information about the physical system it models, e.g. software is desinged to answer questions about the physical system it models.  (The domain is the actual world of the physical system.)
3. The UML contains several different types of diagrams, designed to give different "views" of the software model, i.e. each type of UML diagram represents a different perspective of the software model.   In the following presentation we focus on UML "class" diagrams that are used to represent the physical system in terms of "abstract templates for objects"; in fact, a UML class diagram has a one-to-one correspondence with the code it represents.
   
2. The word "object" has (at least) two distinct, but related, meanings:
1. In general, outside the scope of computer science, an object is any real entity.  They are specified by their state (values of properties, e.g. size, location, etc. that define them) and behavior (actions that alter their state, resize, move, etc.).  The foundation of the object-oriented programming (OOP) paradigm is that real world objects are "modelled" in software.. i.e. computer software is created by modelling real world objects .  When, in my learning material, I am referring to real world objects, I will try to use the term "real objects" to distinguish them.
1. An important aspect of the object concept is that it reflects the way humans view their world. For example, when one thinks of a ball ( an object) one knows the attributes ( size, shape, color, weight, etc.), as well as comprehends the behavior (bouncing, rolling, etc.) that it can exhibit. The attributes and behaviors are inseparable in the mind; this is reflected in OOP.
2. Anything that can be accepted in concept can be modelled as an object, e.g. a spreadsheet, database, menus or icons of a GUI, a person, a car, an idea, etc.
2. In computer science, an object is an instance of a class (See the next item.); it is a synonym of the word "instance" See item C, below.). This means that such objects are created during the execution of computer software, e.g. the window, in which you are viewing this text, is an object that is created when the browser software is run.  When, in my learning material, I am referring to computer objects, I will try to use the term "instance" to distinguish them.
WARNING: The word "object" is  probably the most inconsistently used word in OOSD!  In Tony's courses the word "object" is a very general term, i.e. ANYTHING can be considered to be an object, even outside the scope of computer science.  In many OOPL, e.g. Java and C++, "object" has a more restricted definition, i.e. that of a class instance, distinguished in section A.b, above.
3. The class is the most fundamental "construct" (building block) of OOS; it was designed to encapsulate "class members".  (See item 1.2.D, below.)  Classes should be highly cohesive (self contained) and loosely coupled (as independent as possible  See the definition of loose coupling from the "Web Services Glossary" of the W3C.).  In fact, one can say that one develops OOS by creating classes, and when the software is "implemented" (coded in an OOPL), the result is a collection of classes that modularizes the source code.   A class is analogous to an abstract "template", from which real objects called "instances" are created during the execution of the software; see the next item.  It is important to realize that classes are "abstract objects".  Real objects are created by instantiating classes.
4. Instances are real computer objects resulting from the execution of software.  They are created by instantiating a class, i.e. creating a unique real version of a class.  Note that software developers create classes and write instructions for the instantiation of instances, but it is the computer, during software execution, that actually creates the instances. Note that in the UML and many OOPL, instances and objects are synonymous.

5. Members: A class consists of two kinds of elements, attributes and operations, (called "members" of the class).  However, it should be noted that the developer only specifies those members that are needed to define the particular view an object necessary to completely model the task being implemented, i.e. members that are not relevant to the software model need not be declared.
1. Attributes are the class members that specify the state of an object.  There are two kinds of attributes:
1. An instance attribute has values that are unique to each instance of the class.  Taken collectively, all the values of instance attributes completely specify the current state of an instance.  An example of an instance attribute would be the radius of a circle.
2. A class attribute has only one value for all instances of that class, i.e. the same value for every instance.  An example of an class attribute would be the current number of instances of the class Circle, i.e. the number of circles that exist at a specific time during the execution of the software.
2. Operations are the class members that completely specify the behavior of the class.    When operations are implemented (coded in an OOPL) they are called "methods", i.e. "operations" is the UML term and "methods" is the equivalent term in software code.
1. There are two basic types of operations/methods:
1. mutators (ofthen called "setters") which modify the values of an attribute
2. accessors (often called "getters") which retreive the current value of an attribute.
   
2. There are two ways that operations/methods communicate:
1. Parameters are identifiers, associated with operations, which are used to pass data to and receive data from operations.  (I place a further restriction on the term, associating parameters ONLY with "procedural" operations, i.e. those that do NOT return data via the operation names.  Compare this to "arguments" in the next section.)
2. Arguments are identifiers, associated with operations, which are used to pass data to functional operations, i.e. operations that return values via the function name; functional operations can be substituted for attribures or local variables.  (This restriction on "arguments", like the restriction on "parameters" is NOT standard; you might find these terms used synonymously.)
   
6. Messages are context dependent information that is transmitted between instances, e.g. invocations (calls) of an operation or method or the raising of a signal. Events are an important subset of messages (signals) that apply to real-time interactive environments, e.g. GUIs where a mouse click would be a signal.
7. A Software Architecture specifies the static class structure of a software model.  A software architecture consists of two fundamental kinds of constructs (elements from which a software architecture is constructed), encapsulation constructs and relationships between them.
1. Encapsulation constructs:
1. A classifier is "a mechanism that describes behavioral and structural features.  "Classifier" is a generic term that includes classes, interfaces, data types, and components."  (This definition was taken from the glossary to the Object Management Group (OMG) specification of the UML, version 1.4.)  In a more general sense it is a  term that can used to refer to any encapsulation construct.
2. A class (mentioned in section 1.2.b, above) is the construct that encapsulates the attributes and operations (specifying, respectively, the _________() and __________() of all objects created from it).  Thus, it can be considered as a template for objects , i.e. an abstraction that is can be used to create as many real objects, with similar _________() and __________(), as desired.
3. ( Not available in C++) The interface is the construct that encapsulates a set of abstract operation declarations, and associated constants.   (Only the operation/method names and arguments are specified for an interface; their definition is left unspecified. The definitions must be specified in any class that implements the interface.  (Note that the interface construct is not available in all OOPL, e.g. C++; however, it can be simulated with a completely abstract class; it is available in Java)
4. The packageis the construct that is used to encapsulate related classes and interfaces.  ( Note that the package construct is not available in all OOPL, e.g. C++; it is available in Java.)
5. The note is a means of including annotations in schematic representations of software architectures, i.e. a way of adding comments to architecture diagrams.   Obviously, a note is not really an encapsulation construct like classes, interfaces, and packages, i.e. it does not encapsulate elements of a software architecture.  However, notes are essential to the effective representation of software architectures so we include it here for completeness.
6. ( Advanced subject) A component is modular, deployable, and replaceable code that encapsulates implementation which conforms to and provides the realization of a set of interfaces.  A component is typically specified by one or more coded classifiers (e.g., implementation classes) that reside on it, and may be implemented by one or more artifacts. (This definition was adapted from the glossary to the Object Management Group (OMG) specification of the UML, version 1.4.  An artifact is "a physical piece of information that is used or produced by a software development process, e.g. UML diagram, sourse code, object code (executable file), script files, etc.")
1. A "practical" definition of a component used by Jon Hopkins is, "A software component is a physical packaging of executable software with a well-defined and published interface."  This is from Component Primer, ACM, 2000.)  The article concludes, "Component-based software development represents an important stage in the maturation of the field of software engineering. It shifts the focus from new software development to the integration of existing components to perform new tasks."
2. A component typically is an implementation, i.e. software code (source, binary, or executable) but could also be a script or command file.
3. The most common examples of a component are the GUI elements (e.g. buttons, input fields, output fields, etc.) that developers can drag and drop in modern IDEs (integrated development environment where software is coded).
4. JavaBeans is the Java implementation of generic components.
7. ( Advanced subject) There are several modern encapsulation constructs that, as yet, are not available as distinct parts of OOPL.  Some, like components, are available as nonstandard extensions of languages (e.g. JavaBeans are the components of Java) but others are defined, from classes, interfaces, and packages, by developers.
1. ( Advanced subject) A collaboration is a specification of how an operation or classifier is realized by a set of classifiers and associations playing specific roles used in a specific way.  The collaboration defines an interaction.(This, somewhat arcane, definition was taken from the glossary to the Object Management Group (OMG) specification of the UML, version 1.4.)  Collaborations emphasize the messages exchanged between its objects and the associations between them.
2. ( Advanced subject) A pattern is "a template collaboration" or paramaterized collaboration with a particular name and specific domain of application.  Patterns constitute an extension of OO concepts beyond that of isolated classes to collections of classes and interfaces that work together to model a reusable software architecture.
1. from....Design pattern is a proposed solution to common design problems.... or a pattern is defined as a common solution to a recurring problem in a particular context.
2. "They are guidlines for designing classes." (I think "class architectures" is better than "classes" here.) "... abstractions you read about."
   
3. ( Advanced subject) The framework construct is "a stereotyped package that contains model elements which specify a reusable architecture for all or part of a system.  Frameworks typically include classes, interfaces, patterns or templates.  When frameworks are specialized for an application domain, they are sometimes referred to as "application frameworks." (This definition was adapted from the glossary to the Object Management Group (OMG) specification of the UML, version 1.4.)  A framework is an architectural pattern that provides an extensible template for applications  that can be "plugged into" different environments within a particular domain where it is applicable. Frameworks, like patterns, are an extension of OO technology from individual classes to reusable collections of related classifiers.
1. from...."In contrast (to patterns), frameworks are collections of reusable classes.  Often, Frameworks implement design patterns.
2. Perhaps the most practical definition is "a framework is the skeleton of an application that can be customized by an application developer".
3. Another interesting description is "an open, and often mainly abstract architecture or design that third parties can implement", from
   
4. A classic example of a framework is the Java Collection Framework, contained in the java.util package, which provides a unified architecture for creating common data structures.
   

2. Semantic Relationships between encapsulation constructs include generalization, realization, association (with special cases aggregation and composition), and dependency.  "Semantic" means that these are conceptual relationships between classifiers (classes, interfaces, packages, etc.) of an abstract model of a real world system. - NOT actual relationships specified in a programming language.   Semantic relationship are most effectively described by the "____-a" terms (uses-a, has-a, is-a, realizes-a); however, although these terms are very useful, especially for debugging the logic of your software architecture, they are nonstandard - although they are commonly used; these particular, hyphenated forms, are Tony's terminology.  (Note: only relationships that are distinguished in the UML are given below.)
1. Generalization specifies a subtype-supertype relationship between two classes, where the subclass is a "subtype" of the superclass, i.e. subclasses like Circle, Triangle, Rectangle, etc.  could have a generalization, Shape as a superclass.   A subclass inherits (can freely use) the non private members of its superclass class. 
   
1. "Specialization" is an alternate view this relationship, i.e. the subtype is a "special case" of a more general type; see section 1.2.C.b, below.
2. Generalization/specialization specifies a restricted relationship between a superclass and its subclasses where the subclasses are subtypes, i.e. they satisfy the "is-a" semantic relationship, i.e. a circle "is-a" TwoDimensionalShape.  (A more precise term would be "is-a-subtype-of", but "is-a" is distinctive enough when compared to other semantic relationships, realizes-a, has-a, and uses-a.) This restricted form of inheritance (generalization) conforms to the "principle of substitutability" which means instances of subclass can be substituted for instances of a superclass, i.e. superclass operations will work with instances of a subclass.
3. Generalization is sometimes MISLEADINGLY called "inheritance", but, in fact, the OO concept of generalization is implemented using inheritance, a facility of OO programming languages.  Inheritance is not restricted to type-subtype relationship, i.e. it can be used to implement any superclass-subclass, although this is discouraged, if not forbidden by accomplished OO software developers.  Be careful with the distinction between "generalization" and "inheritance"; most people simply use "inheritance" - as long as they only use inheritance to implement type-subtype relationships, their is no problem, but some texts use inheritance to derive a class Circle from a superclass Point and complicate this semantic nonsense by deriving a class Cylinder from the class Circle.  Common sense proves that a Cyliner is not a "type" of Circle; moreover, a "Circle" is not a type of Point!!  This subtle "pitfall" is discussed forther in Object Oriented Analysis of the Point-Circle Relationship { post an online version!}
   
2. Realizationis another special form of inheritance where the child class inherits the declaration of a class or interface operation, but not its definition.  This means that the the child inherits only the "signature" of an operation, i.e. the operation name along with its arguments.  This relationship is mainly used between an interface and a class that "implements" that interface. i.e. the developer is required to define all the operations declared in the interface.  ( Remember that the interface construct is not available in all OOPL, e.g. C++, so this is not relevant to C++ (although it can be simulated).) (Note: Tony would also use realization to designate the relationship between a class and a parent abstract class, i.e. a class realizes an abstract class; however, this is not specified in current UML specifications - although it is not denied either.)
3. Association is specified when an attribute is declared to have a type that is a class, i.e. a class is associated with a second class, when a class attribute has the second class as its type.  This implements the "has-a" relationship between the classes.  There are two important special cases of association, aggregation and composition.
1. Aggregation is the special form of association that specifies a whole-part relationship between the aggregate (whole) and a part, e.g. a Square (the whole) can be specified as an aggregate of four lines if the attribute Side of Square is declared to be of type Line.  Although it is not specified in the UML definition, aggregation is implemented in OO languages by declaring  an attribute type to be a reference to a class, i.e. aggregation is "has-a by reference".
2. Composition, a strong form of aggregation is conceptualized as the "has-a" relationship where the lifetimes of the whole and part are coincident, i.e. when an instance of the whole is destroyed, the instance of the part is automatically destroyed.  It is implemented in OO languages by declaring  an attribute type to actually contain the class which is its type.  Although it is not specified in the UML definition, composition is often distinguished from aggregation (See the previous item.) because the attribute declaration is by value, e.g. composition is "has-a by value" (possible in C++ but NOT Java) or a nested class.
4. Dependency between
   
1. classes is specified when a class method depends on another class; this implements the "uses-a" relationship between classes, implying that one class uses another in a transient way (i.e. only for a short time, unlike the permanent has-a relationship).  There are two ways this can occur:
1. An operation identifier (argument, local variable, return type, instance, or exception) is declared to have a type that is a class.
   
2. A class can be declared as a "friend" of another class.
2. packages is specified when a classifier in one packages depends on a classifier in another package; this implements the "uses-a" relationship between packages, implying that one package uses another.
4. Naming Guidelines: The naming of the different constructs of a software architecture was discussed in AN INTUITIVE INTRODUCTION TO OBJECT ORIENTED SOFTWARE DEVELOPMENT USING THE UML.  Those are reworded below with the addition of a naming guideline for interfaces.
1. Nouns should be used for:
1. Classes (including abstract classes).
   
2. Functional methods, those that return values via their name.  Functions (in structured programming) and functional methods (in OOS), are like variables/attributes in that values are associated with their names; therefore, they are always part of an expression or method argument.
3. (perhaps) interfaces;
   
2. Verbs should be used for:
1. Procedural methods, those that "do" things or pass values via arguments.  Procedures (in structured programming) and procedural methods (in OOS), are stand-alone expressions; therefore, they, unlike functions, can not be part of an expression or argument - they must be a separate expression themselves.
3. Adjectives should be used for
   
1. Interfaces.  (NOTE: interfaces are sometimes named with nouns, but interfaces do NOT represent objects (things); instead they are modifications of objects.)

1.2 Four Characteristic Features of OOPL:

The four features that really distinguish the OO approach to software development are encapsulation, visibility (access control), inheritance, and polymorphism.  (Some authorities do not distinguish encapsulation and visibility, i.e. they include visibility as part of encapsulation, but I believe it is better to separate them because they are distinct (but related) concepts.)  Several languages provide only encapsulation and visibility; these are typically called "object based" languages, so it is really inheritance and polymorphism that distinguish "object oriented" languages.

1. Encapsulation ensures that everything needed to define a software architecture is "packaged" within "classifiers" (See section 1.1.A.f, above.).  In particular, the primary classifier is the "class", the most fundamental construct of OOS; the class encapsulates the attributes that specify the current state of the object and operations/methods that define the behavior of the class.  The class is an abstract specification of everything needed to define the object being modeled; however, it should be remembered that a class typically models only a "limited world", i.e. properties that are not relevant to the model are ignored, e.g. colors would be omitted in a "black and white" world.
1. A class should be "highly cohesive", i.e. it must encapsulate everything necessary to completely describe and manipulate the associated object of a model.  On the other hand, for flexibility, classes should be "loosely coupled", i.e. they are relatively independent of other classes, including ONLY those members required to model the associated object.   This loose coupling allows the internal details of other classes to be changed without affecting related classes.  For example, input and output are absolutely irrelevant to processing, therefore different I/O mechanism (GUI, CLI, audio UI, etc) could be plugged into a software architecture without altering any of the other classes.  All the designer needs to do is carefully define how data is passed back and forth between all classes.
   
2. Encapsulation incorporates two inter-class relationships, association and dependency, implemented by declaring something within the class (attribute, operation argument, operation return type, or operation local variable) to have a type that is defined by another class.
1. Association has two special cases, aggregation and composition which distinguish two forms of a whole-part relationship between two classes.
2. Association, aggregation, composition, and dependency, when combined with inheritance, facilitate reuse, a prime goal of OOSD, i.e. once a class has been defined then its attributes and operations can be used by any other class, thus avoiding the redundancy of writhing duplicate code;  such redundancy was characteristic of none OOPL.
Details and distinctions of these relationships are given later in this presentation.
2. Visibility (access control) facilitates control over the access to classifiers or classifier members from other classifiers (typically classes).  Visibility is an extension of encapsulation in that one has to have the ability to encapsulate members before access to them can be controlled.  Specific types of access are designated by including visibility specifiers (also called modifiers, because they modify declarations) in the declaration of classifiers or class members.  The number and characteristics of the visibility specifiers differs between languages, but all OO languages have, at least two, public and private.
1. There are four categories of visibility specified in the UML.  They are listed below in order of increasing restrictions.
1. Public visibility allows complete access and are inherited by every subclass in the class hierarchy.  This may seem trivial, but it is essential to be able to specify this explicitly.  Public access was the default in programming languages before the advent of OO technology.
2. Package visibility allows access from any classifier within a package.  However, not all languages provide the package construct so, obviously, such languages would not provide the kind of visibility; the package visibility is available in Java but not C++
3. Protected visibility can be inherited by the whole subclass hierarchy, and, in some languages like Java, allows access to members from classes within the package.
4. Private, the most restricted visibility, denies access to any classifier except from within the class itself, i.e. members are used only within the operations of the class itself.  Obviously, the privatel declarations and definitions can be modified without affecting the implementation of other modules.
See a tabulation of these specifiers in the Summary.
2. Visibility helps ensure reliability and modifiability of software by reducing unnecessary interdependencies between software modules.  This helps facilitates louse coupling (of the "highly cohesive but loosely coupled" goal) between model elements.
3. Private and protected make the internal state of an object inaccessible from outside; members can be used but not accessed directly or modified.  This is also true, to a lesser extent, for package visibility, i.e. classifier members declared with package visibility can only be accessed by classifiers within the same package.  Thus the internal declarations and definitions can be modified, by the developer, without affecting the implementation of other elements.
4. The guideline of declaring all attributes as private (unless there is a clear reason not to) emphasizes complete denial of direct access.  These attribute's values should only be accessible via public "accessor methods", defined for the class, which govern the access to attribute values.  For example,if the coordinates x and y of the class Point are declared private, computer software can not contain references to Point.x or Point.y; the values of x and y  can be retrieved (for example) by an operation getCoordinates and modified by an operation changeCoordinates that would have to be defined by the developer.
3. Inheritance is a programming language feature which allows subclasses to be related to superclasses allowing the reuse of non private superclass members in the subclass.  "Inheritance" is not a term used in the UML; instead "generalization", or its inverse, "specialization", is used to describe a more restricted relationship between the superclass and its subclasses where the subclasses are subtypes, satisfying the "is-a" semantic relationship, i.e. a circle "is-a" TwoDimensionalShape.  (A more precise term would be "is-a-subtype-of", but "is-a" is distinctive enough when compared to realizes-a, has-a, and uses-a.) This restricted form of inheritance (generalization) conforms to the "principle of substitutability" which means instances of subclass can be substituted for instances of a superclass, i.e. superclass operations will work with instances of a subclass.  In other words inheritance is a "coding facility", built into a OOPL with a syntax characteristic of that language, that allows the developer to implement the semantic relationships of generalization and specialization.  It also has other uses (some downright bad!) as explained in...
   
1. Timothy Budd, in Understanding Object-Oriented Programming with Java, identifies six "forms" of inheritance which I have classified as "valid" and "dangerous".
1.  Valid forms of inheritance require that subclasses are subtypes of the superclass, thus explicitly implementing the "is-a" or "is-a-subtype-of" relationship and, consequently can be represented by UML relationships.  There are four forms:
1. Generalization/specialization means that the a superclass is an generalization of its subclasses, or, conversely, subclasses are a special cases of their superclass.
2. Extension means that the subclass adds new functionality to the superclass, but does not change any inherited behavior.
3. Combination means multiple inheritance, available in C++ but not in most other OOPL.
4. Specification means that the superclass only declares the method (making it an abstract" or "virtual" method); it must be defined in the subclass.   This is best described as "inheritance of responsibility".  In the UML this relationship, between an interface and a class, is called "realization", which is distinct from inheritance.
2. Dangerous forms of inheritance:
1. Limitation means that a subclass restricts the use of some of the behavior inherited from a parent class.  This does not, necessarily, violate the is-a relationship, so it can be represented by generalization in the UML.
2. Construction means a subclass is not a subtype of the parent class, i.e. it violates the is-a relationship and, therefore, is not valid in a UML hierarchy.  This is generally considered bad programming to use inheritance for construction!
2. Generalization/specialization is the most common form of inheritance.  The child class and its instances can use the non private members of a parent class as if they were defined within the child class.  Inherited members can be "overwritten" in the child class meaning that the inherited member is redefined in the child class.  (Of course, new members, not defined in the parent class, can be specified in the child, but this has nothing to do with inheritance.)  Generalization and specialization are two different ways of looking at the same relationship; however, from the point of view of execution, inheritance and generalization are identical.
1. Generalization implies that subclasses are created first and their redundant members are removed and placed in the superclass. Thus the parent class is a generalization of its child classes.
2. Specialization is the inverse of generalization, i.e. a subclass is "derived" from its immediate superclass thus inheriting all of the non private "members" of the superclass and its ancestors. Thus the child class (subclass) is a special case of its parent (superclass).
3. A subclass can have members that are inherited, overwritten, and new (not declared in the superclass).
4. Multiple inheritance (Budd's "combination") is the capability of an class to inherit members from more than one superclass.  This is generally considered an error prone technique; Java and Smalltalk do not provide multiple inheritance, but C++ does.
5. Interfaces implement Budd's "specification", a limited form of inheritance in which a class inherits the responsibility to define the methods declared in an interface.  The relationship between a class and its interfaces is called "realization" because the class must "realize" the abstract methods of the interface. (See section 5.C.d, below.)  There is no limitations on the number of realization relationships, e.g. Java classes can realize multiple interfaces.
6. Inheritance is implemented in code by declaring a superclass (or superclasses in the case of multiple inheritance) in the class declaration, i.e. the line of code where the class is declared. Tony uses Timothy Budd's classification of inheritance categories to augment the UML, i.e. although Budd's categories are not standard UML, they are consistent with and extend the UML, which is designed to be extensible.
4. POLYMORPHISM means that a single name can be used in different contexts in software, i.e. it allows the reuse of names.  Polymorphism has two basic two categories, "ad hoc" and "pure".
1. Ad Hoc Polymorphism occurs in coercion/conversion of variable types, redefining inherited methods, and when more than one method definition have the same name, but different signatures (different number/types of arguments).  Since these are distinguished in the source code, ad hoc polymorphism occurs at "compile time", as opposed to run time (when pure polymorphism occurs).  (See item b, below.)  These facilities were implemented in structured programming languages so they are NOT uinque to the object oriented paradigm.   Ad Hoc Polymorphism has six manifestations:
1. Coercion and conversion refer to the change of a variable type during program execution.
2. Overriding and Hiding occur when an inherited method is redefined in a derived class.
3. Overloading allows the use of the same name, within a single class, for different methods ("method overloading")  or same symbol for different operators ("operator overloading" which is available in C++ but not Java).  Overloaded methods are distinguished by having different "signatures", i.e. number and/or data types of arguments, and overloaded operators manipulate different data types.
4. Abstract operations (abstract methods) are declared in a parent class but defined in derived classes.
2. Pure Polymorphism occurs in truely generic code, that can NOT be distinguished before the code is executed; instead, the compiler identifies the current context and selects the appropriate method to invoke, a feature of OOPL called "dynamic binding".   Such generic code can be used on several different kinds of objects.  A program could include an entire set of objects, all derived from different object classes that all respond to the same message (e.g. Open), even though their methods are different.  Pure Polymorphism has three forms:
1. Polymorphic attributes allows variables to have various types (various classes).
2. Polymorphic methods have arguments of different types (different classes).  They allow the same message to be sent to different objects and have each object give a unique response defined by its class.
3. Parametric classes (also called templates) facilitate generic class definitions. The type (class) of an ADT (abstract data type) definition is left unspecified and is later instantiated when used. Parametric classes available in C++, but (currently) not in Java.
The essential compiler feature essential for polymorphism is dynamic binding (also called "late binding") allows memory to be associated with data at run time and assigned and freed dynamically while the program is running.

2. UML, THE ONLY STANDARD REPRESENTATION FOR OOSD:

The UML (Unified Modeling Language) is the only standard, language-independent way of representing OO Software.   Because it is the only international standard, it should be mastered by all computer scientists (especially teachers and students) so that they can communicate the ideas of OOSD accurately.  Because it is language-independent, it can be used to prototype and design a software architecture that can then be implemented in any OOPL.  Therefore, when you learn the UML, you can use it in any course or in the study of any OOPL, e.g. C++, Java, Ada 95, Modula 3, etc.; a single UML architecture can be implemented in any of these languages, resulting in different looking "programs" that yield the same result.   This is analogous to a single recipe being written in different languages like English, French, German, etc.; when followed, all the recipes result in the same dish.  The following is a general introduction to the UML that quickly narrows its focus to the most important part of the UML, class diagrams.

1. The concepts defined in the preceding sections are independent of any representation.  In this and subsequent sections we will specify how these generic concepts are represented using the UML (Unified Modeling Language).  However, I have been careful to use UML terminology throughout the discussion above, so all we need to do is consider how the ideas are represented with UML class diagrams.
2. The UML is the ONLY standard for representing OOS and its development process.  There are other nonstandard representation schemes, but the UML was adopted by the OMG (Object Management Group, the standards organization for OOPL) as "the" standard for OOSD in 1997. This has two important consequences.
1. All OO software developers should use the UML (vocabulary and diagrams) to communicate with each other.  Developers can use any representation when developing on their own or as part of a development team with their own "language", but when communicating with the software public everyone must use the UML to guarantee the accurate communication of ideas.
2. All computer science teachers and students should use the UML vocabulary to describe OO concepts and UML diagrams to illustrate them.  This is best way to guarantee the accurate communication of ideas to students.
3. The UML is a language independent means of representing virtually everything in OOSD.  This has three important consequences.
1. The UML user can focus on software modeling without having to use an actual programming language, i.e. software concepts rather than computer code.  Also the UML allows non-programmers to prototype software, i.e. non-programmers can draw models of software architectures and give these pictorial representations to software developers for implementation in a particular language.
2. Computer science students can learn how to design OO software independently of a programming language.   Thus, once students master UML design, they can learn any OOPL by just learning the syntax of that language because the concepts are the same in all languages.
3. A 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!  For example, some software development environments, e.g. Rational Rose, can convert a UML diagram to software automatically, i.e. clicking a button will cause Rational Rose to write the the code for a UML class diagram in C++ or in Java, etc.!
4. The UML is a metalanguage that can be used to represent every aspect of OOSD.
5. The UML is extensible, i.e. it can be augmented by other schemes to extend its range of applicability.
6. Uses of the UML: The UML is typically used, in OOSD, in four ways:
1. design of language independent software model, i.e. drawing a schematic of the prototype architecture to be modeled in software.  Note that, ultimately, the model will be implemented in a computer language; therefore, as much detail as possible should be included in "design UML CDs".  After all, you should be able to give your UML CD to a "coder", who, without knowledge of your design, can translate your UML CD into OO code in any language; in fact, we already have IDE's (e.g. VP-UML) that can translate UML CDs directly into code - obviously if you leave something out of your UML CD it can not be implemented (coded).
   
2. documentation of existing OOS.  In contrast to the "design UML CDs" discussed in the preceding section, "documentation CD's" should have a minimum of details.  (However, keep in mind Einstein's guideline, "Things should be made as simple as possible, but no simpler.")  One should use the UML CD to illustrate only that for which  the documentation is written.  The whole point of documentation is to illustrate and clarify the complexities of thousands of lines of code, so documentation "documentation CD's" should be as concise as possible.
   
3. debugging software designs, e.g. by generating, from source code, the associated UML class diagram (a form of "reverse engineering"), and 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 (e.g. VP-UML) .
7. UML Terminology:

UML terminology is THE foundation of effective communication of OOSD concepts.  Many people think that the UML is only about diagrams and thus miss the critically important fact that, even if you don't use UML diagrams, you MUST use standard terminology - the UML is the ONLY accepted standard!.  (I have been using standard UML terms throughout this presentation so all the preceding terms are UML terms and all new concepts, introduced below, are defined with UML terms.)  Important UML terms that have not been given above include the following.
1.  A stereotype is an extension of the vocabulary of the UML, which allows you to create new kinds of building blocks that are derived from existing ones but that are specific to your problem. (Definition from The UML User Guide.) Stereotypes are designated by names enclosed within double angle brackets, <<stereotype name>>, e.g. <<Tony's new construct>>.
2. A constraint is an extension of the semantics of the UML, which allows new rules to be added or to modify existing rules.
8. UML 1.4 has nine different types of diagrams (activity, class, collaboration, component, deployment, object, sequence, state, and use case) which provide complementary views of a software model - I like to call them "different windows thru which to view OO software from different perspectives".  (Only Class Diagrams, the essential tool for all OOS development and documentation, are covered in this presentation.)  The documentation of the UML, version 1.4, by the OMG, (Direct quotes from this is shown in pink italics.) specifies the following organization; .  I have included links to  Holub's summaries of some types of diagrams, from Allen Holub's UML Quick Reference, but  only use these to gain an overall perspective of the UML; don't let this distract you from the focus on class diagrams, the only essential tool for COSC core courses.  (UML 2.0 has 13 different diagrams; it incorporates all the UML 1.4 diagrams.  However, since we are only using class diagrams, I will not discuss UML 2.0 here; for a brief overview of this new specification, with illustrations see the UML NOTATION SUPPORT from VP-UML's online documentation.)  The nine UML 1.4 diagrams may be classified as follows:
   
1. User view illustrates how the user interacts with the software.
1. Usecase diagrams illustrate "actors" (representing the user), "use-cases" (representing what the user can ask the software to do), and interactions, represented by relationships, similar to (but not really equivalent to) those in class diagrams.  A use-case concept is designed from the user (not developer) point of view; it is a way the developer can prototype a users interaction with the software and, also, a way for the developer and client can communicate with each other during the design phase of software developemrnt.
2. The use cases represent functionality of a system or a classifier, like a subsystem or a class, as manifested to external interactors with the system or the classifier.
2. Structural views illustrate static organization of software.
1. Class Diagrams, which display the static architecture of software, represent the static structure in terms of classes and relationships."
2. Object diagramsrepresent the instantiated class diagrams, i.e. real objects and their interrelationships that result form the execution of software.  Class diagrams represent an abstract world, but object diagrams represent the real world.  Object diagrams "correspond to simplified collaboration diagrams" (See the next section.) "that do not represent message broadcasts."
3. Behavioral views illustrate the dynamic characteristics of software.
1. Statechart diagrams "represent the behavior of a class in terms of states."
2. Activity diagrams represent "the behavior of an operation as a set of actions."  (Note that, to my utter astonishment, there is no modern equivalent of flowcharts in the UML; I think they are essential to display the language independent logic of operation algorithms, and better than Activity diagrams!  (Perhaps, the UML designers assumed developers would continue to use standard flowcharts since they still compatible with the UML.)  Anyway, I use my own (Tony-specific) SACs (structured algorithm charts) that are based on a modern (but not widely used) form of flowcharting called "structured flowcharting".)
3. Interaction views:
1. Collaboration diagrams "are a spatial representation of objects, links, and interactions." (Collaboration diagrams are called "communication diagrams" in the UML 2.0.)
   
2. Sequence diagrams "are a temporal representation of objects and their interactions."
4. Implementation views illustrate the distinct physical components (actual code) of software.
1. Component diagrams represent physical parts of an application.
5. Environment views illustrate the "complete" system, i.e. how the separate components are integrated together.   "Useful primarily for marketing presentations, executive summaries, and pointy-haired bosses."
1. Deployment diagrams represent the placement of software components on particular hardware systems.
"Although other names are sometimes given to these diagrams, this list constitutes the canonical diagram names. These diagrams provide multiple perspectives of the system under analysis or development. The underlying model integrates these perspectives so that a self-consistent system can be analyzed and built. These diagrams, along with supporting documentation, are the primary artifacts that a modeler sees, although the UML and supporting tools will provide for a number of derivative views."

DIFFERENT "VIEWS" OF THE UML 1.4 DIAGRAMS FIGURE 5-8, UML IN A NUTSHELL

This is an memorable way to represent the different kinds of UML diagrams, i.e. the 5-compartment "picture" is easy to remember, and it helps you to recall the types of diagrams.

UML DIAGRAMS REPRESENTED IN THE UML, VERSION 1.4 (from p. 66 in Instant UML)

This is an interesting way to represent the different kinds of UML diagrams with a UML diagram.  Each type of diagram "is-a" Diagram.  This also illustrates how the UML is a "metalanguage", i.e. a language that can represent languages, in this case it represents itself!

SAQ 10: Use the UML, as a meta language, to describe UML "relationships", i.e. draw a diagram with "relationships" related to generalization, realization, association, aggregation, composition, and dependency.

1. UML Class diagrams are presented completely in section 3, below, but are summarized here to give a global perspective.  UML class diagrams include representations for:
1. encapsulation constructs (in the UML, called "classifiers" or diagram "elements" or "modelling elements"):
1. UML classes  are represented by a solid rectangle with compartments for the class name, attributes, and operations.  The visibility of class members are designated by prefixes, private (-), public (+), protected (#), private derived (/-), and public class (+$).  The type and initial value of attributes may be specified, and the arguments and return types of operations may be specified.
2. Interfaces, which encapsulate method declarations, are represented, in the UML, by either:
1. class rectangles with the <<interface>> stereotype written above the interface name in the upper (name) compartment.
2. a circle with the interface name as an annotation.
3. Packages, which encapsulate related classes, are represented, in the UML, by a rectangle with a tab at the upper left.  This looks like a file folder which is a nice analogy, i.e. packages contain classes like folders contain papers.
4. Documentation, which encapsulate descriptive annotations, are represented by rectangles with the upper right corner "folded down".
2. relationships between encapsulation constructs.  Actually, as mentioned before, these are UML constructs that implement the "semantic relationships" (logical connections) between classifiers.  All UML relationships are specified by a line between two diagram elements.  Directionality can be indicated by an arrow.  The type of relationship is designated using a solid line or dashed line and by including a symbol the end of the line.  Class diagram relationships include:
1. association which is specified by a solid line.  Association has two special cases (distinguished in section 1.2.F.b.ii, above):
1. aggregation  which is specified by a white diamond at the "part" end of a whole-part relationship.
2. composition which is specified by a black diamond at the "part" end of a whole-part relationship.
See the illustration of aggregation and composition, below.
2. dependency which is specified by a dashed, arrow headed line,
3. generalization/inheritance which is specified by a triangle headed solid line, and
4. realization  which is specified by a triangle headed dashed line.
(See the Comparison of UML relationships in the summary of this document.)
(Note that object diagrams are basically the same as class diagrams except the rectangles represent objects (real quantities) rather than classes (abstract quantities); the representations are distinguished from classes by underlining the object name.)

3.1 Encapsulation Constructs in UML Class Diagrams:

In the UML, encapsulation constructs are called "classifiers" or diagram "elements".  They include the classes, interfaces, packages, and .

1. Classes:
1. Classes are represented, in the UML, by a solid rectangle.  There are several forms of UML classes, with varying amounts of details.
1. The trivial form contains on the class name; these are used when it is unnecessary or  counter productive  to specify the class members (attributes and operations), e.g. giving details would unnecessarily complicate the class diagram.   Typically trivial forms have  a more-complete definition elsewhere. 
   
2. Incomplete forms have, in addition to the name compartment, compartments for attributes, and operations, and (sometimes) others, like exceptions .
3. The complete form includes at least three compartments, one each for the class name, attributes, and operations.
   

FIG. 1A:  UML REPRESENTATIONS OF A CLASS (Trivial and Complete Forms)

The upper rectangle is the simplest representation of a class, where only its name is specified.  The lower rectangle is a complete representation.

2. UML class diagrams, being language independent, are developed during the the analysis and design phases of the software development.
   
1. During the object oriented analysis (OOA) phase possible classes are identified and their tentative attributes and operations are specified.  When using the UML this involves drawing incomplete UML CD with only the names of the attributes and operations are represented, i.e. types and operation algorithms are not considered.
2. During the object oriented design (OOD) phase the relationships between classes are developed.  When using the UML, this involves specifying the the types which are classes and, if relevant, drawing the classes with associations, dependencies, generalizations, and realizations represented.  There are many forms of the UML CD varying from the simple form where only types are specified to the detailed form where all related classes represented with their attributes and operations given.
   

EVOLUTION OF UML CD DURING THE ANALYSIS AND DESIGN PHASES
OOA Phase: Classes are identified and their attributes and operations are specifed
OOD Phase: Relationships to other classes are defined.  In the simple form this means only the types are given; in the detailed form, the class diagram of the types are represented.  Note that the types were not given in the detailed form, because since the relationships define these, writing them out would be redundant.	Simple form: Detailed form:

3. Varieties of classes:  The class is the most fundamental encapsulation construct in OOSD and, therefore, the essential element in UML diagrams.  However, there are special cases of the class construct, e.g. abstract classes, parametric classes, and association classes.
1. An abstract class is used to collect class members, that are common to several classes, in a single class; the class members can then be inherited from the abstract class.
1. Abstract quantities are distinguished, in the UML, by italicized text.
1. Abstract classes are represented, in the UML, by writing the class name in italics.
2. The abstract operations of an abstract class are distinguished by writing the operation name, its argument, and return type in italics.  (Abstract classes must contain at least one abstract operation, i.e. one that has a name and arguments, but one whose algorithm is undefined.)
Thus the UML diagram of abstract classes look exactly the same as normal classes, except the class names and abstract operations are italicized.
2. Inheriting class members of abstract classes implements the specification form of inheritance.
( Be careful with the concept of abstract classes; there are subtle points that can be confusing to beginners.  Note that a  class is, itself, an abstract concept, i.e. a "template" for real objects (instances of the class).  So what is an "abstract class", an abstraction of an an abstract concept?  Well, ... yes.  The key distinction is that classes can be instantiated, i.e. real objects can be created when the software is executed.  On the other hand, abstract classes can NOT be instantiated, i.e. they really represent abstract concepts.  For example, one could define the class Circle which could be instantiated as a real circle with a radius, for example, of one centimeter; such a real object (the circle) could appear on your computer screen.  However, a circle, like a rectangle, triangle, etc., is, in general, a "two dimensional object" so we could define an abstract class called TwoDimObject from which we could derive, using inheritance, all these real objects.  (In other words a circle "is-a" TwoDimObject, and a Square "is-a" TwoDimObject, and so on.)  However, the TwoDimObject class can NOT be instantiated because it represents a truly abstract concept. Why bother with such subtle points?  The reason is that abstract classes are a powerful tool for reuse, one of the primary goals of OOSD.  One can define attributes and operations once, in an abstract class and then inherit them in all the subclasses of that abstract class; the more subclasses, the more redundancy can be avoided.  For example, the center of a two dimensional object can be declared in the abstract class TwoDimObject and inherited in classes Circle, Triangle, Rectangle, etc.  Hmmmm... Obviously, the similarities and distinctions of classes and abstract classes are worth careful consideration!)
2. ( Advanced subject) Parametric classes (also called templates) facilitate generic class definitions. The type of members used in the parametric class can be left unspecified; they are instantiated when the class actually used.  For example, when defining a data structure, the kind of data it contains is left unspecified and is defined, later, when the parametric class is used (instantiated).  This allows developers to define a single class, for example a Stack , that can be instantiated with different types, e.g. a stack of integers, or a stack of characters, or as stack of arrays, etc.
1. Parametric classes are represented in the UML with a rectangle that has a dash sided rectangle superimposed on its upper right corner.  The formal arguments of the parametric class are given in this dash sided rectangle.  See the upper diagram in the following illustration.
2. A class that is instantiated from a parametric class has the class name followed by its actual arguments enclosed within angle brackets.  See the lower diagram in the following illustration

FIG. 1B: UML REPRESENTATION: PARAMETRIC CLASS (TEMPLATE) & INSTANTIATED PARAMETRIC CLASS

These illustrations were taken from Rational Rose Documentation.

3. ( Advanced subject) Association classes are UML modeling elements that have both association and class properties.  They can be viewed as class that has the properties of an association or and association that has the properties of a class.
   

FIG. 1C: UML REPRESENTATION: ASSOCIATION CLASS

These illustrations were taken from Rational Rose Documentation.

4. Members of classes are listed in separate compartments of the class rectangle; attributes are listed in the second compartment (from the top) and operations/methods are listed in the third.
1. Various levels of detail are allowed in member representation:
1. Attributes can be listed by name only or the type can be appended following a ":"; an optional initial value can also be appended following a "=".  (See Fig. 1A, above.)
2. Operations (methods) can be listed by name only or the argument list can be inclosed within parentheses; if the method returns a value its type is be appended following a ":".  (See Fig. 1A, above.)
2. Three categories of members can be distinguished.
1. Instance members represent the state and behavior of class instances.  These are, by far, the most common members, so they not distinguished by a special symbol.
2. Class members (as opposed to instance members) belong to the class as a whole, not an instance, therefore at any time, there is only one value or one message associated with the execution of an application.  Class members are designated by prefixing the "$" symbol to the UML declaration; see the next diagram.
3. Derived members( New terminlolgy, not well documented