Object Oriented Analysis and Design 1 Chapter 2 UML Overview Building blocks of the UML Structure things in the UML Behavioral things in the UML.

Object Oriented Analysis and Design 1

Chapter 2 UML Overview Building blocks of the UML Structure things in the UML Behavioral things in the UML Grouping things in the UML Relationships in the UML Diagrams in the UML Extension mechanism of the UML Simple Example - Hello World


Building Blocks of the UML


Building Blocks of the UML The vocabulary of the UML encompasses

three kinds of building blocks: Things: the abstractions that are first-class

citizens in a model; Relationships: relationships tie these things

together; Diagrams: diagrams group interesting

collections of things.


Things in the UML There are four kinds of things in the UML:

Structural things: class, interface, collaboration, use case, active class, component, artifact & node

Behavioral things: interaction, state machine, activity

Grouping things: package Annotational things: note

These things are the basic object-oriented building blocks of the UML.


Structural things in the UML


Structural things in the UML the nouns of UML models. the mostly static parts of a model, either

conceptual or physical Collectively, the structural things are called

classifiers eight kinds:

Logic view: class, interface, collaboration, Requirement view: use case Process view: active class Implementation view: component, artifact, node


Structural things - Class A class is a description of a set of objects

that share the same attributes, operations, relationships, and semantics.

A class is represented using a compartmented rectangle

Objects

Professor Smith

Professor Jones

Professor Mellon

Professor

- name- employeeID : UniqueId- hireDate- status- discipline- maxLoad

+ submitFinalGrade()+ acceptCourseOffering()+ setMaxLoad()+ takeSabbatical()

Attributes

Operations


ProfessornameempID

create( )save( )delete( )change( )

Class Name

Attributes

Operations

Review: Class Compartments A class is comprised of three sections

The first section contains the class name The second section shows the structure

(attributes) The third section shows the behavior

(operations)


: Professor

ProfessorClark : Professor

ProfessorClark

Class Name Only

Object Name Only

Class and Object Name

Review: Representing Objects An object is represented as rectangles with

underlined names

Professor Clark

a + b = 10


Tube

Pyramid

Cube

Shape

DrawMoveScaleRotate

<<interface>>

Realization relationship

Structural things - Interface An interface is a collection of operations that

specify a service of a class or component. Interfaces support “plug-and-play”

architectures


Tube

Pyramid

Cube

Shape

DrawMoveScaleRotate

<<interface>>

Tube

Pyramid

CubeShape

Elided/Iconic Representation(“lollipop”)

Canonical (Class/Stereotype) Representation

Review: Interface Representations


Structural things - Collaboration In the context of a system's architecture, a

collaboration allows you to name a conceptual chunk that encompasses both static and dynamic aspects.

A collaboration names a society of classes, interfaces, and other elements that work together to provide some cooperative behavior that's bigger than the sum of all its parts.

You use collaborations to specify the realization of use cases and operations, and to model the architecturally significant mechanisms of your system.


Structural things - Collaboration A collaboration is a society of classes, interfaces,

and other elements that work together to provide some cooperative behavior that's bigger than the sum of all its parts.

A collaboration is also the specification of how an element, such as a classifier (including a class, interface,component, node, or use case) or an operation, is realized by a set of classifiers and associations playing specific roles used in a specific way.

Graphically, a collaboration is rendered as an ellipse with dashed lines.

LoginLogin


Structural things – Use Case a use case is a description of set of sequence of

actions that a system performs that yields an observable result of value to a particular actor.

A use case is used to structure the behavioral things in a model.

A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with

solid lines, usually including only its name.

LoginLogin


Structural things – Active Class an active class is a class whose objects own one or

more processes or threads and therefore can initiate control activity.

An active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements.

Graphically, an active class is rendered as a class with double lines on the left and right; it usually includes its name, attributes, and operations.

EventManager

suspend()flush()


Structural things – Component A component is a modular physical part of the

system design that hides its implementation behind a set of external interfaces.

The implementation of a component can be expressed by wiring together parts and connectors.

Graphically, a component is rendered like a class with a special icon in the upper right corner.

