Basic Structural Modeling
Pertemuan ke 4
Classes
Sung Kim CS6359
Slide 2
Overview
• Classes
– Attributes – Operations
– Responsibilities
• Modeling the vocabulary of a system.
• Modeling the distribution of responsibilities.
• Modeling non-software “things”.
• Modeling primitive types.
• Modeling quality abstractions.
Class Vs Objek
Sung Kim CS6359
Slide 4
Classes
• Description of a set of objects that share the same attributes, operations, relationships, and semantics.
Window
origin size open() close()
name attributes operations
Names
• Distinguishing identity.
• Textual string.
• Simple name.
• Prefixed by package name to generate path name.
Account
Java::awt::Rectangle Simple names
Sung Kim CS6359
Slide 6
Name Rules
• Consists of letters, numbers, and certain punctuation marks.
• Short noun phrases drawn from vocabulary of the domain.
• First letter of every word capitalized.
TemperatureSensor BrokerageAccount
Attributes
• Named property of a class.
• Describes a range of values that an instance of the property may hold.
• Short noun representing property of its enclosing class.
• First letter of every word capitalized except the first.
birthDate userAccount
Sung Kim CS6359
Slide 8
Attributes (cont’d)
attributes height : Float width : Float isStudent :
Boolean = false origin
size
You can further specify an attribute by stating its class and possibly a default initial value
Operations
• Abstraction of something that can be done to an object.
• Shared by every object of the same class.
• May cause object to change state.
• Short verb representing behavior of representing class.
• First letter of every word capitalized except the first.
addUser() isEmpty()
Sung Kim CS6359
Slide 10
Operations (cont’d)
operations
reset()
setAlarm( t : Temperature ) value() : Temperature
add() move()
You can specify an operation by stating its signature, covering the name, type and default value of all
parameters and a return type
Organizing
• Only a subset of attributes and operations are typically relevant to any one view.
• Elide a class; hide non-relevant information.
• Use stereotypes to categorize.
• Use ellipsis to specify additional attributes or operations
<<constructor>>
new()
new( p : Policy )
<<process>>
process( o : Order )
…
Sung Kim CS6359
Slide 12
Responsibilities
• Contract or obligation of a class.
• Carried out by attributes and operations.
• Techniques
– CRC cards (Class-Responsibility-Collaborator);
Kent Beck and Ward Cunningham; ’89
– Use case based analysis.
Responsibilities (cont’d)
• Free-form text; one phrase per responsibility.
Responsibilities
-- determine the risk of a customer order
-- handle customer-specific criteria for fraud
FraudAgent responsibilities
Sung Kim CS6359
Slide 14
Modeling Techniques
• Vocabulary.
• Distribution of responsibilities.
• Non-software things.
• Primitive types.
Modeling Vocabulary
• Things used to describe the problem or
solution. Found through CRC cards and/or use case analysis.
• Identify responsibilities for each abstraction.
• Provide attributes and operations needed to
carry out responsibilities.
Sung Kim CS6359
Slide 16
Modeling Distribution of Responsibilities
• Identify a set of classes that work together to carry out some behavior.
• Identify responsibilities for each class.
• Split classes with too much responsibility.
• Collapse classes with trivial responsibility.
• No class should do too little or too much.
Modeling Non-software Things
• Model the thing as a class.
• Use stereotypes to give a distinctive cue.
• Consider nodes to model hardware.
• Use a unique icon.
Sung Kim CS6359
Slide 18
Modeling Primitive Types
• Model as a type using a class notation.
• Use stereotypes as necessary.
• Use constraints to represent valid values.
<<enumeration>>
Boolean false
true
<<datatype>>
Int
{ value range
–2**31 to +2**31-1 }
Hints & Tips
• Well-structured class
– Provides a crisp abstraction drawn from vocabulary of problem or solution.
– Embodies small, well-defined set of responsibilities.
– Provides clear separation of the abstractions specification and implementation.
– Understandable and simple.
– Extensible and adaptable.
Sung Kim CS6359
Slide 20
Hints & Tips (cont’d)
• Drawing a UML class
– Show only properties that are important in a specific context.
– Organize long lists of attributes and operations by grouping.
– Show related classes in the same diagrams.
Summary
• Classes
– Name.
– Attributes.
– Operations.
– Responsibilities.
• Modeling techniques.
– Vocabulary.
– Responsibilities.
– Non-software things.
Basic Structural Modeling
Class Diagrams
Overview
• Modeling simple collaborations.
• Modeling a logical database schema.
• Forward and reverse engineering.
Sung Kim
CS6359
Chapter 8 Slide 24
Class Diagram
• Typical Contents
– Classes – Interfaces
– Collaborations – Relationships
• Dependencies
• Generalizations
• Associations
– Notes
Class Diagram Uses
• Model static design view of a system.
– Vocabulary of the system.
– Collaborations
– Logical database schema.
Sung Kim
CS6359
Chapter 8 Slide 26
Modeling Simple Collaborations
• Identify the mechanism to be modeled; a mechanism represents some function or behavior.
• For each mechanism, identify the classes, interfaces, and other collaborations that participate in this
collaboration.
• Identify the relationships among those entities.
• Use scenarios to walk through the model.
Example Collaboration
SteeringMotor MainMotor
Motor
move(d:Direction, s:Speed) stop()
resetCounter()
Driver CollisionSensor PathAgent
Responsibilities -- seek path -- avoid obstacles
*
Sung Kim
CS6359
Chapter 8 Slide 28
Modeling a Logical Database
• Identify classes whose state must be persistent.
• Create a class diagram using standard tagged value.
• Expand to include structural details, specifically attributes and associations.
• Identify common patterns which cause database problems; create intermediate abstractions if
necessary.
• Use tools if available to transform logical design into physical design.
Example Logical Database
1..*
School
{ persistent}
name : Name address : String phone : Number addStudent() removeStudent() getStudent() getAllStudents() addDepartment() removeDepartment() getDepartment() getAllDepartments()
Student
{ persistent} Instructor
{ persistent}
Department
{ persistent}
name : Name addInstructor() removeInstructor() getInstructor() getAllInstructors()
Course
{ persistent}
1..*
1..*
1..*
1..*
* 1..*
0..1
0..1 chairperson
Sung Kim
CS6359
Chapter 8 Slide 30
Forward Engineering
• Forward engineering—the process of
transforming a model into code through a mapping to an implementation language.
• Steps
– Identify the rules of mapping to a specific language.
– Constrain use of UML to match language semantics (e.g. inheritance).
– Use tagged values to identify language.
– Use tools when possible.
Example Forward Engineering
GuiEventHandler
successor
EventHandler
{ Java}
currentEventId : Integer source : Strings handleRequest() : void
Client
{ Java}
public abstract class EventHandler {
private EventHandler successor;
private Integer currentEventId;
private String source;
EventHandler() {}
public void handleRequest() {}
}
Sung Kim
CS6359
Chapter 8 Slide 32
Reverse Engineering
• Reverse engineering—the process of transforming code into a model through mapping from a specific implementation language.
• Steps
– Identify the rules of mapping from a specific language.
– Use a tool; point the tool to the code.
– Query the model to obtain desired information for the model.
Hints & Tips
• Separate your analysis models from your design models.
– Different levels of abstraction.
– Different contextual vocabulary.
• Elements of a well-structure class diagram.
– Focused on one aspect of a system’s static design view.
– Contains only essential elements for that aspect.
– Provides sufficient details for the level of abstraction.
Sung Kim
CS6359
Chapter 8 Slide 34
Hints & Tips (cont’d)
• Give diagrams a name that communicates their purpose.
• Diagram layout.
– Minimize crossing of arcs.
– Co-locate semantically related elements.
– Use notes and color as visual cues.
– In general one relationship type will dominate each diagram; don’t confuse the issue.
Summary
• Class diagram contents.
• Modeling simple collaborations.
• Modeling logical databases.
• Forward engineering
• Reverse engineering.
Advanced Structural Modeling
Advanced Classes
Overview
• Classifiers
• Advanced notations
• Special properties
– Attributes – Operations
• Template Classes
Sung Kim
CS6359
Chapter 9 Slide 38
Advanced UML Notations
+ addMessage( m : Message ) : Status
# setCheckSum() - encrypt() header : FrameHeader uniqueID : Long
Frame
abstract
class scope public protected
private
signature type
Classifiers
• Classifier—mechanism that describes structural and behavioral features.
Classes Components
Interfaces Nodes
Data types Use cases
Signals Subsystems
Sung Kim
CS6359
Chapter 9 Slide 40
Classifier Examples
move() resize() display() origin
Shape
IUnknown
<<type>>
Int { values range from -2**31 to +2**31 - 1 }
<<signal>>
OffHook
Process loan
<<subsystem>>
Customer Service egb_server
kernel32.dll
class interface
data type
signal
use case
subsystem component node
Visibility
• Public—access allowed for any outside
classifier with visibility to the given classifier (+).
• Protected—access allowed for any descendant of the classifier (#).
• Private—access restricted to the classifier
itself (-).
Sung Kim
CS6359
Chapter 9 Slide 42
Scope
• Instance—each instance of the classifier holds its own value.
• Classifier—one value is held for all instances of the classifier (underlined).
header : FrameHeader uniqueID : Long
Frame
class scope instance
scope
Generalization
display() getID() : Integer { leaf } origin : Point
Icon { root }
isInside( p : Point ) : Boolean edge : LineCollection
ArbitraryIcon height : Integer
width : Integer RectangularIcon
display()
Button
OKButton { leaf }
base class
abstract operation concrete operation
abstract class abstract class
polymorphic operation
concrete class
Sung Kim
CS6359
Chapter 9 Slide 44
Multiplicity
• Constraint on the number of instances of a class or attribute.
consolePort [ 2..* ] : Port
NetworkController 1
ControlRod 3
multiplicity could be singleton
Attributes
• Syntax
[ visibility ] name [ multiplicity ] [ : type ] [ = initial-value ] [ {property-string } ]
• property-string
– changeable—no restrictions (default)
– addOnly—values may not be removed or altered, but may be added
– frozen—may not be changed after initialization
Sung Kim
CS6359
Chapter 9 Slide 46
Attributes (cont’d)
• Examples
origin Name only
+ origin Visibility and name
origin : Point Name and type
head : *Item Name and complex type
name [ 0..1 ] : String Name, multiplicity, and type origin : Point = { 0, 0 } Name, type, and initial value id : Integer { frozen } Name and property
Operations
• Syntax
[ visibility ] name [ (parameter-list ) ] [ : return-type ] [ (property-string) ]
• parameter-list syntax
[ direction ] name : type [ = default-value ]
• direction
– in—input parameter; may not be modified – out—output parameter; may be modified
Sung Kim
CS6359
Chapter 9 Slide 48
Operations (cont’d)
• property-string
– isQuery—state is not affected – sequential—not thread safe
– guarded—thread safe (Java synchronized)
– concurrent—typically atomic; safe for multiple flows of control
Template Classes
• Parameterized element
+ bind( in i : Item; in v : Value ) : Boolean + isBound( in i : Item ) : Boolean {isQuery}
Map
Item Value Buckets : int
Map< Customer, Order, 3 >
<<bind>> ( Customer, Order, 3 )
explicit binding template class
template parameters
Sung Kim
CS6359
Chapter 9 Slide 50
