Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
96 views81 pages

OOSE-Chapter - 3-Part II (Structural Modeling)

Uploaded by

sintebeta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
96 views81 pages

OOSE-Chapter - 3-Part II (Structural Modeling)

Uploaded by

sintebeta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 81

OOSE

Chapter 3-Part II
Structural Model:
Class/Object diagram
Recall
 The UML-
 The why? and the principle of modeling
 The diagrams
 Functional Model
 Essential/system usecase
 Use case components; Actors,Use cases,Boundary
And Relationship
Introduction
 Modelling a system involves identifying the things that
are important to your particular view.
 These things form the vocabulary of the system you are
modelling.
 This part explores how we do basic modelling of
things and concepts from the real-world
 using Class Diagrams
 Before learning how to model using Class Diagram, we
must first understand the basic building blocks of
Class Diagram
3
Cont…
 Class diagrams are widely used to describe the types of
objects in a system and their relationships.
 The relationship can be inheritance, aggregation and
association.
 The class model also describes the attributes and
operations of the class along with the visibility of each.
 Class diagrams model class structure and contents using
design elements such as classes, packages and objects.
 Class diagrams are used in nearly all Object Oriented
software designs.
4
Common Uses
 Class diagrams are used to model the static design
view of a system
 supports the functional requirements of the system as it
contain the data to be manipulated by the functions
 When we model the static design view of a system,
we will use class diagrams in 3 ways: -
 To model the vocabulary of the system
 involves making a decision about which abstractions are a part of
the system under consideration and which falls outside its
boundaries
 Class diagrams are used to specify these abstractions and their
5
responsibilities
 To model simple collaborations
 A collaboration is a society of classes, interfaces, and
other elements that work together to provide
some co-operative behaviour that is bigger than the
sum of all the elements
 Class diagrams are used to visualize and specify this
set of classes and their relationships
 To model logical database schema
 Class diagrams can also be used to model schemas
for databases used to store persistent information

6
Forward & Reverse Engineering
 Even though modelling is important, the primary product of
a development team is software, not diagrams
 Therefore, it is important that the models we create and the
implementations we deploy map to one another
 In most cases, the models we create will be mapped to code
 Forward engineering is the process of transforming a
model into code through a mapping to an implementation
language
 Reverse engineering is the process of transforming code
into model through a mapping from a specific
implementation language
7
Cont…
 The UML was designed with such mappings in mind
 Especially true for class diagrams, whose contents have a
clear mapping to object-oriented languages, i.e Java, C++,
etc
 To start with class modeling, identify objects and classes,
prepare a data dictionary, identify associations between
objects, identify class attributes and initial set of operations
and then organize object classes using inheritance. (more on
this later)
 This process can be initiated from CRC model

8
Cont…

9
Domain Modeling Using CRC
 Class Responsibility Collaboration (CRC cards)
◦ are a brainstorming tool used in the design of object-
oriented software.
◦ are typically used when first determining which
classes are needed and how they will interact.
◦ CRC are an index card on which one records the
responsibilities and collaborators of classes, thus the
name, which stands for Class-Responsibility-
Collaboration.

10
Cont…
 A class responsibility collaborator model is a
collection of standard index cards that have been
divided into three sections.
 A class represents a collection of similar objects,
 a responsibility is something that a class knows
or does, and
 a collaborator is another class that a class
interacts with to fulfill its responsibilities.
Cont..
 CRC cards are usually created
from index cards on which are
written:
 The class name
 The responsibilities of the class.
 The names of other classes with
which the class will collaborate
to fulfill its responsibilities.
Cont…
 Although CRC cards were originally introduced
as a technique for teaching object-oriented
concepts, they have also been successfully used as
a full- fledged modeling technique.
 CRC models are an incredibly effective tool for
conceptual modeling as well as for detailed
design.
Basic steps
 Brainstorm with SME
 Iteratively do the following
 Find classes
 Find responsibilities
 Define collaborators