Orderform


Structural things – Artifact An artifact is a physical and replaceable part of

a system that contains physical information ("bits").

An artifact typically represents the physical packaging of source or run-time information.

Graphically, an artifact is rendered as a rectangle with the keyword «artifact» above the name.

Login.dll

<<artifact>>


Structural things – Node a node is a physical element that exists at run time

and represents a computational resource, generally having at least some memory and, often, processing capability.

A set of components may reside on a node and may also migrate from node to node.

Graphically, a node is rendered as a cube, usually including only its name.

Node #1

<<Node>>


Behavioral things in the UML


Behavioral things in the UML the verbs of UML models. the mostly dynamic parts of a model three primary kinds:

Among a set of objects: interaction For an object: state machine The sequence of steps: activity


Behavioral things - Interaction an interaction is a behavior that comprises a set of

messages exchanged among a set of objects within a particular context to accomplish a specific purpose.

The behavior of a society of objects or of an individual operation may be specified with an interaction.

An interaction involves a number of other elements, including messages, action sequences (the behavior invoked by a message), and links (the connection between objects).

Graphically, a message is rendered as a directed line, almost always including the name of its operation. display()


What Is an Interaction Diagram? An interaction diagram shows an interaction,

consisting of a set of objects and their relationships, including the messages that may be dispatched among them.

It models the dynamic aspects of a system.

Sequence Diagrams Collaboration Diagrams


What Is a Sequence Diagram? A sequence diagram is an interaction

diagram that emphasizes the time ordering of messages.

The diagram shows The objects participating in the interaction. The sequence of messages exchanged.

Sequence Diagrams


What Is a Communication Diagram? A communication diagram emphasizes the

organization of the objects that participate in an interaction.

The communication diagram shows The objects participating in the interaction. Links between the objects. Messages passed between the objects.

Communication Diagrams


public class HelloWorldApp2 { public static void main(String[] args) { Greeting hello = new Greeting(); hello.greet("Hello World"); }}class Greeting { public void greet(String s) { System.out.println(s); }}

Interaction Diagram Example - HelloWorldApp2.java

client hello : Greeting

greet(String)

client hello : Greeting1: greet(String)


Behavioral things - State machine a state machine is a behavior that specifies the

sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events.

The behavior of an individual class or a collaboration of classes may be specified with a state machine.

A state machine involves a number of other elements, including states, transitions, events, and activities.

Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates, if any.

waiting


Behavioral things - Activity an activity is a behavior that specifies the

sequence of steps a computational process performs

In an activity, the focus is on the flows among steps without regard to which object performs each step.

A step of an activity is called an action. Graphically, an action is rendered as a rounded

rectangle with a name indicating its purpose. States and actions are distinguished by their different contexts.

waiting


Grouping things in the UML


Grouping things in the UML A package is a general-purpose mechanism for

organizing elements into groups. In all, there is one primary kind of grouping thing,

namely, packages. Packages are the basic grouping things with which

you may organize a UML model. There are also variations, such as frameworks, models, and subsystems (kinds of packages)

Business rules


Grouping things - Package Grouping things are the organizational parts of UML

models. Structural things, behavioral things, and even other

grouping things may be placed in a package. Unlike components (which exist at run time), a

package is purely conceptual (meaning that it exists only at development time).

Graphically, a package is rendered as a tabbed folder, usually including only its name and, sometimes, its contents.

A(from packageA)

B(from packageB)

Dependency relationship

PackageA PackageB


Annotational things - Note Annotational things are the explanatory parts of UML models. These are the comments you may apply to describe,

illuminate, and remark about any element in a model. There is one primary kind of annotational thing, called a note. A note is simply a symbol for rendering constraints and

comments attached to an element or a collection of elements. Graphically, a note is rendered as a rectangle with a dog-

eared corner, together with a textual or graphical comment.

One of these is executed:


Relationships in the UML


Relationships in the UML There are four kinds of relationships in the

UML: Association Dependency Generalization Realization

+ open() : void

AbstractWindow

+ close() : void

<<Interface>>

