# Presentation: 609384

## Java TrainingIntroduction to UML

- Written by Jeff Smith

## What is UML? -1

- Unified Modeling Language.
- UML provides a common way to diagram classes and discuss objects.
- UML is NOT Java specific. Almost all books on OOP will use UML to show their class designs

## What is UML? -2

- Unified - UML combines the modeling methods of Booch, Rumbaugh, and Jacobson. In 1997, the Object Management Group (OMG) took official ownership of it, but Rational software corporation continues to work on it.
- UML allows programmers to communicate their ideas using class diagrams, activity diagrams, sequence diagrams, etc.
- In theory, UML allows for design decisions to be made before coding is started

## What is UML? -3

- Various UML Diagrams
- Class diagram
- Activity diagram
- Use case diagram
- Sequence diagram
- Collaboration diagram
- State Transistion diagram
- Component diagram
- Deployment diagram

## Sequence Diagrams -1

- Sequence diagrams illustrate a process which unfolds over a timed sequence
- Sequence diagrams are typically used to describe or model the following
- use cases
- subsystem interactions
- related classes
- program logic within a method
- You can tools like Together or Visio to create your diagrams

## Sequence Diagrams -2

- Sequence diagrams for use cases
- You generally add an actor (the external entity) which is "acting" on the system. For example, your actor might be an employee applying for vacation time
- Next you generally add the objects the actor will interact with
- We'll create a sample sequence diagram which models an employee requesting vacation days

## Sequence Diagrams -3

- In this diagram, we start with an Actor (the employee), and a couple of the objects he will interact with (VacationApplication and VacationRequest).

## Sequence Diagrams -4

- Next, we connect the Actor with the Objects by drawing horizontal lines with arrows. These lines represent "messages".
- The employee will create a VacationApplication object by calling it's constructor. We'll call this message "create".
- This will create a blank VacationApplication object

## Sequence Diagrams -5

- Here's what this message looks like on the sequence diagram (note that the timeline always points downward with early events on top, later events on the bottom)
- Note that when a message is received by an object (this is called **activation**), a box is created on the object's lifeline.

## Sequence Diagrams -6

- In our example, the employee interacts with the VacationApplication twice:
- first to create (and get) a vacation application
- second to submit a completed application

## Sequence Diagrams -7

- Sometimes sequence diagrams tools number the messages (e.g. 1, 2, 1.1, 1.2, etc.) to make it easier to follow the timeline

## Sequence Diagrams -8

- Once a message is received by an object, the object can send it's own message to itself or other objects.
- In our example, the VacationApplication object will send a message to itself, calling the method, isValid()

## Sequence Diagrams -9

- The isValid method validates the VacationApplication object. For example, was every required field filled out?
- If the validation is successful, the VacationApplication object creates a new VacationRequest object

## Sequence Diagrams -10

- Since the VacationRequest object comes into existence at this step in the process, we move its box down to the corresponding position in the timeline
- Horizontal arrows indicate almost instantaneous message transmittal (atomic messages)
- A slanted arrow indicates that a significant amount of time elapses between when a message is sent and received.
- Messages sent over a network, CORBA, HTTP, or RMI are denoted by slanted arrows.

## Sequence Diagrams -11

- In our example, we assume that our VacationRequest object will send a message to a VacationSchedule object (which is an EJB residing on a remote server) in order to check for scheduling conflicts
- We will use a slanted line
- Since the VacationRequest object is an EJB it probably already exists on the remote server
- Since the object didn't come into existence at this step in the process, we leave its box at the top of the timeline

## Sequence Diagrams -12

- VacationSchedule will check for conflicts (like all employees being gone on the same day)

## Sequence Diagrams -13

- It is generally assumed that a returning message from the object to the caller will exist.
- So we're not required to draw the returning arrow (although sometimes they are drawn with either a solid or dashed arrow)

## Sequence Diagrams -14

- Final diagram, with return messages

## Sequence Diagrams Summary

- Sequence diagrams are typically used to illustrate (or model) the behavior of a system over time.
- They can model the interaction of actors and objects
- They can also model high level processes which have nothing to do with OOP, classes and objects. For example,  we could model a vacation request process that is entirely paper based.
- In my opinion, "real world" sequence diagrams with many objects and messages tend to become difficult to read and are of marginal use
- Activity diagrams may be a better tool to describe these systems.

## Class Diagrams -1

- Class diagrams are probably the most commonly used UML diagram
- Class diagrams illustrate the attributes and operations of classes and their inter-relationships (such as one class extends another class, or one class implements a particular interface).
- Thus on one handy page, you can have skeletal information about several classes and how they might work together
- By creating class diagrams, you allow other programmers to quickly obtain a rough idea what the classes do without requiring them to read the source code.

## Class Diagrams -2

