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