Event

Window+ open() : void

+ close() : void

+ handleEvent(e: Event) : void

ConsoleWindow DialogBox Control


What Is an Association?The semantic relationship between two

or more classes that specifies connections among their instances A structural relationship, specifying that objects of

one thing are connected to objects of another

Course<<entity>>

Student<<entity>>

Schedule<<entity>>

Professor University

EmployerEmployee

Role Names

Works for

Association

Association Name


What Is an Association? – A example

class CatalogueEntry { private string name; private int number; private double cost; public double getCost () { return cost; } }class Part { private CatalogueEntry entry; public double cost () { return entry.getCost(); }}

CatalogueEntry screw= new CatalogueEntry (“screw”, 28834, 0.02);

Part screw1 = new Part(screw) ;

screw1.cost();


An association is a structual relationship that desribes a set of links. a link being a connection among objects.

A link specifies a path along which one object can dispatch a message to another (or the same)object.


: Part : Part

: CatalogueEntry

name = “screw” number = 28834 cost = 0.02

Describes Describes

Fig. Links between objects

: CatalogueEntry

name = “screw” number = 28834 cost = 0.02

: PartClientcost()

Fig. Finding the cost of a Part

getCost()


In general, a link is an instance of an association.


Fig. Example of an association

CatalogueEntry

- name - number - cost

+ cost()

Part

+ getCost() 1*


Schedule

Student

‘ Student.cls

Public theSchedule as Schedule

‘ Schedule.cls

Public theStudent as Student

1

1

Example : Associations mapping to VB


Adornments that apply to associations.

Person Companynn

-employer-employee

job nn

Association Name

Role Names

An association name: to describe the nature of the relationship. When a class participates in an association, it has a specific role that it plays in that relationship. A role is just the face

the class at the near end of the association presents to the class at the other end of the association.


Adornments that apply to associations. The multiplicity of an association's role: to state how many objects may be connected across an instance of an association. Navigation: Given a plain, unadorned association between two classes, it's possible to navigate from objects of one kind to

objects of the other kind.

2..4

0..1

1..*

0..*

1

*

2, 4..6

University Professor1 0..*

Multiplicity

Navigation

Unspecified Exactly one Zero or more (many,

unlimited) One or more Zero or one Specified range Multiple, disjoint

ranges


Student Schedule

Whole

Aggregation

Part

Association - Aggregation A special form of association that models a

whole-part relationship between an aggregate (the whole) and its parts


Whole

Composition

Part

Association - Composition A form of aggregation with strong

ownership and coincident lifetimes The parts cannot survive the whole/aggregate

Student Schedule


Association - Association Class In an association between two classes, the

association itself might have properties. A class “attached” to an association Contains properties of a relationship One instance per link

Company Person* 1..*

-employer -employee

Job-salary

+ getSalary()


Association - Association Class

Company Person* 1..*

-employer -employee

Job-salary

+ getSalary()

Design Decisions

Company Person*1..* Job-salary

+ getSalary()

1 1


Association - Recursive association

Course

prerequisites

0..*


Association - Example

School

Student

1..n

n

1..n

n

member

Coursenn

attends Instructor1..nn 1..nn

teaches

Department

1 1..n1

has

1..n

1..n1..n

1..n

1..n

assignedTo

0..10..1

0..1

-chairperson


Client Supplier

Package

ClientPackage SupplierPackage

Client Supplier

Class



Component

Relationships: Dependency A relationship between two model elements

where a change in one may cause a change in the other

Non-structural, “using” relationship


Dependency – Example

Professor Course

class Professor { public void teach(Course c) { ……..} ……………..}

class Professor { public void teach() { Course c = new Course(); ……..} ……………..}


Example: HelloWorld.java import java.applet.Applet;import java.awt.Graphics; public class HelloWorld extends Applet { public void paint(Graphics g) { g.drawString("Hello World!", 50, 25); }}

HelloWorld

paint()

Applet

Graphics



Relationships: Generalization A relationship among classes where one

class shares the structure and/or behavior of one or more classes

Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses Single inheritance Multiple inheritance

