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

Draft!  Created 9/1/05; updated 9/6/07
ABRIDGED SIMPLIFIED, PRACTICAL
OVERVIEW OF
UML CLASS DIAGRAMS
If you are new to the UML, it might help to first read my gentle introduction to OOSD using the UML class diagrams,
 Intuitive Introduction to OOSD Using the UML.

The UML (Unified Modeling Language) is an essential "tool" for object oriented software development (OOSD) that "models" real world systems.   (In fact, the UML is NOT limited to software development; it's notations and numerous diagrams can be used to schematically represent any kind of related ideas or human activities; however, in the following presentation we focus on only one type of diagram, the class diagram, and it's application to software development.)  The ability to understand UMLCDs and develop them when designing software  are critical assets 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 2.1; however, from the beginner's point a view there is really no significant difference in "class" diagrams 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 2.1 (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.)

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. 

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 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.
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.
2. 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).  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.
3. 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.

4. 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.)
5. 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.
6. 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. The interface is a completely abstract class that contains only constants and "abstract" methods (method that contain only declarations), i.e. interfaces contain no attributes nor method definitions. They are used only to require a child class to to define a clearly specified set of operations.  This is an advanced subject, not relevant to introductory courses.  (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. 
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 subjects) There are several modern encapsulation constructs that are beyond the scope of this presentation; these include components, patterns, and frameworks.  These are irrelevant to introductory OOSD courses and will be ignored in COSC 101 AND cosc 240.
2. Relationships between encapsulation constructs include inheritance, association (with special cases aggregation and composition), and dependency.  (Note: only relationships that are distinguished in the UML are given below.)
1. Generalization specifies a child-parent or subclass-superclass relationship between two classes, where the subclass is a "subtype" of the superclass. A subclass inherits the non private members of its parent class.  Specialization is the same relationship viewed "top-down", i.e. from the perspective of the parent class; see section 1.2.C.b, above.
2. Realization is a special form of inheritance where the child class inherits the members of an interface.  Remember that interfaces can contain only constants and declarations of  "abstract" operations; see F.a.iii, above.  Therefore, the the child inherits only the "signatures" of these operations, i.e. the operation name along with its arguments.  In order to be instantiated, all these abstract operations must be defined in the child class, in other words in realization, the child class inherits the "responsibility" to define all of the operations declared in an interface.  If this is done, it is said that the class "implements" 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).  Also note that, since interfaces are an advanced subject, beyond the scope of this presentation, so is realization.)
   
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., but, because they are relatively subtle, advanced subjects, not critical to introductory courses, I will ignore them in this presentation except to preview their relationship with "association" in the following two subsections.  Note that, since aggregation and comosition are special cases of association, we can always use the word "association" for what would be more precisely called "aggregation" or "composition", in a more advanced viewpoint.
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,, instance, or exception) is declared to have a type that is a class.
   
2. An operation throws an exception.
3. An operation uses an operation from another class, e.g. float n = Math.sqrt(x).
   
