Home / Summaries / Ocup Certification Guide Uml 2.5 Foundational Exam; Preparing for the Ocup 2 / structure-abstract-book

Study Cards on structure, abstract, book

Q: We consider the nonitalic named classes as ...?

We consider the nonitalic named classes as concrete. A concrete class can have instances (objects) created of the Class , but abstract classes cannot have direct instances

You can use Generalization / Specialization in which diagrams?

Generalization/Specialization can be used between Classes and also between Use Cases.

How can we read this diagram?

We might read the top relationships of this diagram as:

A Structure Diagram IS A Diagram or

A Structure Diagram is a KIND OF (or SORT OF) Diagram or

A Structure Diagram is a specialization of a Diagram or

A Diagram is a generalization of Structure Diagram and Behavior Diagram or

Structure Diagrams and Behavior Diagrams are CHILDREN of Diagram or

A Diagram is a PARENT of Structure Diagram and Behavior Diagram

The specialization relationship allows a ..... To Substitute for the .....

The specialization relationship allows a SUBCLASS (the bottom end) to SUBSTITUTE for the SUPERCLASS (the end with the arrowhead).

How do we draw the generalization?

We normally draw the generalization triangle pointing up and have all the subclasses sharing the same triangle in a tree-like shape.

However, you can have each subclass use its own triangle, and the direction can be in any orientation, subject to considerations on readability.

Read the diagram

In Fig. 10.29, we show an example of how inheritance works.

The features of the superclass Borrowable Material (title, callNo, and borrow()) are available on all the subclasses.

In Audio CD and Book, the two attributes (title and callNo) are repeated.

UML recommends using the caret (^) to precede inherited features to distinguish them from features that are native to the class.

We do not have to show an inherited feature at all.

For example:
we did not repeat borrow() on Audio Cd or Book, but it is there.

On Book, we also added another property, that of author:Person.

How do we show that this is a inherited feature?

We show that this feature is also inherited in Juvenile Book by showing ^author:Person.

We show that this feature is inherited in Adult Book by showing ^author:Person on the end of the association.

As previously discussed, we did not have to show these as the association would be inherited naturally.

We also added new attribute and operations on the Book subclasses.

Also, note that the role name at the Book end and the Adult Book end is not inherited. These are properties of Person.

How does it work when a feature is requested?

When a feature is requested on a subclass, the definition of the feature is retrieved.

If it cannot be found in the current subclass, the chain of superclasses above the subclass is examined to find the closest definition.

When the closest definition is the found, it is retrieved and used.

The UML specification does not explain what happens if the definition is never found as that is an implementation/language concern.

We consider the classes with italic names as ...?

We consider the classes with italic names as abstract.

Equivalently, we can use an {abstract} flag before or after the class name

We consider the nonitalic named classes as ...?

We consider the nonitalic named classes as concrete.

A concrete class can have instances (objects) created of the Class, but abstract classes cannot have direct instances

What is an abstract operation?

An abstract operation is an operation with a defined argument list, but no implementation defined, that is, the mechanism for performing the operation’s work is not available.

If a class has an abstract operation, then the class must also be abstract.

At the very bottom of an inheritance hierarchy, all the classes must be ...?

At the very bottom of an inheritance hierarchy, all the classes must be concrete.

They must be able to have instances, and all their operations must have a method supplied.

One common modeling idiom that also illustrates the power of combing composition with generalization allows for parsing of structures, see Fig. 10.30.

What do we see in this figure?

In that figure, we show two types of Structures, Simple, or Compound.

A Compound Structure has many Structures as parts, which can be either Simple or Compound.

If we make the Structure represent a Mathematical Expressions, we can depict how expressions are built from subexpressions.

This pattern could also represent clauses in English Sentences, or Parts in a Mechanical Assembly.

What else can we see about the Structure class?

We made the Structure class an abstract class (in italics) because all structures must be either a Simple Structure or Compound Structure.

No structure can exist that is not resolved to be one of the subclasses.

In such circumstances, the Generalization/Specialization is considered “complete” or “covering.” It is common in such circumstances to make the superclass abstract.

Imagine you had a simple pet license that would handle dogs and cats.

If somehow the political powers force you to allow Tiger licenses, you can ...?

If somehow the political powers force you to allow Tiger licenses, you can create a Tiger as a subclass of Cat, and then you could handle the Tiger license.

You will probably need a separate method on the Tiger to enforce whatever safety rules a Tiger license requires.

However, other than the new method on Tiger, you would probably not have to change Cat, Dog, or any other class.