an “is-a-kind of” relationshipEmployee

ManagerEngineer

Generalization relationship


• Employee is a generalization of Engineers and Managers.

• Engineer is a specialization of Employee.

• Manager is a kind of Employee.

• Engineers and Managers inherit the Employee interface (and in this case, some implementation too).

Generalization - Example

class Employee {…...};class Manager : public Employee {..};class Engineer : public Employee {…};.

class Employee {…...}class Manager extends Employee {..}class Engineer extends Employee {…}


Example: HelloWorld.java import java.applet.Applet;import java.awt.Graphics; public class HelloWorld extends Applet { public void paint(Graphics g) { g.drawString("Hello World!", 50, 25); }}

HelloWorld

paint()

Applet

Graphics

Generalization relationship


Accountbalancenamenumber

Withdraw()CreateStatement()

Checking

Withdraw()

Savings

GetInterest()Withdraw()

Superclass (parent)

Subclasses

Generalization Relationship

Ancestor

Descendents

Example: Single Inheritance One class inherits from another


Airplane Helicopter Wolf Horse

FlyingThing Animal

Bird

multipleinheritance

Use multiple inheritance only when needed, and always with caution !

Example: Multiple Inheritance A class can inherit from several other

classes


Inheritance leverages the similarities among classes

What Gets Inherited? A subclass inherits its parent’s attributes,

operations, and relationships A subclass may:

Add additional attributes, operations, relationships

Redefine inherited operations (use caution!) Common attributes, operations, and/or

relationships are shown at the highest applicable level in the hierarchy


Truck

tonnage

GroundVehicle

weight

licenseNumber

Car

owner

register( )

getTax( )

Person

0..*

Trailer

1Superclass (parent)

Subclass

generalization

size

Example: What Gets Inherited


Relationships: Realization One classifier serves as the contract that

the other classifier agrees to carry out

Shape

Tube

Pyramid

Cube

Shape

draw()move()scale()rotate()

<<Interface>>Tube

Pyramid

Cube

Canonical (Class/Stereotype) Representation

Elided/Iconic Representation(“lollipop”)

Realization relationship


Realization - Example

Circle

Shape

interface Shape { public void draw() ; }

class Circle implements Shape { public void draw() {…..} ……}

class Shape { public: virtual void draw() = 0 ; };class Circle : public Shape { public: void draw() {…..} ……};


Diagrams in the UML


The UML1.x includes nine such diagrams: Class diagrams: to illustrate logical structure. Object diagrams: to illustrate objects and links. State diagrams: to illustrate behavior. Component diagrams: to illustrate physical structure of

the software. Deployment diagrams: to show the mapping of software

to hardware configurations. Interaction diagrams (i.e., collaboration and sequence

diagrams): to illustrate behavior. Activity diagrams: to illustrate the flow of events in a use-

case.

Diagrams in the UML 1.x


A diagram is a view into a modelA model is a completedescription of a systemfrom a particularperspective

DeploymentDiagrams

DeploymentDiagrams

use-caseDiagrams

use-caseDiagrams

ScenarioDiagrams

ScenarioDiagramsScenario

Diagrams

ScenarioDiagramsSequence

Diagrams

SequenceDiagrams

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsState

Diagrams

StateDiagrams

ComponentDiagrams

ComponentDiagramsComponent

Diagrams

ComponentDiagramsComponent

Diagrams

ComponentDiagrams

Models

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsObject

Diagrams

ObjectDiagrams

ScenarioDiagrams

ScenarioDiagramsScenario

Diagrams

ScenarioDiagramsCollaboration

Diagrams

CollaborationDiagrams

ActivityDiagrams

ActivityDiagrams

StateDiagrams

StateDiagramsState

Diagrams

StateDiagramsClass

Diagrams

ClassDiagrams


Class diagram - shows a set of classes, interfaces, and collaborations and their relationships.

Component diagram - shows the organizations and dependencies among a set of components.

Deployment diagram - shows a set of nodes and their relationships.

Diagrams in the UML1.xModeling Requirements

Modeling Behavior

