What is UML?

UML is the Unified Modeling Language Unifies the OO modeling techniques of Grady Booch, Jim Rumbaugh and Ivar Jacobson (the three amigos) UML is a current standard by the OMG (Object Management Group)

Current UML revision is UML v 1.5 (2003) It is a way to express an OO design, easily communicative to others, regardless of the language UML can express systems other than computer systems UML is not a process or method: it is a modeling language OO Analysis & Design has a static view and a dynamic view A static view is one in which we view the structure of the system A dynamic view is one in which we see how the system object collaborate to solve the problem UML offers modeling for both, static and dynamic views

Elements of the UML Use Cases Class Diagrams Interaction diagrams (Collaboration and Sequence Diagrams) Packages State Diagrams Activity Diagrams

Use Cases A use case is a set of scenarios, which describe all relevant interactions of a user with the system for the purpose of achieving a users goal. A scenario is one particular sequence of events (a single thread) of a use case. An actor is a role that a user plays in interacting with the system. One user can play different roles in different use cases. Actors also may be nonhuman elements, such as other systems interacting with our own. All car buyers are one actor to a Car Dealer Buy-Car use case All web users are one actor for a Get-Stock-Quote use case

Use Cases can be either written (text) or drawn (diagram) Ex: add a course (text) 1. 2. 3. 4. 5. 6. student looks for acceptable course and fills the add form student goes to the registrar registrar verifies the date is ok, and instructor signature student pays the course add fee by credit registrar enters student in the enrollment database student receives the receipt and class confirmation

alternative #1 - At step 4, student credit card is not accepted, and a second attempt on the card proceeds alternative #2 - At step 4, an honor student has the add fee waived

Use Cases ( a set of use cases for a Chat Application )

<<generalizes>> Log Onto Chatline Banned User

Quit Chatline

Chatline Manager Send Message to SINGLE Internet Chatter Decode Chatter Message Send Control Message

<<include>>

<<include>>

<<include>>

Send Message to ALL

Start/Stop Chat Server Chatline Manager

Use Cases A use case can be extended in a controlled manner, if a base case defines explicit extension points. A use case extension can extend on one or more of these points.

Frequent Flyer

Buy Airline Tix extension points number of flights payment history senior citizen

<<extends>> (number of flights payment history)

A use case can be related to another use case in three ways: include - allows factoring common elements to two or more use cases generalization - describes variation in normal behavior extend - similar to generalization but the variation is more formal as it is tied to the extension points

1.

2. 3.

Class Diagrams Class diagrams give a static view of the structure of the system. These popular models can be used at various levels of abstraction:

1.

Conceptual - this level allows the diagrams to be used as a representation of the domain under study. Classes developed here will relate to the future software, but not in a direct way. In other words, we do not focus on software to be developed

2.

Specification - this level is focusing on the interfaces of the design, not implementation. As a key feature of OO is clear separation of the two. If an interface is a type, then a class can implement many types and a type can have many classes

3.

Implementation - at this level we detail our specification level to move closer to language implementation

The ChatServer class showing attributes and operations.

ChatServer Component which will take all incoming connections and keep communication with chat clients active. Live Connection management will be monitored
Conceptual

ChatServer receive connections manage clients enable communication

Specification

ChatServer
nameChatter : String message : String connections : Collection socketListener : Socket getNewConnection() testConnection() timeOutConnection() disconnectUser() sendData() sendPrivate() receiveData()
Implementation

Generalization-specialization is a form of inheritance. This inheritance is often referred to as isa inheritance. For example, we could say that ServerListener is a kind of a Thread.

Thread run()

ServerListener nameChatter : String message : String processRequest() run()

Aggregation and Composition show an object of class A is part of another object of class B. Aggregation is more loose while composition is tightly connected.

aggregation - Shows a clear association between classes. For, example, A course at a university may be related to a major through aggregation. It is conceptual in that it shows an existent relationship. It is an informal way We think of the part as being a part of the while.
1..* 8..*

Major

Core Class

composition - This association is a stronger than aggregation. It shows that the whole owns its parts. Copying or removing the whole takes the composed part along. We also think of the part as being a part of the while, but more tightly coupled. The multiplicity on the whole end is 1 or 0..1.
1 256

Maze

Position

Aggregation and Composition Example

Composition
{ordered}

Pixel
4 3

Square

Triangle

Aggregation

Computer

Cell Phone

H/W Components
1:* 1:*

10

