basic structural modeling
DESCRIPTION
Basic Structural Modeling. Pertemuan ke 4 Classes. 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. - PowerPoint PPT PresentationTRANSCRIPT
Basic Structural Modeling
Pertemuan ke 4Classes
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
originsizeopen()close()
nameattributes
operations
Sung Kim CS6359 Slide 5
Names
• Distinguishing identity.• Textual string.• Simple name.• Prefixed by package name to generate path
name.
Customer
Account
TemperatureSensor
Circuit
Java::awt::RectangleSimple names
path name
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.TemperatureSensorBrokerageAccount
Sung Kim CS6359 Slide 7
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.
birthDateuserAccount
Sung Kim CS6359 Slide 8
Attributes (cont’d)
attributesheight : Floatwidth : FloatisStudent : Boolean = false
originsize
You can further specify an attribute by stating its class and possibly a default initial value
Sung Kim CS6359 Slide 9
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)
operationsreset()setAlarm( t : Temperature )value() : Temperatureadd()
move()
You can specify an operation by stating its signature, covering the name, type and default value of all parameters and a return type
Sung Kim CS6359 Slide 11
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 oroperations
<<constructor>>new()new( p : Policy )<<process>>process( o : Order )…<<query>>isSuspect( 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.
Sung Kim CS6359 Slide 13
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.
Sung Kim CS6359 Slide 15
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.
Sung Kim CS6359 Slide 17
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
falsetrue
<<datatype>>Int
{ value range –2**31 to +2**31-1}
Sung Kim CS6359 Slide 19
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.
Sung Kim CS6359 Slide 21
Summary• Classes
– Name.– Attributes.– Operations.– Responsibilities.
• Modeling techniques.– Vocabulary.– Responsibilities.– Non-software things.– Primitive types.
Basic Structural Modeling
Class Diagrams
Sung KimCS6359
Chapter 8 Slide 23
Overview
• Modeling simple collaborations.• Modeling a logical database schema.• Forward and reverse engineering.
Sung KimCS6359
Chapter 8 Slide 24
Class Diagram
• Typical Contents– Classes– Interfaces– Collaborations– Relationships
• Dependencies• Generalizations• Associations
– Notes
Sung KimCS6359
Chapter 8 Slide 25
Class Diagram Uses
• Model static design view of a system.– Vocabulary of the system.– Collaborations– Logical database schema.
Sung KimCS6359
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.
Sung KimCS6359
Chapter 8 Slide 27
Example Collaboration
SteeringMotor MainMotor
Motor
move(d:Direction, s:Speed)stop()resetCounter()Status status()Integer distance()
Driver
CollisionSensorPathAgent
Responsibilities-- seek path-- avoid obstacles
*
Sung KimCS6359
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.
Sung KimCS6359
Chapter 8 Slide 29
Example Logical Database
1..*
School{ persistent}
name : Nameaddress : Stringphone : NumberaddStudent()removeStudent()getStudent()getAllStudents()addDepartment()removeDepartment()getDepartment()getAllDepartments()
Student{ persistent}
name : NamestudentId : Number
Instructor{ persistent}
name : Name
Department{ persistent}
name : Name
addInstructor()removeInstructor()getInstructor()getAllInstructors()
Course{ persistent}
name : NamecourseId : Number
1..*
1..*
1..*
1..*
1..*
1..**
0..1
0..1 chairperson
** *
Sung KimCS6359
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.
Sung KimCS6359
Chapter 8 Slide 31
Example Forward Engineering
GuiEventHandler{ Java}
successor
EventHandler{ Java}
currentEventId : Integersource : Strings
handleRequest() : void
Client{ Java}
public abstract class EventHandler{ private EventHandler successor; private Integer currentEventId; private String source;
EventHandler() {} public void handleRequest() {}}
Sung KimCS6359
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.
Sung KimCS6359
Chapter 8 Slide 33
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 KimCS6359
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.
Sung KimCS6359
Chapter 8 Slide 35
Summary
• Class diagram contents.• Modeling simple collaborations.• Modeling logical databases.• Forward engineering• Reverse engineering.
Advanced Structural Modeling
Advanced Classes
Sung KimCS6359
Chapter 9 Slide 37
Overview
• Classifiers• Advanced notations• Special properties
– Attributes– Operations
• Template Classes
Sung KimCS6359
Chapter 9 Slide 38
Advanced UML Notations
+ addMessage( m : Message ) : Status# setCheckSum()- encrypt()
header : FrameHeaderuniqueID : Long
Frame
abstract
class scope
public
protected
private
signature
type
Sung KimCS6359
Chapter 9 Slide 39
Classifiers
• Classifier—mechanism that describes structural and behavioral features.
Classes Components
Interfaces Nodes
Data types Use cases
Signals Subsystems
Sung KimCS6359
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
nodecomponent
Sung KimCS6359
Chapter 9 Slide 41
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 KimCS6359
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 : FrameHeaderuniqueID : Long
Frameclass scope
instancescope
Sung KimCS6359
Chapter 9 Slide 43
Generalization
display()getID() : Integer { leaf }
origin : Point
Icon{ root }
isInside( p : Point ) : Boolean
edge : LineCollection
ArbitraryIcon
height : Integerwidth : Integer
RectangularIcon
display()
Button
display()
OKButton{ leaf }
base class
abstract operation
concrete operation
abstract class
abstract class
polymorphic operation
concrete class
leaf class
Sung KimCS6359
Chapter 9 Slide 44
Multiplicity
• Constraint on the number of instances of a class or attribute.
consolePort [ 2..* ] : Port
NetworkController 1
ControlRod3
multiplicity
could be singleton
Sung KimCS6359
Chapter 9 Slide 45
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 KimCS6359
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
Sung KimCS6359
Chapter 9 Slide 47
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– inout—input parameter; may be modified
Sung KimCS6359
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
Sung KimCS6359
Chapter 9 Slide 49
Template Classes
• Parameterizedelement
+ bind( in i : Item; in v : Value ) : Boolean+ isBound( in i : Item ) : Boolean {isQuery}
Map
ItemValueBuckets : int
Map< Customer, Order, 3 >
OrderMap
<<bind>> ( Customer, Order, 3 )
explicit binding
implicit binding
template class
template parameters
Sung KimCS6359
Chapter 9 Slide 50
Summary
• Classifiers• Visibility• Scope• Multiplicity• Attributes• Operations• Template Classes