This resource page is designed to provide an overview of the Unified Modeling Language (UML) notation used in the AITP NCC Java Competition Event. All of the Java event problem statements are documented using TogetherSoft TogetherJ, Rational Rose, and the UML version 1.3/2.0 notation. The Object Management Group (OMG) is currently working to finalize UML version 2.0. This tutorial is going to focus on UML notation basics, which will conform to all versions of UML (from 1.3 through 2.0). This tutorial is divided into five parts:
This tutorial is intended as an introduction to basic UML. You are encouraged to explore the Problem Statement UML Documentation to gain a better understanding of how UML is used in industry as a design and modeling tool.
A Class Diagram provides an overview of a system by showing its classes and the relationships among them. Class diagrams are static - they display what interacts, but not what happens when they do interact.
The Class is represented as a rectangle that is typically divided into three regions. The top region contains the class name, the middle region contains the class attributes, and the bottom region contains the class methods (or operations). NOTE: TogetherJ adds a fourth region to the bottom that shows the class properties, which are attributes with assessor (getter) and mutator (setter) methods.
A class can have a note associated with it. Notes do not effect the underlying code.
The illustration below shows how TogetherJ represents a note and the corresponding Java source code.
A class is a template from which objects are instantiated (derived from). The act of instantiating an object from a class is similar to building a house from a blueprint. The class is a form of blueprint for building objects. Classes can be represented in a short form by using a box with no internal regions as illustrated below.
Object Diagrams show instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships. Objects are indicated by placing the name of the object (instance name) to the left of the class name and separating the two names by a colon. Object names are typically underlined in a UML diagram to visually help in distinguishing them from classes (e.g. anObject:ClassA). Examples of simplified class and object UML notation are illustrated above.
The object diagram below illustrates an example of the instances of the underlying classes that have been instantiated from the class diagram above.
The objects AITP and Auldenfire have been instantiated from the class Organization. Both of these objects share a recursive association with each other in that Auldenfire supports the AITP Java Competition Event.
The objects United States and Europe have been instantiated from the class Region and are associated with the object Auldenfire.
The objects Auldenfire
US, Auldenfire SE,
Auldenfire TX, and
Classes and objects can be associated with each other and a class may be dependent upon another class. There are four forms of association: Association, Aggregation, Composition, and Generalization.
In the example illustration below, there is a linked association between Person and Address:
In the example illustration below, there is a whole-part relationship between the Car (whole) class and the Engine (part) class. In English, this would be stated as Engine is a part of Car.
There has been considerable confusion in how Aggregation and Composition have been defined in the past and not all tools support both of these special forms of association.
In the example illustration below, there is a whole-part relationship between the Person (whole) class and the Head (part) class. In this example, removing the person also removes the head and removing the head effectively destroys the person - the person and head must exist together in the context of a living person. A Java program can be used to store attributes of the Person and Head.
Generalization is a relationship between classes that allows the sharing of properties defined within one class to be shared within subordinate classes. Generalization is used to build class hierarchies. Although it is a more abstract concept, generalization is also referred to as inheritance. The illustration below shows a concrete class inheriting from an abstract class.
Generalization (or inheritance) can consist of two types of classes:
Abstract Classes cannot be directly instantiated and are only used for specification purposes. A class is abstract if it has no instances. An abstract class is only used to inherit from. Abstract classes are represented by an italicized class name.
Concrete Classes can be directly instantiated to generate objects.
In Java, generalization is represented by the extends keyword as illustrated in the TogetherJ example below.
Interface is a mechanism used by Java to conveniently package and reuse a collection of methods (method signatures) and constants. An interface is an abstract class that only contains method signatures and can also contain constants. There is no underlying source code that defines the methods. Essentially, a Java Interface is a promise to implement a standard package of methods and constants - how the implementation is actually carried out depends on the programmer. The illustration below shows two examples of an interface.
Both abstract classes and concrete classes can implement an interface.
Interfaces provide extensibility to Java. As a side note, interfaces are an alternative to multiple inheritance, which Java does not support. Interfaces provide looser coupling, support design by composition, and provide plug-in points that allow a design to have greater flexibility.
The UML diagram and Java source code example below illustrate dependency. In this example, the Address class is associated with the Person class and Person depends on Address for providing aHomeAddress. This is an example of an asymmetric dependency.
The UML diagram and Java source code example below illustrate dependency. In this example, the Child class depends on the Parent class. A symmetric dependency does not use a directional arrowhead. This is an example of an asymmetric dependency.
Class Multiplicity notation is shown in the diagram below:
Class Cardinality is defined in the diagram below:
The illustration below shows how class cardinality and multiplicity are notated in UML and in the Java source code by TogetherJ. The arrow pointing to the Address class from the Person class indicates that Person depends on Address. This notation also indicates that the Person class has knowledge of the Address class; however, in this asymmetric dependency, Address has no knowledge of Person.
A class is divided into three regions: Name, Attributes, and Operations. Each attribute and operation, referred to as a member, is assigned a scope: Public, Protected, or Private. The scope determines the level at which a member can be accessed.
Public members can be accessed by any other class. Protected members can only be accessed by classes that belong to the same package. Private members can only be accessed by the class itself. The class Order is used as an example below:
Class Scope or Static members (attributes and operations) are underlined.
Static members are not instantiated with the object, they are available through the class itself.
Class Operations follow the form:
Access specifiers appear in front of each member (+,
#, or -).
For comments or questions, contact: Don Baldwin
|Copyright © 2001 - 2007 Aurenav LLC - e-mail: email@example.com|