An Introduction to UML and Collections by oxu11283

VIEWS: 0 PAGES: 4

									CSC 133 Fundamentals of Programming II Lab "                                                 January 12, 2010


An Introduction to UML and Collections

There is really no good way to describe this lab except that I want to give you more instruction on UML
models and I also want to introduce you to the concept of Collections. These seemingly unrelated
technologies will be critical as we progress down the path in search of the “deeper meaning” of the object
oriented programming paradigm. [NB: Isnʼt that great--an almost Zen-like “mystery”. And itʼs only the first
week!]

First, lets explore UML a bit. We wonʼt get too deep into all of the nuances, but it will be very convenient
to have enough mastery that we can use UML to describe object interfaces.

A UML class model is comprised of class diagrams (basically, partitioned boxes) and specialized arcs
(arrows, lines, etc.) that are used to express architectural relationships among the diagrammed classes.
We will keep things simple for now, adding to our building blocks and becoming more sophisticated as we
move through the semester.

A class diagram is a box partitioned into three horizontal segments. For now, the top segment contains
the name of the class being described, the middle segment documents the attributes of the class and the
lowest segment documents the signatures (names, arguments, and return types) of methods. Attributes
and method signatures optionally are prefixed by “tags” that provide privacy and scoping information.




It is probably useful to understand that a UML class diagram doesnʼt necessarily show all of the attributes
or all of the methods of an object class. In particular, often only the public interface of the object is shown
(those attributes and methods that are either public or inheritable). As you become more experienced
expressing object oriented programs using UML models, you will probably begin to leave out details that
arenʼt important to the “end user” of instances of the class; for now, it is a good idea to try to be thorough,
until you are able to decide what is or is not important.

Consider the following simple Java class description. [NB: One of the important facets of UML is that
UML models are not dependent upon a specific language such as Java or C++. UML models described
object oriented systems and their components. Which language is eventually used to realize the model is
irrelevant. This leads us to an important idea: we program with UML (and other types of models), and only
after the programming is done, should our attention turn to a realization of the program in some language.
Anyway, returning to the example...]

public class BankAccount {
    private String accountHolderName;
    private int balance;!     // in cents

     private int getBalance() { ... }

     public String getAccountHolderName() { ... }
     public double balanceInquiry() { ... }
     public void deposit (double credit) { ... }
}



"                                                                                                              1/4
CSC 133 Fundamentals of Programming II Lab "                                                  January 12, 2010


Of course, this class definition is incomplete: there is no constructor (not necessarily a problem, but there
is no way specified to set the account holder name, either). Also, I have used ellipses “...” to stand in for
the methodsʼ implementation details.

Below is a UML diagram for this class.




Letʼs take a closer look at this diagram. The name of the class is BankAccount. That part is pretty clear.

The middle segment documents the attributes, accountHolderName and balance. The type of those
attributes (reference to a String and int, respectively) follow the attribute name. This is one of the
important ways in which UML differs from the Java syntax: the type follows the name. Donʼt complain
about it--just deal with it.

The final segment documents the method signatures. If you just look at it for a moment, you should
understand the translation from the Java realization to the model. [NB: Of course, you ought to be going
the other way: models to realizations.] Remember: types follow names. Note that deposit, being a void
method, has no type. A constructor would be the same.

Regarding the tags, ʻ-ʼ means private, ʻ+ʼ means public. If you need it, protected is ʻ#ʼ. Use italics to
indicate static attributes or methods. For example

"       + main (args : String[])

If you are creating a model by hand (drawing), then

"       + /main/ (args : String[])

will convey “static”, since most of us are pretty terrible about writing italic fonts. [Actually, most of us are
pretty poor with any hand-written font! I had a marvelous student once who had spent a great deal of time
and practice developing a suite of fonts, including several sans-serif fonts, italics, bold, etc. He can shift
as fast as he can print. His work was so beautiful, nobody wanted to erase it from the boards--really.]

    Modify the UML class diagram for the BankAccount class by adding a representation for the following
    methods:

"       public double withdraw (double debit)
"       private void setAccountHolderName (String name)
"       public BankAccount (String accountHolderName)

How are these methods supposed to be implemented? That is one of the “drawbacks” to UML: the
diagrams donʼt tell us anything about the implementation of specific methods. But then, that is not the
purpose of the diagrams. We use UML to describe the public interfaces and the relationships among
classes, but not the implementation of individual methods. [NB: We have other models that do help us


"                                                                                                            2/4
CSC 133 Fundamentals of Programming II Lab "                                                January 12, 2010


with method implementation models. You learned about flowcharts last semester. There are other UML
models too: collaboration and sequence models. Also, State and requirements models... We will learn
about some of these as the semester moves along.]

Two object class can be related in one (or more) of four ways, using basic UML structures. The four basic
relations are illustrated and described below. In these pictures, we use “abbreviated” UML class diagrams
that show only the class names. Donʼt get lazy: always show the important details! I am abbreviating here
for purposes of brevity.
From the left...




“Is A” (the Java “extends” inheritance). The Subclass “is a” specialization of the Superclass. That is, all of
the public and protected methods (and attributes) of the Superclass are “visible” to methods of the
Subclass. We will make sure you have these notions nailed down in the next week or so.

“Does” (the Java “implements” concept). The Implementor implements all of the methods of the Interface.
An interface is set of related method signatures that must be implemented by the implementing class. We
will be using this concept a great deal as this semester rolls forward.

“Has A” means that the Container class includes one or more references to instances of the Component
class among its attributes, or in a Collection. We will talk about this a lot more. But, for example, in the
BankAccount example, it would be strictly correct to show




since a BankAccount “has a” reference to a String object instance as an attribute (accountHolderName).
In practice, it is not typical to document “has a” relationships for common objects (String, StringBuffer,
Integer, etc.) since the behavior of such common objects is “well understood”. Remember: documentation
is valuable when it adds to the understanding of the thing being documented.

“Depends on” means that the Using Class “depends on” the public interface of the Used Class.
Specifically, “depends on” means that if the Used Class changes its public interface, then the Using Class



"                                                                                                           3/4
CSC 133 Fundamentals of Programming II Lab "                                                 January 12, 2010


methodsʼ implementations will need to be changed. Once again, we donʼt usually show “trivial”
dependencies, such as dependencies on String, for example.

    “Depends on” relationships are directly tied to the concept of encapsulation that we discussed in class
    today. Describe the impact of good (or bad) encapsulation on a design with many “depends on”
    relationships among the objects.

We can use these relationships to describe fairly sophisticated relationships among objects. The following
UML is a fairly simple description of one of the first design patterns that we will discuss: the Observer.
Interpretation: The Observer has a Collection of Listener instances (listeners), in this case, implemented
by the class Client. The Observer has methods addListener and removeListener. Although UML canʼt tell




us this, the convention is that these methods are used to add and remove instances of Listener to and
from the Collection. Finally, if the Listener method somethingHappened changes, then the Observer will
need to alter one or more of its methodsʼ implementations.

    Detail everything that is described directly or that you can infer from the UML model above. I know
    you donʼt have the experience to do a complete job, here, but give it your best shot.

If you donʼt understand all of this, thatʼs fine. I am just trying to show you how powerful the UML modelsʼ
descriptions can be. You will get used to these--and to various design patterns--as the semester rolls
forward. For now, just trust me. Eventually, we will be using UML diagrams and just a few words of text in
order to describe complex systems of objects--and you will understand them well enough to provide a
realization!




To complete this lab, do the work required by the check boxes and turn in your assignment in class on
Wednesday.




Part Two: Introduction to Collections... This part will be a “lecture” that will set up for a programming
assignment next week. Donʼt miss lab!




"                                                                                                           4/4

								
To top