Class model: major concepts
 Objects
 Classes
 Name
 Attribute
 operations
Objects
 An object is simply a real-world thing or concept
 Three essential aspects of objects are:
 An object has an identity
 Can have a name or can be anonymous
 An object has state
 the names of the various properties that describe the object
(attributes) and also the value of those attributes
 An object has behaviour
 represented by functions (or methods) that use or change the values
of the object’s attributes
 An object is an instance of a class

16
Classes
 Classes are the most important building block of any object-
oriented system
ClassName
attributes
operations
 Classes are used to: -
 capture the vocabulary of the system you are developing
 represent software things, hardware things, and even things
that are purely conceptual
 Well-structured classes have crisp boundaries and form a
part of a balanced distribution of responsibilities across the
system
17
Name

 Every class must have a name to distinguish it


from other classes
 can be a simple name, i.e. Student, Door, etc
 can be a path name
 the class name prefixed by the name of the package
in which that class lives, i.e.
BusinessRecord::Customer,
 A class may be drawn showing only its name
Customer

18
Attribute

 An attribute is a named property of a class


that describes a range of values that instances of the
property may hold
 represents some property of the thing you are modelling
that is shared by all objects of that class
 At any given moment, an object of a class will have
specific values for every one of it’s class attributes
 A class may have a number of attributes

19
 Attributes may be drawn showing only their names (a)
 Or, we can further specify an attribute by stating its type
and possibly a default initial value (b)
Customer Wall
name height : Float
address width : Float
phone thickness : Float
birthdate isLoadBearing : Boolean = false

(a) (b)
20
Operation
 An operation is the implementation of a service
that can be requested from any object of the
class to affect behaviour
 Often, invoking an operation on an object changes
the object’s data or state
 A class may have a number of operations or no
operations at all

21
 Operations may be drawn showing only their names (a)
 We can further specify an operation stating its signature (b)
including the name, type and default value of all parameters
and (in case of functions) a return type

Customer TemperatureSensor

add() reset()
(a) remove() setAlarm(t : Temperature)
(b)
edit() value() : Temperature
22
Cont…
 Attributes define the properties of the objects:
 every instance of the class has the same attributes
 an attribute has a data type
 an attribute has visibility (private, protected,
public)
 the values of the attributes may differ among
instances

23
Cont…
 Operations define the behavior of the
objects
 action performed on or by an object
 available for all instances of the class
 methods/operations has visibility (private,
protected, public)
 need not be unique among classes
Cont…

25
HINTS!
 When we model classes, a good starting point is to
specify the responsibilities of the things in our vocabulary
 A class may have any number of responsibilities
 We do not want any one class to have too many or too little
responsibilities
 In practice, every well-structured class has at least one
responsibility or at most, just a handful
 We will then translate these responsibilities into a set of
attributes and operations that best fulfil the class’s
responsibilities
26
A simple example

 On-line Bookstore Review


 a web application that can be accessed by the store’s registered
customer, whereby each customer can review one or more books sold
in the book store
 The process: -
 Each registered customer has an account that is used to verify his/her ID and
password
 Each registered customer, upon account verification, can review one or more
books based on its title.
 Problem: Come up with a set of classes that can be found in
the above problem

27
 Things that are found in the problem: -
 The process: -
 Each registered CUSTOMER has an ACCOUNT that is used to
verify his/her ID and password
 Each registered CUSTOMER, upon ACCOUNT verification, can
REVIEW one or more BOOKS based on its title.
 Therefore, the things identified are: -
 Account
 Customer
 Book
 Review
28
 Each of these things can form individual classes with
responsibilities
 Account
 Used to keep the customer’s ID and password for verifying that the customer is a
registered customer
 Also keeps additional information, i.e. e-mail address
 Customer
 Used to keep information about the customer, such as customer’s name, ID,