Navigation in Associations The open arrowhead shows that we can navigate from a or to its core classes, but not the reverse. Navigability shows whether an object can send messages to its associated objects. Below we see that a core class has no way to send a message to its associated major.

Major

Core Class

Lack of arrows may imply no navigability or unspecified navigability. Some tighter convention can be adapted by a designer.

Major

Core Class

An association class can be created to show that the association may have both attributes and operations. Warranty is an association class.

Car

Person

Warranty
11

Named Associations Associations can be unnamed, named by a verb phrase, or identified by role names at either end of the association. An optional arrow shows the direction of the association.

purchases

Car

Person

covers

Warranty

protects

Alternatively, a class can have a role name specified. Role names aid in OO development with respect to responsibilities and operations.

customer

Car

Person

Warranty

12

Constraints on Classes In this example, the solicitCode is set false on Student Customers. These constraints are useful in implementation models.

{if income > 100000 then discountLease = true } {solicitCode = false}

Student

Professional

customer

Car

Person

Warranty

13

Interfaces are used to specify a set of operations for a model element. Interfaces do not specify attributes. The interface is usually marked with an <<interface>> stereotype. <<interface>> Transferable streamOut() streamIn() The diagram below shows a DataSet realizes or supports the Transferable interface. A SocketConnection has an association to a DataSet and depends only on the Transferable interface. DataSet streamOut() streamIn() streamIn()

Transferable transfers

SocketConnection

Note the lack of navigation arrows, implying that navigation is not possible, or not defined.

14

Another way of showing interface realization is shown below. It looks like a form of generalization-specialization. This is due to the fact that an object of eBook or DataSet will behave like a Transferable type.

<<interface>> Transferable streamOut() streamIn()

eBook

DataSet

The diagram above shows that an eBook or DataSet both realize the interface Transerable.

15

Dependency A usage of an interface can also be shown as follows. This shows that a SocketConnection object depends on the Transferable interface. It is important to note that the SocketConnection class does not implement the interface. We say that the SocketConnection class uses the interface. The stereotypes <<interface>> and <<use>> make the diagram more clear, but are not necessary.

<<interface>> Transferable streamOut() streamIn()

<<use>>

SocketConnection

16

Classes and Interfaces in Java Example

<<interface>> DataOutput

<<abstract class>> OutputStream

<<sub interface>>

<<subclass>>

<<interface>> ObjectOutput

ObjectOutputStream

<<dependency>>

MyObjectSender

17

A parameterized class is a type of a class factory. Class Stack creates classes which supply a type for the T parameter. below, three classes are created in two different ways.

T Stack push(element:T) T pop()

<<bind>>Socket

<<bind>>Token

SocketStack

TokenStack

Stack<Position>

18

Interaction Diagrams: Sequence and Collaboration Diagrams Interaction diagrams show how groups of objects work together in the system A Chat Message Use Case Sequence Diagram

aSendMessage Window
client Message()

aClientSocket

* write()

aServerSocket
* recieve()

mssgType := getMssgType()

[validMssg]
new new

aBroadcastMssg

aLogEntry

| | | | | | |

| | | | | | |

| | | |

| | | | | 19

Another Sequence Diagram, with asynchronous messaging A Client Create Sequence Diagram
new

aChatClient

new

aClientListener

new

aChatClientSender

* listenToServer()
recieve()

* listenToChatter()
mssgRequest()

postToClient()

sendToServer()

logout

kill kill

| | | | | | |

| | | | | | |

20

A Collaboration Diagram for the Chat Message Use Case

: SendMessage Window
1 :clientMessage()

:ClientSocket
1.1 * write() 1.1.1 * recieve()

1.1.3: new :ServerSocket 1.1.2 getMssgType() 1.1.4: [validMssg]:new :BroadcastMssg : LogEntry

21

State Diagrams State Diagrams show the dynamic behavior of a system from an outside perspective. The diagram is divided into states and transitions. states describe the activity of the system, that is, the process of the state transitions describe the action of the system, where an action is a short process which moves the sys tem to a new state

Statei

do / activity

Event [Guard] / Action

Statej

do / activity

22

State Diagram Example

Event [Guard] / Action

start / get first item [Not all items checked ] / get next item

Checking

do / check item

[All items checked and available]

Dispatching

do / initiate delivery

[All items checked but some not in stock] Items Received [All items available]

Delivered

Waiting

Delivered

do / close

Item Received [some items not in stock]

23