4. A class can be declared as a "friend" of another class.  (A C++ feature that is not available in Java; it's rough equivaltent is the package.)
   
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.
7. 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 (although 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; these are beyond the scope of this presentation.
2. Association 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 standard 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 Java, allows access to members from classes within the package.  WARNING: the exact meaning of protected visibility is language dependent, e.g. Java and C++ have a (dangerously) subtle difference.
   
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.
See a tabulation of these specifiers in the Summary.
2. 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 (parent) and its subclass (child).  In other words inheritance is a facility, built into OOPL, that allows the developer to implement the semantic relationships of generalization and specialization.
   
1. A 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.)
2. Generalization/specialization is the most common use of inheritance; it requires that the subclass is a subtype of the superclass.    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 subtype, i.e. special case of its parent (superclass).
3. A subclass can have members that are inherited, overwritten, and new (not declared in the superclass).
4. Inheritance is implemented in code by declaring a superclass  in the class declaration, i.e. the line of code where the class is declared.  The syntax of inheritance is, of course, language dependent, i.e. Java and C++, for example, express inheritance different ways.
   
4. POLYMORPHISM means that a single name can be used in different ways in software, i.e. it allows the reuse of names.  Polymorphism has two basic two categories (that are beyond the scope of this presentation):
1.  "ad hoc" polymorphism which is distinguishable in code and therefore occurs at compile time, and
   
2. "pure" polymorphism which is NOT distinguishable in code and therefore occurs a run time, i.e. the compiler detects the context of a method call and selects the correct method.
   

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. Java, C++, 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 development applications (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 (See the simplified, practical guidelines for documenting Java Code, given in Lab 1 of COSC 390.).  In contrast to the "design UML CDs" discussed in the preceding section, "documentation CD's" should have a minimum of details.  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.  (However, keep in mind Einstein's guideline, "Things should be made as simple as possible, but no simpler.")  Therefore, one should use the UML CD to illustrate only that for which  the documentation is written.  Typically this would mean only relevant user-defined classifiers would be included (e.g. classes used from the Java API would be ingored), irrelevant relationships would be left out, etc.; in fact, in typical complex architectures only the generalization/realization hierarchy would be specified (associations and dependencies would be ignored because they "muddy the water".)  
3. analysis of code, e.g. a reader may "reverse engineer" software code by generating the equivalent UML class diagrams. (Note that this use is similar to documentation, i.e. you essentially "document" someone else's code.)  This can be done manually or, if the source code is available in digital form, by using software development tools that provide UML features, and
4. debugging software designs, e.g. by generating, form source code, the associated UML class diagram, an comparing it to the UML prototype created during the modeling phase.
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 has thirteen different types of diagrams (activity, class, collaboration, component, deployment, object, sequence, statechart, and use case) which provide complementary views of a software model. (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; .
9. 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"):
1. classes  are represented, in the UML, 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.  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, aggregation and composition, but since they are irrelevant in introductory software development they are ignored in this introductory presentation; they will be distinguished and discussed in later courses.
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.)

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 notes.

2. Classes:
1. Classes are represented, in the UML, by a solid rectangle.  The trivial form contains on the class name; these are used when it is unnecessary to specify the class members (attributes and operations).  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. An abstract class can not be instantiated, i.e. they can not be used to create real objects.  They are useful for collecting members, that are common to several classes, in a single class; the class members can then be inherited from the abstract class in all its subclasses. 
   
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. ( 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) would 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 which is a generalization (a "super class" or "supertype") of all these real objects.  (In other words a circle "is-a" TwoDimObject, and a Square "is-a" TwoDimObject, and so on, i.e. they are all "subtypes" of TwoDimObject.)   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!)
3. 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. Two 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.
1. Visibility is the UML term for a software developer's control over the access to a class's members. (See the examples in the following diagram.)
1. Public visibility is specified by the the prefix "+" in a declaration.
1. Public class members, represented by "+$", designate public attributes or operations that are associated with the class, as a whole, NOT individual instances (objects).  The "+" sign on its own designates public members associated with instances.
2. Package visibility is a new category, whose symbol, the tilde "~" has only recently been accepted as a standard.  It is not yet listed in the Rational Rose documentation, shown in Figure 2, below.
3. Protected visibility is specified by the the prefix "#" in a declaration.
4. Private, the most restricted visibility,  is specified by the prefix "-" in a declaration. 



FIG. 2: UML REPRESENTATIONS OF VISIBILITY

These illustrations were taken from Rational Rose Documentation.

2. Interfaces: The interface has two schematic representations in the UML.
1. The most common representation is a stereotyped class, i.e. a rectangle with "<<interface>>" above the interface name.  This is a nice illustration of the stereotype mechanism that allows standard UML  to be extended; a new schematic element need not be created because the class rectangle can be modified by the stereotype notation.  This is illustrated in the top of the following figure.
2. A shorthand notation for an interface is the "lollipop" shown at the bottom of the following illustration.  This only allows the specification of the interface name, which is written beside the lollipop.

FIG. 3: UML REPRESENTATIONS OF AN INTERFACE

or



3. Packages:  The package is represented by a tabbed rectangle enclosing the the package name, like a file folder.  This is sensible since a package encapsulates classes, interfaces, and other packages like a file folder holds pieces of paper.
 

FIG. 4: UML REPRESENTATION OF A PACKAGE

These illustrations were taken from Rational Rose Documentation.



4. Notes: These are not really functional encapsulation constructs; they simply provide a way to annotate the UML representation of a software architecture. 



FIG. 5: UML REPRESENTATION OF A NOTE (ANNOTATION)

These illustrations were taken from Rational Rose Documentation.

1. Relationships between the various encapsulation constructs in UML diagrams are represented by lines with various specifications for:
1. navigability,
2. multiplicity (only meaningful in association, aggregation, and , and
3. kind of relationship
2. Navigability specifies the direction of a relationship, i.e. the source and target of the relationship; this is indicated by an arrow, e.g.




3. The UML defines four fundamentally distinct kinds of structural relationships between classes:  association, dependency, generalization, and realization - and four (fundamental) relationships in all; association has two subcategories (aggregation and composition), but these are beyond the scope of this introductory presentation.   Note that the terms "has-a", "uses-a", "is-a" and "realizes-a", used below, to conceptualize relationships within UML class diagrams are "colloquialisms", i.e. although they are widely used, they are NOT part of the UML; in fact, they are not part of any "standard".
1. Association, a structural relationship between classes, is implemented by declaring an attribute to have a class as a type and is conceptualized as a "has-a" relationship between classes that represents a "whole-part" relationship.  
1. In general, an association is simply a structural relationship between pairs of classes or objects that can be uni-directional or bi-directional.  In the UML an association as a simple line between two classes; however, there are several annotations that specify navigability and multiplicity of associations.
3. The multiplicity of an association (as well as aggregation or composition) specifies the number of instances that may participate in that relationship.  Each end of a relation may have a multiplicity specified for it, e.g.
 







2. Dependency, a unidirectional relationship between classes (as well as other UML elements), is conceptualized as a "uses-a" relationship between classes that represents a represents the "user-supplier" (or "client-server") relationship.
1. Dependency means that a user class depends on some services of a supplier class, but dependency does NOT imply an internal "structural" dependency  between classes.
2. There are two basic categories of Dependency, both of which use classes in a temporary (transient) way.
1. Dependency via methods occurs when a method is "called", and that method, itself, uses another class  (as a return type, a argument type, a local variable type, or raises and exception.)
2. Dependency via instantiation occurs when a class uses-a class instance as a local variable in the  main() method.  
WARNING: Note that the dependency, like all relationships, is defined between two classes. Even though it is a specific method or instance that use-a another class, it is the class that contains that instance or method that depends on the supplier class, not just its instance or method.   For examples of the most universal forms of dependency between classes, see the fourth row of the table of the UML REPRESENTATIONS OF OO RELATIONSHIPS in the summary. 

3. "Generalization", a unidirectional relationship between classes, is conceptualized as an "is-a" relationship between classes that represents a represents the "type-subtype" relationship.  This is also referred to as "specialization" (the reverse of generalization), but since they are synonyms, "generalization" is, by far, the most commonly used for so we define this relationship as generalization.
1. Generalization and specialization are the same relationship, only the inverses of each other.
1. Generalization simply means that the relation between subclasses and superclasses (from a language independent viewpoint) are developed from the subclass to the superclass, i.e. the subclass is created first then the superclass is developed by generalizing the members of several subclasses into a single superclass.  Thus, the superclass is a "generalization" of its subclasses.   This happens, during the development of a software architecture, when classes are created which have redundant members; recognizing this, efficiency can be introduced by declaring and (if possible) defining these members, only once, in a new superclass.  Then the redundant members can be eliminated from the subclasses because they can be inherited from the superclass, and use as if they were part of the subclass definition.
2. Specialization is the semantic inverse verse of generalization, i.e. the development sequence is the reverse of generalization.  In specialization the subclass is derived from its superclass, adding complexity that distinguishes the subclass, as a subtype, of the superclass.  Thus, a subclass/subtype is a special case, or a "specialization" of its superclass.  Obviously a single superclass can have many subclasses, all of which are distinct from each other but are still subtypes of the superclass.
2. Generalization/specialization is conceptualized as the "is-a" relationship between classes or between interfaces and represents the type-subtype relationship, i.e. the subclass is-a subtype of the parent class.  This means an instance of the parent class can be used anywhere that an instance of it's subtype is used; this is formalized as the "principle of substitutability".  (Note that this is more restrictive than a parent-child relationship.  It is implemented in OO languages two ways:
1. declaring a class to be a child class or subclass of another class or
2. less commonly, by declaring an interface to be a child interface of a parent interface. (The interface construct is not available in C++, but it can be simulated as a purely abstract class, with all methods virtual)

3. Multiple generalization, in which a subclass (subtype) has multiple superclasses, is controversial. Most authorities believe this is an error prone technique and discourage its use.  In fact, although C++ has multiple inheritance, Java and Smalltalk (the "father" of OOPL) do not even provide it!
4. Generalization facilitates efficient software development several ways.  Three of the most important are due to the fact that generalization...
1. facilitates this reuse of code. Without modifying the original code, the developer can extend or modify a class in a new, unique subclass. Thus, one does not have to write redundant code; one only has to specify attributes and behavior that are completely new or redefined inherited members.
2. facilitates the efficient use of memory. Because the entire class hierarchy is available to a program, each descendant class contains only the differences between it and its immediate ancestor.
3. facilitates maintenance of programs with a minimum of side effects. If one ancestor is changed, all descendants automatically inherit the new behavior.
5. The UML representation of generalization/specialization is a solid line with a triangular arrow pointing from the "child" class to the "parent" class, e.g.

6. Generalization is implemented, via inheritance, by declaring the superclass in the class declaration, i.e. the line of code where the class is declared.
3. Realization is the newest UML relationship and is not mentioned in some texts. It ,like generalization, is implemented by declaring a parent-child relationship, but in this case the parent is an interface, and the child "implements" the interface by defining all the methods that are declared (but undefined) in the interface..  It is conceptualized as the "realizes-a" relationship between a class and an interface and represents the interface/class relationship.  ( It is not clear that realization is recognized as a distinct relationship on the same level as generalization, association, and dependency; personally, I would prefer to call realization a special case of inheritance (inheritance of declarations, not inheritance of definitions) along with generalization/specialization .)
1. The UML representation of realization is a dashed line with a triangular arrow pointing from the "implementing" class (child) to the interface, or a line ending with a small, named circle representing the interface.  For examples, see the last row of the table of the UML REPRESENTATIONS OF OO RELATIONSHIPS in the summary.
2. The following diagram illustrates realization relationships as well as associated elements and relationships.
 
2. SUMMARY:
1. Characteristic features, that distinguish, OO programming languages:
1. Encapsulation allows the developer to package everything needed to specify a classifier (modeling element) within the classifier definition.  The most common application is the encapsulation of members (attributes and operations) within classes.  In pure OOSD, everything must be encapsulated, i.e. there are no operations (functions) can be defined outside of a class.
2. Visibility allows the developer to control the access to the members of a classifier.  This typically involves declaring the attributes or operations of a class to be public, package, protected, or private.
3. Inheritance allows the developer to derive subclasses from superclasses, thus using the non private member of the superclass in the subclass.  The UML allows only those forms of inheritance (generalization, extension, and combination) that result in a subclass being a subtype of the superclass or that cause a class to realize an interface (specification).
4. Polymorphism allows the developer to use the same name in different contexts in the same software.  Polymorphism is manifested many ways including conversion/coercion of types, overriding/hiding, overloading, abstract operations, polymorphic attributes, polymorphic methods, and polymorphic classes (templates).
2. The essential constituents of the development of class architectures are:
1. Object: The word "object" does not have a consistent definition. In general, it is used to represent any real entity, i.e. "things" that can be modeled in object oriented software.  In many object oriented programming languages and in the UML it has a more restricted meaning, i.e. an object is synonymous with instance of a class.
2. Class: The class is the most fundamental construct in OOSD in that it is used to modularize software by encapsulating state (defined by attributes) and behavior (defined by operations) of objects being modeled in software.
3. Instance: An instance is a real object created, from a class, when OO software is executed by a computer.  It refers to an "instance of a class", i.e. a real manifestation of the abstract object represented by the class.
4. Member: In general, a member is an element of a classifier, i.e. something encapsulated within the classifier.  Classes encapsulate two kinds of members, attributes and operations.
1. Attributes specify the state of a class.  Each instance of a class will have unique values for each attribute.
2. Operations specify the behavior of a class. Operations is a UML term; when operations are implemented (coded in a programming language) they are called "methods".
Instance members refer to the state an behavior of each individual real object (instance).  Class members refer to the class as a whole, i.e. a class attribute has one value for the whole class.
5. Message: Messages are OO way of transmitting information between instances, e.g. invocations of an operation or method or the raising of a signal.
6. Software Architecture: A software architecture is the conceptual representation, in terms of classes, interfaces, packages, and notes of the system being modeled in software.  The software architecture replaces the concept of a program in OOS, i.e. in OOSD, developers model systems with software architectures rather than write programs that implement algorithms.
3. Comparison of UML encapsulation constructs of class diagrams:



CONSTRUCT:	ENCAPSULATES:	REPRESENTATION:	IMPLEMENTATION:	EXAMPLE:
class	attributes operations nested classes		class declaration
interface	constants operation declarations	or	interface declaration
package	classes, interfaces packages		package declaration
notes	annotations		comments


 
4. Comparison of UML visibility (access control) specifiers:



VISIBILITY SPECIFIERS ( "Access Control Modifiers")

VISIBILITY (UML symbol)	CLASSES and INTERFACES	ATTRIBUTES and METHODS
public (+)	Accessible from anywhere	Inherited by whole subclass hierarchy  Accessible from anywhere
package (~)	Accessible from classes within package	Inherited by subclass hierarchy within package Accessible from classes within package
protected (#)	N/A except for nested classes (for these see next right)	Inherited by whole subclass hierarchy  Accessible from classes within package
private (-)	N/A except for nested classes (for these see next right)	Not inherited  Not accessible outside the class


 
5. Comparison of the most basic UML relationships between encapsulation constructs of class diagrams:

RELATIONSHIP:	CONCEPT:	REPRESENTATION:	IMPLEMENTATION:	EXAMPLE:
association	has-a	etc.	attribute declaration
dependency	uses-a		operation declarations of   arguments,   local variables, or    return type
generalization/specialization	is-a		class declaration
realization	realizes-a	or	class declaration

SAQ: Summarize the essential point of this presentation in two sentences (semicolons allowed).
See the draft ONLINE ASSESSMENT  for this presentation.  It has hints and answers.  Working through this should help you "UNDERSTAND" the knowledge contained in this presentation.   "Competency" on the material covered in this document, as well, as it's two predecessors can be defined as 100% (not 99%) "understanding" of the answers to the questions in the PUBLIC COSC101 EXIT EVALUATION.

The expanded version of this document, for CS2 (COSC 201/241) and COSC 390 students can be found at:

http://faculty.frostburg.edu/cosc/htracy/UML/OverviewUMLCD.html