address etc
 Book
 Used to keep the relevant information on the book that is crucial to customer’s
review, i.e. book title, author, rating
 Review
 Used to assign ratings to book reviewed (with 1 being the lowest and 5 the
highest)
 Used to compute the average rating for each book that has been reviewed

29
 Translate the responsibilities for each class into attributes and
operations needed to perform those responsibilities (relevant to
the given problem)
 Account
 Attributes: emailAddress, ID, password
 Operations: verifyPassword()
 Customer
 Attributes: CustName, CustAddress, CustID etc
 Operations: NONE
 Can choose not to show the attributes when modelling the class as they are not
relevant to the given problem
 Book
 Attributes: title, author, rating
 Operations : NONE
 Review
 Attributes: NONE
 Operations: assignRatings(rating : Int), computeAvgRating() : double

30
 Model the classes: -

Account Book
emailAddress title : String
ID author: String
password rating: Float
verifyPassword()

Review

Customer
assignRating(rating : Int)
computeAvgRating() : Double

31
Summary
 Attributes, operations and responsibilities are
the most common features needed to convey the most
important semantics of our classes
 We may need to extend our classes by specifying other
features : will be covered later
 Classes rarely stand alone
 When we build models, we will focus on groups of classes
that interact with one another (relationships)
 In the UML, these group of classes form collaborations
and are usually visualized in class diagrams

32
Relationships
 In object-oriented modelling, there are three kinds of
relationships that are most important
 Dependencies
 represents ‘using’ relationship among classes
 Generalizations
 connects generalized classes to more specialized ones in what
is known as subclass/super-class or child/parent relationship
(inheritance)
 Associations
 represents structural relationships among instances/objects
 Each of these relationships provides a different way
of combining our abstractions (classes)
34
Dependency
 A dependency is a using relationship that
states that a change in specification of one thing
(which is the independent) may affect another
thing that uses it (the dependent thing), but not
necessarily the reverse
 It is rendered as a dashed directed line
dependent independent

35
 Dependencies are used in the context of classes
to show that one class uses another class as an
argument in the signature of an operation
 if the used class changes, the operation of the other class
may be affected
 The most common kind of dependency
relationship is the connection between a class that
only uses another class as a parameter to an
operation
36
Cont…
To model dependency
 Create a dependency pointing from the class
with the operation to the class used as a
parameter in the operation

37
 Example: - A system that manages the assignment of
students and instructors to courses in a university
CourseSchedule

add(c : Course) Course


remove(c : Course)

 There’s a dependency from CourseSchedule to


Course, as Course is used in both the add() and
remove() operations of CourseSchedule

38
Generalization
 A generalization is a relationship between
a general thing (superclass or parent) and a
more specific kind of that thing (subclass or
child)
 Generalization means that objects of the
child may be used anywhere the parent
may appear, but not the reverse
 the child is substitutable for the parent

39
Cont…
It supports polymorphism
An operation of the child that has the
same name/signature as an operation in a
parent overrides the operation of the
parent

40
 Graphically, a generalization is rendered as a solid
directed line with a large open arrowhead, pointing
to the parent

ParentClass

ChildClass
attributes
operations

41
 A class may have zero, one or more parent
 A class that has no parent and one or more children is
called a root or base class
 A class that has no children is called a leaf class
 A class that has exactly one parent is said to use single
inheritance
 A class that has more than one parent is said to use
multiple inheritance
 A given class cannot be its own parent
 We will often use generalizations among classes and
interfaces to show inheritance relationships.
 can also create generalizations with packages
42
How to Identify Generalization
To model inheritance relationship
 Given a set of classes, look for responsibilities,
attributes and operations that are common to two or
more classes
 Elevate those common responsibilities, attributes and
operations to a more general class. If necessary, create a
new class to which you can assign these elements
 Specify that the more-specific classes inherit from
the more-general class by placing a generalization
relationship that is drawn from each specialized class to its
more-general parent
43
 Example: - The Rectangle, Circle and Polygon