Modeling Structure: Logic View

Physical View

Use Case diagram - organizing and modeling the behaviors of a system.

Sequence diagram - emphasizes the time ordering of messages.Collaboration diagram - emphasizes the organization of the objects that participate in an interaction.

Statechart diagram - emphasizes the event-ordered behavior of an object.Activity diagram- emphasizes the flow of control among objects.

Projection of Interaction

Projection of state machine


The UML2.0 includes thirteen diagrams: Class diagram Object diagrams Component diagrams Composite structure diagram State diagram Deployment diagram Interaction diagrams

• communication and sequence diagrams)

Activity diagram. Package diagram Timing diagram Interaction overview diagram

Diagrams in the UML 2.0


Diagrams in the UML 2.0


Diagrams - Class Diagram Class diagram shows a set of classes, interfaces,

and collaborations and their relationships


Object Oriented Analysis & Design, SJTU 66

Class diagrams contain: Classes, interfaces, collaborations. Dependency, generalization, and association relationships

Captures the vocabulary of a system Built and refined throughout development Purpose

Name and model concepts in the system Specify collaborations Specify logical database schemas

Developed by analysts, designers, and implementers

Diagrams - Class Diagram


Order

Product

Ship via

A Simple Sales Order Example


Class Diagram for the Sales Example

Salesperson Product

Sale

Corporate

Customer

Individual Truck

Vehicle

Train

seller buyer item sold shipping mechanism


Effect of Requirements Change

Suppose you need a new type of shipping vehicle ...

Salesperson Product

Sale

Corporate

Customer

Individual Truck

Vehicle

Train

seller buyer item sold shipping mechanism

Change involves adding a new subclass

Airplane


Diagrams - Component Diagram

component.javaImageObserver

image.java

A component diagram shows the organizations and dependencies among software components, including source code components, binary code components, and executable components.

Component diagrams contain: Component packages. Components Interfaces Dependency relationships


Diagrams - Component Diagram Captures the physical structure of the

implementation Visualize the physical components in a system.

libraries, packages, files etc. Built as part of architectural specification Purpose

Organize source code Construct an executable release Specify a physical database

Developed by architects and programmers


Component Diagram - Example


Component Diagram - Example


Diagrams - Deployment Diagram A deployment diagram is a diagram that shows

the configuration of run time processing nodes and the components that live on them.

Captures the topology of a system’s hardware Built as part of architectural specification Purpose

Specify the distribution of components Identify performance bottlenecks

Developed by architects, networking engineers, and system engineers


Deployment Diagram -Example


Deployment Diagram -Example


Diagrams - Sequence Diagram

1: doSomething()

Client Object Supplier Object

Message

:Client :Supplier

Focus of Control

Reflexive MessageObject Lifeline

1.1: doAnotherthing()

Sequence number

A sequence diagram emphasizes the time ordering of messages.


Diagrams - Collaboration Diagram A collaboration diagram emphasizes the organization

of the objects that participate in an interaction.

1: doSomething()

Client Object Supplier Object

Message

Link

:Client :Supplier


Sequence Diagram V.S. Collaboration Diagram Sequence diagrams and collaboration diagrams

express similar information but show it in different ways.

Sequence diagrams show the explicit sequence of messages and are better for real-time specifications and for complex scenarios.

Collaboration diagrams show the relationships among objects and are better for understanding all of the effects on a given object and for procedural design.


Diagrams - Statechart diagram

keyPress

Finished

RunningIdle

shutDown

A statechart diagram shows a state machine, consisting of states, transitions, events, and activities.

Statechart diagrams emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems.


add student / numStudents = numStudents + 1

Unassigned

Assigned

Full

Cancelled

do: Send cancellation notices

Committed

do: Generate class roster

closeRegistration [ has Professor assigned ]

close

/ numStudents = 0

addProfessor

closeRegistration

remove student / numStudents = numStudents - 1

cancel

removeProfessor

[ numStudents = 10 ]

close[ numStudents < 3 ]

closeRegistration[ numStudents >= 3 ]

close[ numStudents >= 3 ]