- Class diagrams illustrate
- Classes in a system
- The relationships that exist between classes (e.g., does one class extend another)
- The multiplicity between classes (e.g. one to many relationships)
- Attributes of classes (fields)
- Operations of classes (methods)

## Class Diagrams -3

- Generally, class diagrams are organized into 3-5 sections
- Section 1 shows the class name
- Section 2 lists the attributes
- Section 3 lists the operations
- Section 4 (optional) lists the inner classes
- Section 5 (optional) lists the "properties" returned by getter methods
- Relationships between classes are usually represented by a line with a hollow arrow
- Sometimes the public getter methods are placed in a separate section and listed as "properties" (see next slide)

## Class Diagrams -4

- The arrow in this class diagram indicates that the SQLExecutor class contains a ConnectionPool object.
- This diagram was created using Together

## Class Diagrams -5

- The **first** section contains the name, ConnectionPool
- The **second** section contains the attributes
- For example, "- driverName : String"
- This attribute is called "driverName" and it is of type String. The minus sign "-" indicates that it has **private** access (only visible to methods in this class)
- The "+" sign indicates public access (visible to other classes)
- If there isn't a plus sign or a minus sign, the access is package access (visible to all classes in the same package)
- A "#" indicates a protected attribute (visible to subclasses)

## Class Diagrams -6

- The **third** section of the UML diagram for the ConnectionPool class contains the **operations** (methods)
- Their access levels are also denoted by the same "-", "+", and "#" characters
- Note that the getDbType operation is listed twice--this is because getDbType() happens to be a static, overloaded method
- The **fourth** section of the UML diagram contains an entry for PooledConnection. PooledConnection is a private inner class (more on inner classes later on)
- The **fifth** section of the UML diagram lists the "properties" returned by public getter methods

## Class Diagrams -7

- Relationships between classes are generally denoted by various types of lines:
- Association -- a line connecting two classes indicates that the classes send messages to each other (call each other's methods)
- Aggregation -- a line connecting two classes with a hollow diamond next to the "aggregate" class. This relationship indicates that one classes ***uses*** another class (for example, an Invoice class might use a related Customer class)

## Class Diagrams -8

- Composition -- a line connecting two classes with a solid diamond next to aggregate class. Indicates that one class contains another (has a field of the other class's type). For example, a Customer class might contain (as a field) an Address class.

## Class Diagrams -9

- Dependency -- a dashed line connecting two classes indicates a weak connection between them.
- Inheritance -- a line with a triangle on the end indicates that one class extends another class. You can think of this as an "arrow" which points to the superclass (or more general, ancestor class)
- Abstract classes are distinguished by ***italics***
- Multiplicity
- 1 		= one and only one
- 0..1 	= zero or one
- M..N 	= from M to N (integers)
- *		= from zero to infinity
- 0..*	= from zero to infinity (same as *)
- 1..*	= from one to inifinity

## Class Diagrams -10

- Can you spot the
- relationships?
- 1) inheritance
- 2) Dependency
- 3) Multiplicity
- 4) Association
- 5) Abstract class
- This diagram was created using Microsoft Visio

## Class Diagrams -11

- Example 2
- The solid arrows in this
- class diagram indicates
- that the MySQLException
- and OracleException classes
**extend** the
- DatabaseException class

## Class Diagrams -12

- The name of a class should indicate what it IS, not what it does. Java class names should generally be nouns and begin with a capital letter
- Some good names for classes are:
- Customer
- WebOrder
- Employee
- ConnectionPool
- Bad names include
- OpenCustomerOrder
- PlaceAnOrder
- CreateConnection

## Class Diagrams -13

- Java field names follow the normal Java convention of starting with a lower case letter and having each "word" in the field capitalized
- Some good names are:
- firstName
- tpsReport
- emailErrorRecipients

## Class Diagrams -14

- The name of a method should indicate what it does. They should generally be verbs:
- Some good names are:
- registerCustomer()
- processOrder()
- saveCustomerConfigInfo()

## Class Diagrams -Summary

- Use class diagrams to illustrate
- The structure of the classes in a system
- The inter-relationships of those classes
- You can create class diagrams from scratch using a tool like Visio
- An alternative method is to reverse engineer your Java classes using a tool like Together (which reads the class files and generates the UML class diagram for you).

## Activity Diagrams -1

- Activity diagrams are similar to flow diagrams and can illustrate
- use cases
- program logic within a method
- program logic within a system
- You can tools like Together or Visio to create your activity diagrams

## Activity Diagrams -2

- Activity diagrams begin with a starting point denoted by a solid circle.
- The end point of an activity diagram is a solid circle with a ring around it
- Each activity (or action state) in the diagram is represented by a rounded rectangle
- Decision points are represented by diamonds

## Activity Diagrams -3

- Activity diagrams begin with a starting point denoted by a solid circle.