classes inherits the attributes and operations of the
Shape class
Shape
origin
move()
resize()
display()

Rectangle Circle Polygon

corner : Point radius : Float


points : List
duplicate()
44
Association
 An association is a structural relationship that specifies
that objects of one thing are connected to objects of
another thing.
 we can navigate from an object of one class to an object of the other
class, and vice versa. The attachment is neither dependency nor
generalization.
 Types of association: -
 Unary association
 where both ends of an association circle back to the same class
 Binary association
 connects exactly two classes
 N-ary association
45
 connects more than two classes
 There are 4 adornments that apply to associations: -
 Name
 An association can have a name to describe the nature
of the relationship
 A direction can also be given to the name by providing
a direction triangle that points in the direction intended
(to read the name)

name name direction

Works for
Person Company

association
46
 Role
 When a class participates in an association, it has a
specific role that it plays in the relationship
 A role is just the face that the class at the near end of
the association presents to the class at the other end
of the association
 An explicit name can be given to the role a
class plays in an association
association

Person Company
employee employer

role name

47
 Multiplicity
 It is important to state how many objects may be connected across
an instance of an association
 This “how many” is called multiplicity of an association’s role
 It is written as an expression that evaluates to a range of values or an
explicit value
 Multiplicity can be written as multiplicity of
 exactly one (1..1) • zero or more (0..*)
 zero or one (0..1) • one or more (1..*)
 many (*) • exact numbers, i.e. 3
multiplicity

1..* 0..*
Person Company
employee employer

48
 Aggregation
 is a “whole-part” relationship within which one or more
smaller class are “part” of a larger “whole”
 represents a “has-a” relationship, whereby an object of the
whole class has objects of the part

Company
whole 1
aggregation

part *
Department
49
 Association Classes
 Sometimes in an association between two classes, the
association itself might have properties /attributes
 In the UML, you’ll model this as an association class, which
is a modeling element that has both association and
class properties
 It is used to model an association that has characteristics of its own
outside the classes it connects
 It comes in handy when you have many-to-many relationship
that you would like to break into a set of one-to-many relationships
 Warning:
 You cannot attach an association class to more than
one association
50
 UML represents an association class with a regular
class box and a dashed line that connects the
association class to the association between the other
two classes.

* 1..*
Company employer
Person
employee

association class
Job
description
dateHired
salary

51
 Example: There’s a many-to-many relationship between Author
and Book, whereby an Author may have written more than one
book and a Book may have more than one Author. The presence
of the BookAndAuthor association class allows us to pair one
Author with one Book: the role attribute allows us to state
whether the Author was the primary, or supporting author, or
editor or etc
* 1..* Book
Author
title: String

BookAndAuthor
role: String

52
To model structural relationship
(association): -
 For each associations, specify a multiplicity
 If one of the classes in an association is structurally
or organizationally a whole compared with the
classes at the other end that look like parts, use an
aggregation
 If there’s a many-to-many relationship between two
classes, use association class (if possible)

53
Modelling Relationships
 When modelling relationships in the UML
 Use dependencies only when the relationship is not
structural
 Use generalization only when the relationship is an “is-a-
kind-of ” or inheritance relationship
 Beware of introducing cyclical generalization relationships
 Keep generalization relationships generally balanced where
the level of inheritance should not be too deep
 Use associations only when there are structural relationships
among objects
54
A simple example
 On-line Bookstore Review
 a web application that can be accessed by the store’s
registered customer, whereby each customer can review one
or more books sold in the book store
 The process given: -
 Each registered CUSTOMER has an ACCOUNT that is used to
verify his/her ID and password
 Each PASSWORD entered must be more than 8 characters and
consists of a combination of text and numbers
 Each registered CUSTOMER, upon ACCOUNT verification, can
REVIEW one or more BOOKs based on its title
 A REVIEW can either be a customer’s review and editor’s review
