Structural Diagrams
1
3 basic building blocks of UML - Diagrams
Graphical representation of a set of elements.
Represented by a connected graph: Vertices are things; Arcs are relationships/behaviors.
5 most common views built from
UML 1.x: 9 diagram types. UML 2.0: 13 diagram types
Structural Diagrams Structural Diagrams
Represent the static aspects of a system.
– Class; – Class;
Object Object
– Component – Component
– Deployment – Deployment
– Composite Structure
– Package
Behavioral Diagrams Behavioral Diagrams Interaction Diagrams
Represent the dynamic aspects.
– Use case – Use case
– Sequence; – Sequence;
Collaboration Communication
– Statechart – Statechart
– Activity – Activity
– Interaction Overvie
2
– Timing
Class Diagrams
Structural Diagrams
– Class;
Object
– Component
– Deployment
– Composite Structure
– Package
3
Class Diagram
The basis for all object modeling
All things lead to this
• Most common diagram.
• Shows a set of classes, interfaces, and collaborations and their
relationships (dependency, generalization, association and realization); notes too.
• Represents the static view of a system (With active classes, static process view)
Three modeling perspectives for Class Diagram
❑ Conceptual: the diagram reflects the domain
❑ Specification: focus on interfaces of the software (Java supports interfaces)
❑ Implementation: class (logical database schema) definition to be
implemented in code and database.
Most users of OO methods take an implementation perspective, which is a shame because the
other perspectives are often more useful. -- Martin Fowler
4
Classes
type/class
Names Account simple name - start w. upper case
balance: Real = 0 default value
Attributes
<<constructor>>
short noun - start w. lower case
Operations +addAccount()
<<process>> signature
may cause object to
change state +setBalance( a : Account)
+getBalance(a: Account): Amount
… ellipsis for additional
<<query>> attributes or operations
isValid( loginID : String): Boolean stereotypes to categorize
Bank Customer only the name compartment, ok
Java::awt::Polygon path name = package name ::package name::name
5
Account
Responsibilities
Responsibilities
-- handles deposits
• anything that a class knows or does -- reports fraud to managers
(Contract or obligation)
• An optional 4th item carried out by attributes and operations.
• Free-form text; one phrase per responsibility.
• Technique - CRC cards (Class-Responsibility-Collaborator); Kent Beck and Ward
Cunningham’89
• A collaborator is also a class which the (current) class interacts with to fulfill a responsibility
Customer Account
Opens account Knows interest rate Manager
Account Knows balance
Knows name
Knows address Handles deposits
Reports fraud to
manager
6
Scope & Visibility
• Instance Scope — each instance of the classifier holds its own value.
• Class Scope — one value is held for all instances of the classifier (underlined).
Instance scope Frame
class scope header : FrameHeader
uniqueID : Long
+ addMessage( m : Message ) : Status
public # setCheckSum() Public Public Public
- encrypt()
class method attribute
protected - getClassName()
Private
private class
Protected
class
• Public - access allowed for any outside classifier (+).
• Protected - access allowed for any descendant of the classifier (#).
• Private - access restricted to the classifier itself (-).
• (using adornments in JBuilder)
7
Multiplicity
singleton
multiplicity
1
NetworkController
consolePort [ 2..* ] : Port
Using Design Pattern
public class Singleton {
Singleton private static Singleton instance = null;
- instance private Singleton() {}
public static Singleton getInstance() {
+ getInstance():Singleton if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
NetworkController
consolePort [ 2..* ] : Port
8
Relationships
Window Event
open()
close() dependency
generalization
association
ConsoleWindow DialogBox Control
Controller EmbeddedAgent
generalization
(multiple inheritance)
<<interface>> association navigation
URLStreamHandler SetTopController
authorizationLevel PowerManager
openConnection()
parseURL() startUp()
setURL() shutDown() <<friend>> ChannelIterator
toExternalForm() Connect() 9
realization stereotyped dependency
Dependency
• A change in one thing may affect another.
• The most common dependency between two classes is one where one
class <<use>>s another as a parameter to an operation.
AudioClip
name
Microphone
record(m:Microphone)
start()
stop()
dependency Using relationship
CourseSchedule
addCourse(c : Course) Course
removeCourse(c : Course
Usually initial class diagrams will not have any significant number of 10
dependencies in the beginning of analysis but will as more details are identified.
Dependency – Among Classes
AbstractClass {abstract} <<metaclass>> <<interface>>
attribute MetaClassName InterfaceName
concreteOperation() operation()
abstractOperation()
<<instanceOf>>
generalization realization
ClassName
-simpleAttribute: Type = Default <<use>>
#classAttribute: Type
+/derivedAttribute: Type
+operation(in arg: Type = Default): ReturnType
<<instanceOf>>
objectName: ClassName ClientClass
Attribute = value
simpleAttribute: Type = Default
classAttribute: Type
/derivedAttribute: Type
11
Dependency –Among Classes
• Eight Stereotypes of Dependency Among Classes
– bind: the source instantiates the target template using the given actual
parameters
– derive: the source may be computed from the target
– friend: the source is given special visibility into the target
– instanceOf : the source object is an instance of the target classifier
– instantiate: the source creates instances of the target
– powertype: the target is a powertype of the source; a powertype is a
classifier whose objects are all the children of a given parent
– refine: the source is at a finer degree of abstraction than the target
– use: the semantics of the source element depends on the semantics
of the public part of the target
12
Dependency –Among Classes
– bind: the source instantiates the target template using the given actual
parameters
– derive: the source may be computed from the target
13
Dependency –Among Classes
– friend: the source is given special visibility into the
target
– instanceOf : the source object is an instance of
the target classifier
14
Dependency –Among Classes
–instantiate: the source creates instances
of the target
–powertype: the target is a powertype of
the source; a powertype is a classifier whose
objects are all the children of a given parent
15
Dependency –Among Classes
–refine: the source is at a finer degree of
abstraction than the target
–use: the semantics of the source element
depends on the semantics of the public part of
the target
16
Dependency –Among Use Cases
• Two Stereotypes of Dependency Among Use Cases:
– extend: the target use case extends the behavior of the source
– include: the source use case explicitly incorporates the behavior of another
use case at a location specified by the source
System
Use Case A
Actor
<<include>> <<extend>> Order Processing System
Place Order
<<actor>>
Use Case B Use Case C
Actor Extension points <<extend>>Request Catalog
Additional requests:
1 * after creation of The sales person
the order asks for the catalog
SalesPerson <<include>> <<include>> <<include>>
Supply Customer Info. Order Item Make Payment
17
Generalization
• Four Standard Constraints
– complete: all children in the generalization have been
specified; no more children are permitted
– incomplete: not all children have been specified;
additional children are permitted
– disjoint: objects of the parent have no more than one of
the children as a type
– overlapping: objects of the parent may have more than
one of the children as a type
• One Stereotype
– implementation: the child inherits the implementation of the
parent but does not make public nor support its interfaces
18
Generalization – Along Roles
19
Generalization –Among Actors
Place Order
Extension points
1 * Additional requests:
after creation of the order
SalesPerson
Sales person can do only “Place Order”;
Sales manager can do both “Place Order”
and “Grant Credit”
Grant Credit
1 *
SalesManager
20
Associations
• Represent conceptual relationships between classes
(cf. dependency with no communication/message passing)
direction indicator:
how to read relation name navigability
relationship name
Professor teaches 1..* Course
*
teacher class
role names Multiplicity
defines the number of objects associated with
an instance of the association.
Default of 1;
Zero or more (*);
n..m; range from n to m inclusive
{visibility} {/} role name {: interface name} 21
Associations – A Question
• How would you model the following situation?
“You have two files, say homework1 and myPet, where homework1 is
read-accessible only by you, but myPet is write-accessible by anybody.”
You could create two classes, File and User.
Homework1 and MyPet are files, and you are a user.
File User
<<instanceOf>>
<<instanceOf>>
homework1:File
u:User
myPet:File
anyoneElse: User
Approach 1: Now, would you associate the file access right with File?
22
Approach 2: Or, would you associate the file access right with User?
Associations – Links
– link is a semantic connection among objects.
– A link is an instance of an association.
association class
class association name
Worker 1..* works for *
employee
Company
employer
+setSalary( s : Salary)
+setDept( d : Dept)
? <<instanceOf>>
<<instanceOf>>
assign(development)
w : Worker : Company
named object
link anonymous object
23
Association generalization is not automatic, but should be explicit in UML
Associations – Link Attributes
• Link Attributes
The most compelling reason for having link attributes is for-many-to-many relationships
File User
link attribute
access permission
• Association Class
File * 1..* User
visual tie
AccessRight
access permission association class
• With a refactoring
AccessRight * 1
File 1 1..* User
access permission 24
Modeling Structural Relationships
Considering a bunch of classes and their association relationships
1
School Department 0..1
has 1..*
1..*
1..* 1..*
assigned to
member
* 1..* 1..* 1 chairperson
attends * teaches1..*
Student Course Instructor
* *
The model above is from Rational Rose. How did the composite symbol ( )get loaded versus the
aggregation? Use the Role Detail and select aggregation and then the “by value” radio button.
25
Modeling Structural Relationships
Aggregation - structural association representing “whole/part” relationship.
- “has-a” relationship.
multiplicity whole
part
1..*
Department Company
association aggregation
Composite Composite is a stronger form of aggregation.
Composite parts live and die with the whole.
Body Composite parts may belong to only one composite. Car
Part -> whole?
Liver
Body
Heart
Liver Heart Wheel Engine
Can aggregations of objects be cyclic?
Association – Qualification
Bank Qualifier,
account # cannot access person without knowing the account #
*
0..1
Person
Chessboard
rank:Rank
file:File
1
1
Square
* 0..1
WorkDesk jobId : int returnedItem
27
Association – Interface Specifier
association
worker : IEmployee *
Person 1
supervisor : IManager
Interface Specifier
Realization
• A semantic relationship between classifiers in which one classifier specifies
a contract that another guarantees to carry out.
• In the context of interfaces and collaborations
• An interface can be realized by many classes/components
• A class/component may realize many interfaces
IManager
Person
getProject()
getSchedule() 28
Modeling a Logical Database
• Class diagrams to provide more semantics
• From a general class diagram, first identify classes whose state must be persistent (e.g. after
you turn off the computer, the data survives, although the program doesn’t).
• Create a class diagram using standard tagged value, (e.g. {persistent} ).
• Include attributes and associations.
• Use tools, if available, to transform logical design (e.g., tables and attributes) into physical
design (e.g., layout of data on disk and indexing mechanisms for fast access to the data).
School Department
0..1
{ persistent} { persistent}
name : Name
name : Name
address : String
phone : Number addInstructor()
1..* removeInstructor()
addStudent()
removeStudent() getInstructor()
1..*
getStudent() getAllInstructors()
getAllStudents()
addDepartment() 1..*
removeDepartment()
getDepartment()
getAllDepartments()
1..*
1..* 1..* 0..1 chairperson
*
Student Course Instructor
{ persistent} { persistent} { persistent}
name : Name * * name : Name * 1..* name : Name
studentId : Number courseId : Number
29
Forward/ Reverse Engineering
• translate a collaboration into a logical database schema/operations
• transform a model into code through a mapping to an implementation language.
• Steps
– Selectively use UML to match language semantics (e.g. mapping multiple inheritance in a collaboration
diagram into a programming language with only single inheritance mechanism).
– Use tagged values to identify language..
successor
public abstract class EventHandler
{
EventHandler private EventHandler successor;
{ Java} private Integer currentEventId;
currentEventId : Integer
Client source : Strings private String source;
{ Java}
handleRequest() : void
EventHandler() {}
public void handleRequest() {}
}
• translate a logical database schema/operations into a collaboration
• transform code into a model through mapping from a specific implementation language.
30
Object Diagrams
Structural Diagrams
– Class;
Object
– Component
– Deployment
– Composite Structure
– Package
31
Instances & Object Diagrams
❑ “instance” and “object” are largely synonymous; used interchangeably.
❑ difference:
❑ instances of a class are called objects or instances; but
❑ instances of other abstractions (components, nodes, use cases, and
associations) are not called objects but only instances.
What is an instance of an association called?
Object Diagrams
❖ very useful in debugging process.
– walk through a scenario (e.g., according to use case flows).
– Identify the set of objects that collaborate in that scenario (e.g., from use case flows).
– Expose these object’s states, attribute values and links among these objects.
32
Instances & Objects - Visual Representation
anonymous instance
named instance
myCustomer
: Multimedia :: AudioStream
t : Transaction
: keyCode c : Phone
agent :
[WaitingForAnswer]
multiobject orphan instance
(type unknown) instance with current state
r : FrameRenderThread myCustomer
active object
(with a thicker border; owns a id : SSN = “432-89-1738”
thread or process and can
initiate control activity) active = True
instance with attribute values
33
Instances & Objects - Modeling Concrete Instances
• Expose the stereotypes, tagged values, and attributes.
• Show these instances and their relationships in an object diagram.
current: Transaction
primaryAgent <<instanceOf>>
[searching] LoanOfficer
current := retrieve()
: Transaction
Instances & Objects - Modeling Prototypical Instances
• Show these instances and their relationships in an interaction diagram or an
activity diagram. 2.1 : startBilling
1 : create
a: CallingAgent c: Connection
34
2: enableConnection
Instances & Objects – More Examples
1: sort() c : Company
list()
d: Directory contents: File
s : Department rd : Department
addFile(f:File) 1: addElement(f)
name = “Sales” name = “R&D”
d: Directory contents: File
secureAll() 1*: changeMode(readOnly) uss : Department
d: Directory f: File *
name = “US Sales”
client servers :Server manager
1: aServer := find(criteria) erin : Person
aServer:Server : ContactInfomation
name = “Erin”
2: process(request)
employeeID = 4362 address = “1472 Miller St.”
title = “VP of Sales”
call ::= label [guard] [“*”] [return-val-list “:=“] msg-name “(“ arg-list “)” 35