add student /numStudents = numStudents + 1

cancel


close

[ numStudents = 10 ]cancel

Statechart diagram -Example


superstate

substate

add student /numStudents = numStudents + 1

Open

Unassigned

Assigned

H

add a professor

Closed

Cancelled

do: Send cancellation notices

Full

Committed

do: Generate class roster

closeRegistration

close

remove a professor

close[ numStudents < 3 ]

[ numStudents = 10 ]

closeRegistration[ numStudents >= 3 ]

close[ numStudents >= 3 ]

closeRegistration [ has Professor assigned ]

close

/ numStudents = 0


cancelcancel

Statechart diagram -Example


Diagrams - Activity Diagram

initial state

action state

concurrent fork

concurrent join

Select site

Do site work Do trade work

guard expression

[ not accepted ][ else ]

Bid Plan

Finish construction

final state

decision

An activity diagram shows the flow from activity to activity within a system.


Extension mechanism of the UML


Extension mechanism of the UML Stereotype Tagged value Constraint


Extension mechanism - Stereotypes A stereotype is an extension of the vocabulary of the

UML, allowing you to create new kinds of building blocks similar to existing ones but specific to your problem.

Stereotypes must be based on certain existing types or classes in the metamodel. Stereotypes may extend the semantics, but not the structure of pre-existing types and classes. Certain stereotypes are predefined in the UML, others may be user defined.

LoginForm

Stereotyped element as icon

LoginForm<<boundary>>

Named Stereotype


<<Interface>>Shape

Shape

Stereotypes

Stereotypes define a new model element in terms of another model element.

Sometimes, you need to introduce new things that speak the language of your domain and look like primitive building blocks.

Represented with name in guillemets or as a different icon


Extension mechanism - Tagged Values

Many kinds of elements have detailed properties that do not have a visual notation. In addition, users can define new element properties using the tagged value mechanism.

A tagged value is an extension of the properties of a UML element, allowing you to create new information in that element’s specification.

A tagged value is a keyword-value pair that may be attached to any kind of model element The keyword is called a tag.


Tagged Values - Example

Common examples of tagged values are:

• {Author = (Dave,Ron)}

• {Version Number = 3}

• {Location = d:\java\uml\examples}

• {Location = Node: Middle Tier}

MyClass

{Version = 1.02}


Extension mechanism - Constraint A constraint is an extension of the semantics of a UML

elements, allowing you to add new rules or to modify existing ones.

Constraints may be written as free-form text. If you want to specify your semantics more precisely, you can use the UML’s Objec Constraint Language(OCL).

Simple constraint

{self.wife.gender = female and self.husband.gender = male}

PortfolioCorporation

BankAccount

{secure}{or}

Person

gender : {female,male}0..1

+wife

0..1+husbandConstraint across multiple elements

Formal constraint using OCL


Common Modeling Techniques

1) Modeling Comments - use notes

2) Modeling New Building Blocks - use stereotype.

3) Modeling New Properties - use tagged values.

4) Modeling New Semantics - use constraint


Simple Example – Hello World


Simple Example - Hello World Key Abstractions Mechanisms Components


Example - Key Abstractions

import java.awt.Graphics;class HelloWorld extends java.applet.Applet { public void paint (Graphics g) { g.drawString (“Hello World !”,10,10); }}

HelloWorld

paint()

Applet

Graphics

HelloWorld

paint()

g.drawString (“Hello World !”,10,10)


Example - Key Abstractions

Applet

HelloWorld

Panel

Object

Component

Container

ImageObserver

applet

awt

lang

java

HelloWorld


Example - Mechanisms

:

run( )run( )

callbackLoop( )

handleExpose( )paint( )

Painting mechanism


Example - Components

HelloWorld.class hello.java

hello.html

hello.jpg

HelloWorld Component

Object Oriented Analysis and Design 1 Chapter 2 UML Overview Building blocks of the UML Structure things in the UML Behavioral things in the UML.

Documents

uml slide

structural things class

object oriented analysis

uml behavioral things

uml structure things

kinds of things

uml relationships

uml diagrams