55
 Things that are found in the problem: -
 Account
 Password
 Customer
 Book
 Review
 can be divided into CustomerReview and
EditorialReview

56
Cont…
 Each of these things can form individual
classes with responsibilities (attributes and operation)
 Account
 Used to keep the customer’s ID and password for
verifying that the customer is a registered
customer
 Also keeps additional information, i.e. e-mail
address
 The password is of the type PASSWORD
57
 Password
 Used to check that the password entered is valid (more
than 8 characters and consists of combination of text and
numbers)
 Customer
 Used to keep information about the customer, such as
customer’s name, ID, address etc
 Book
 Used to keep the relevant information on the book that is
crucial to customer’s review, i.e. book title, author, rating
58
Cont…
 Review
 Divided into sub-classes: CustomerReview and
EditorialReview
 CustomerReview
 Used to assign ratings to book reviewed (with 1 being
the lowest and 5 the highest) by customer
 Used to compute the average rating for each book that
has been reviewed by customer
 EditorialReview
 Used to store editor’s review

59
 Translate the responsibilities for each class into attributes and operations
needed to perform those responsibilities (relevant to the given problem)
 Account
 Attributes: emailAddress(string), ID(string), passwd(Password)
 Operations: verifyPassword(p: Password)
 Password
 Attributes: passwd(string)
 Operations: checkPassword()
 Customer
 Attributes: CustName, CustAddress, CustID etc
 Operations: NONE
 Can choose not to show the attributes when modeling the class as
they are not relevant to the given problem (put NONE for both)
 Book
 Attributes: title, author, rating
 Operations : NONE
60
 Review
 Attributes: NONE
 Operations: NONE
 CustomerReview
 Attributes: NONE
 Operations: assignRatings(rating : Int),
computeAvgRating() : double
 EditorialReview
 Attributes: NONE
 Operations: NONE
61
 The relationship between classes: -
 Dependency
 The operation verifyPassword in Account class has as
parameter a Password class
 Therefore, Account depends on Password
 Generalization
 Review can be divided into customer’s review and
editor’s review
 Therefore, CustomerReview and EditorialReview is the
subclass of Review

62
 Association
 A customer can open 1 account and an account
can be opened by 1 customer
 A customer writes a review and a review can
be written by a customer
 1 customer can write 1 or many reviews, but 1
review can only come form 1 customer
 A book can have many reviews but a review is
for one book
63
 Modelling the classes and relationships: - EditorialReview
Book
title : String has
Review
1 *

writes is written by CustomerReview


Customer
1 1..*
1
assignRating(rating : Int)
opens
computeAvgRating() : Double
1
Account
emailAddress : string
ID : string Password
passwd : Password
pass : String
verifyPassword(p : Password)
checkPassword()
64
Summary

 Plain, simple dependencies, generalizations


and associations with names, multiplicities
and roles are the most common features
needed in creating abstractions (classes)
 For most of the models that we will build, the
basic form of these three relationships will be all
that is needed to convey the most important
semantics of a relationship

65
Example
Littlesand, Pebblesea and Mudport are three charming resorts
on the South Coast which are very popular with tourists, since
they score well on beach rating and hours of sunshine for the
area. All three resorts have a large number of places to stay,
ranging from one-room guest house to the exclusive Palace
Hotel at Pebblesea. The local tourist board wants to set up a
central system to deal with room bookings in the area.
 Draw a class diagram to represent this information. Where appropriate,
your diagram should include association, aggregation, inheritance
and multiplicity. List sample attributes and operations ONLY for the
class Resort.

66
 Steps in drawing the Class Diagram: -
 Find the abstractions/classes
Littlesand, Pebblesea and Mudport are three charming
resorts on the South Coast which are very popular with
tourists, since they score well on beach/sea side rating and
hours of sunshine for the area. All three resorts have a large
number of places to stay, ranging from one-room guest
house to the exclusive Palace Hotel at Pebblesea. The local
tourist board wants to set up a central system to deal with
room bookings in the area.
The classes are: -
RESORT, PLACE TO STAY, HOTEL, GUEST HOUSE, ROOM, BOOKING &
TOURIST

67
 Can ignore each classes responsibilities as the question
only wants the attributes and operations for the Resort
class. (follow the PROBLEM DOMAIN)
 Resort Class
 Used to store information on the resort such as name, description,
beach rating, hours of sunshine etc
 Used to perform operations such as updating the beach rating and
updating the hour of sunshine etc
 Attributes:
name (string) description (string)
beach rating (double) hour of sunshine (double)
 Operations:
update beach rating
68 update hours of sunshine
 Find the relationships between the classes: -
 “All three Resorts have a large number of places to stay”
 Places to stay is ‘a part of’ Resorts, with Resort being the
‘whole’ : AGGREGATION
 A resort can have 1 or many places to stay
 “All three resorts have a large number of places to stay, ranging
from one-room guest house to the exclusive Palace Hotel at
Pebblesea”
 Places to stay consists of guest houses and hotels, with
Places to stay being the parent and the other two, the
child : GENERALIZATION

69
 “The local tourist board wants to set up a central system to
deal with room bookings in the area”
ASSOCIATION: -
 A place to stay has one of many rooms
 A room can have many bookings or none
 A booking is for one or more rooms
 A booking can be done by one or many tourists
 A tourist can book one or many rooms

70
 The class diagram : -

Resort

1..*
Place_to_Stay Room Booking
1 1..* 1..* 0..*

1..*

1..*
Hotel Guest_House
Tourist

71
 The attributes and operations for the Resort class

Resort
name : String
description : String
beach_rating : Double
hours_of_sunshine: Double
update_beach_rating (r : Double)
update_hours_of_sunshine (h : Double)

72
 Note: Using forward engineering, the Resort class can now be
mapped into a C++ code.
class Resort
{
private:
char name[20], descrp[100];
double rating, sun_hours;
public:
void updateBeachRating(double r) { rating = r; }
void updateHoursSunshine(double h) {sun_hours = h; }
};

73
Object diagrams
Object Diagrams
 Object diagrams model the instances of things
contained in class diagrams
 An object diagram shows a set of objects and
their relationships at a point in time
 We use object diagrams to model the static design
view or static process view of a system.
 involves modelling a snapshot of the system at a
moment in time and rendering a set of objects,
their state, and their relationships
75
 The UML notation for an object takes the same form as
that for a class, except for 3 differences:
 Within the top compartment of the class box, the name of the
class to which the object belongs to appears after a colon :
 The object may have a name that appears before the colon, or it may be
anonymous (no name before the colon)
 The contents of the top compartment are underlined for an
object.
 Each attribute defined for the given class has a specific
value for each object that belong to that class.
Object : Class : Class

attribute1 = value attribute1 = value


attribute2 = value attribute2 = value

named object anonymous object


76
 Object diagrams commonly contain
 objects
 links
 may contain notes and constraints
 may also contain packages or subsystems, both of which
are used to group elements of your model into larger
chunks
 We use object diagrams to model the static design
view or static process view of a system just as you do
with class diagrams, but from the perspective of real
or prototypical instances
 Supports the functional requirements of a system
77
From the class diagram given below, you can get several
instances of it.
Author Book
name : String wrote title : String
rating: Double

published by

Publisher
name : String

Class Diagram

78
: Author : Book
name : “Margeret Mitchell” wrote title : “Gone With the Wind”
rating: 4.5

published by

AW: Publisher
name : “Hawthorne”

Object diagram

79
: Author : Book
name : “Tim Burton” wrote title : “Burton on Burton”
rating: 4

published by

AW: Publisher
name : “Barnes”

Object diagram

80
End of Part II

You might also like