CHAPTER THREE-PART III

Structural Model

1
 Class Diagram

 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
A class is a definition of objects that share the same properties, relationships and
behavior.
 An object is an instance of a class(or structure).
 The properties of a class are called attributes and the behavior is expressed in
2
operations.
 Class Diagram------

 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.

 They are used to describe the classes of the system and their relationships to each other.

 Class diagrams are used to model the static design view of a system

It supports the functional requirements of the system

When we model the static design view of a system,

we will use class diagrams in 3 ways:

3
 Class Diagram------
1. To model the vocabulary of the system
 This 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 responsibilities
2. 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.
3. To Model Logical Database Schema
 Class Diagrams can also be used to model schemas for databases used to store persistent
4
 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.

1. Forward Engineering:
 It is the process of transforming a model into code through a mapping to an

implementation language
5
 Forward & Reverse Engineering------

2. Reverse Engineering:
 It is the process of transforming code into model through a mapping from

a specific implementation language

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

6
 Class Representation

Each class is represented by a rectangle subdivided into three compartments

 Name
 Attributes
 Operations
Modifiers are used to indicate visibility of attributes and operations, but this is included
in class diagram (at Design level).
 ‘+’ is used to denote public visibility (everyone)
 ‘#’ is used to denote protected visibility (friends and derived)

 ‘-’ is used to denote private visibility (no one)

By default, attributes are hidden and operations are visible.
7
 Objects

 An object is simply a real-world thing or concept

What are the three essential aspects of objects?

1. An object has an identity

 Can have a name or can be anonymous

2. An object has state

 The names of the various properties that describe the object (attributes) and also

the value of those attributes

3. An object has behaviour
 represented by functions (or methods) that use or change the values of the
8
 Classes

 Classes are the most important building block of any object-oriented system
Classes are used : -
 To capture the vocabulary of the system you are developing
 To 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
Class Name
attributes
operations

9
 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, Customer

 A class may be drawn showing only its name

Attribute
 An attribute is a named property of a class that describes a range of values that instances of the

property may hold

 It 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 10

 Attributes-----

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)
11
 Attributes-----

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

12
 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.
 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

13
 Customer TemperatureSen
sor
add()
remove() reset()
(a) edit() (b) setAlarm(t :
Temperature)
value() :
Operations define the behavior of the objects Temperature
 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

14
 Relationships
A relationship is, the logical or physical connections found on class diagrams.
 A Link is the basic relationship among objects-represented as a line connecting two
or more object boxes.
 A link is an instance of an association. In other words, it creates a relationship
between two classes.
 When we build abstractions, we will discover that very few classes stand alone
Therefore, when we model a system, we must
 Identify the things that form the vocabulary of our system (classes)

15
 Relationships------
 Model how these things stand in relation to one another
In UML, the ways that things can connect to one another, either logically or
physically, are modelled as relationships
In object-oriented modelling, there are three kinds of relationships that are most
important
1. Dependencies- represents ‘using’ relationship among classes
2. Generalizations
 Connects generalized classes to more specialized ones in what is known as
subclass/super-class or child/parent relationship (inheritance)

16
 Relationships------
3. Associations
 It represents structural relationships among instances/objects
Each of these relationships provides a different way of combining our abstractions
(classes).
The UML provides a graphical representation for each of these kinds of
relationships
 allows us to visualize relationships
 emphasize the most important parts of a relationship: its name, the things it
connects, and its properties
17
 A. Dependency

A dependency is a using relationship that states that a change in specification of one thing
(independent thing) may affect another thing that uses it (dependent thing), but not
necessarily the reverse
 It is rendered as a dashed directed line
dependent independent

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.

18
 A. Dependency------

To model dependency

 Create a dependency pointing from the class with the operation to the class used as a
parameter in the operation.
 Example: - A system that manages the assignment of students and instructors to courses
in a university

 There’s a dependency from CourseSchedule to Course, as Course is used in both the

add() and remove() operations of CourseSchedule
19
 B. Generalization
 It 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
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

20
 B. Generalization-----
Graphically, a generalization is rendered as a solid directed line
with a large open arrowhead, pointing to the parent

21
 B. Generalization--------
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.
 It can also create generalizations with packages

22
 B. 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

23
 B. Generalization--------
Example: - The Rectangle, Circle and Polygon classes inherits
from the attributes and operations of the Shape class

24
 C. Association

An association is a structural relationship that specifies that objects of one thing are

connected to objects of another

 We can navigate from an object of one class to an object of the other class, and vice

versa
Types of association: -

1. Unary Association- is where both ends of an association circle back to the same

class

2. Binary-Association-connects exactly two classes

3. Ternary Association-Connects more than two classes 25

 C. Association------
Graphically, an association is shown as a solid line connecting the same or different classes
There are 4 adornments that apply to associations:
1. 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)

26
 C. Association------
2. 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

27
 C. Association------
3. 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)
 Zero or one (0..1)
 Many (*)

28
 D. Aggregation
 It is a “whole-part” relationship within which one or more smaller class are
“part” of a larger “whole”
It represents a “has-a” relationship, whereby an object of the whole class has
objects of the part

29
 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

30
 Simple Example: To Model a Class Diagram

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. Each registered customer
has an account that is used to verify his/her ID and password. And Each registered
customer, upon account verification, can review one or more books based on its title.
The process given: -
 Each registered CUSTOMER has an ACCOUNT that is used to verify his/her
ID and password

31
 Simple Example: To Model a Class Diagram------

 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
1. Identify the things found in the problem
 Account
 Password
 Customer
 Book
 Review
32

 Simple Example: To Model a Class Diagram------

2. Define the responsibilities of each class

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
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
33
 Simple Example: To Model a Class Diagram------

Book
 Used to keep the relevant information on the book that is crucial to customer’s review, i.e. book
title, author, rating
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

34
 Simple Example: To Model a Class Diagram------

3. Translate the responsibilities for each class into attributes and operations needed to
perform those responsibilities.
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
35
 Simple Example: To Model a Class Diagram------

 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
Review
 Attributes: NONE
 Operations: NONE
CustomerReview
 Attributes: NONE
 Operations: assignRatings(rating : Int), computeAvgRating() : double
36
 Simple Example: To Model a Class Diagram------

EditorialReview
 Attributes: NONE
 Operations: NONE
4. Determine 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

37
 Simple Example: To Model a Class Diagram------

 Therefore, CustomerReview and EditorialReview is the subclass of Review

 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

38
5. Modelling the classes Diagram EditorialReview
Book
title : has
String Review
1 *

writes is written by CustomerReview

Customer
1 1..*
1
assignRating(rating : Int)
opens
computeAvgRating() :
1 Double
Account
emailAddress : string
ID : string Password
passwd : Password
pass : String
verifyPassword(p :
Password)
checkPasswor 39
 YO
U RR
EA
DIN
GA
SSI
GN
ME
NT
Object
Diagrams

40
 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
 You 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

41
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 named attribute1 = value anonymous

attribute2 = value object attribute2 = value object
42
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
You 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

43
Example: 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

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

published by

AW: Publisher
name : “Hawthorne”

Object diagram

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

published by

AW: Publisher
name : “Barnes”

Object diagram

46
 3. Sequences Diagram

Interaction Diagram:
Expressing How Things Work Together

47
 Modelling an Interaction
When modelling an interaction, we need to include
both objects and messages
1. Each object plays a specific role
2. Each message represents the communication between objects,
with some resulting action
These dynamic aspect may involve : -
 The interaction of any kind of instance in any view of
a system’s architecture, including instances of a class, interface,
components and nodes.
 A system as a whole, a subsystem, an operation or a class.
48
 Modelling an Interaction---------

An interaction diagram can be used in two ways: -

 To model flows of control by time ordering
Emphasizes the passing of messages as they unfold over time- Sequence
Diagram is used to model this
 To model flows of control by organization
Emphasizes the structural relationships among the instances in the
interaction, along which messages may be passed- Collaboration Diagram is
used to model this

49
 3. Sequences Diagram

A sequence diagram is an interaction diagram that emphasizes the time

ordering of messages
 Build sequence diagram for each use cases
But if you think that some use cases are clear to understand you may not need
to develop a sequence diagram, you need to explain this explicitly
 Sequence Diagram is used to visualize the logic inside use cases.
You built sequence diagrams or collaboration diagrams from the use-case and
class diagrams that were built before.

50
 3. Sequences Diagram----------

 Each use cases in a use-case diagram has its corresponding sequence or collaboration
diagram
 A sequence diagram has four key elements: -
1. Objects appear along the top margin
2. Lifeline, which is a dashed line that represent the life and perhaps death of the object
3. A focus of control, which is a tall thin rectangle that sits on top of an object’s lifeline
 It shows the period of time during which an object is performing an action, either directly
or through subordinate procedure
 The bottom part of a focus of control can be marked by a return message
4. Messages show the actions that objects perform on each other and on themselves.
 You model the diagrams
51 from the main flow of events, or the alternate flow of events, or
 3. Sequences Diagram======

 Every object that you have identified in the sequence or collaboration diagram,
MUST have its corresponding class in the class diagram
To Model a Sequence Diagram: -
 Set the context for the interaction
 Whether it is a system, subsystem, operation, class or a scenario of a use case or
collaboration
 Identify which objects play a role in the interaction
 Place them from left-to-right, at the top of the diagram
 Set the lifeline for each object

52
 Messages & Actions
 A message is a communication between two objects, or within an object, that is
designed to result in some activity.
This activity involves one or more actions, which are executable statements that
result in
 Changes in the values of one or more attributes of an object, or
The return of some value(s) to the object that sent the message, or both.
 There are 5 kinds of actions that the UML explicitly supports:
Call and Return
Create and Destroy
Send
53
A. Call Action: A call action invokes an operation on an object
It is synchronous, meaning that the sender assumes that the receiver is ready to accept the
message,
 And the sender waits for a response from the receiver before proceeding
The UML represents a call action as an arrow from the calling object to the receiving
object

: Class Object: Class A call action that involves

two objects
action name
A lifeline

action name
A call action from an
54 object to itself
B. Return Action
 A return action is the return of a value to the caller, in response to a call action
 The UML represents a return action as a dashed arrow from the object returning the
value to the object receiving the value

: Class Object: Class

return value

55
Example :- Call and Return action

: Customer : CustomerReview
assignRating()

computeAvgRating()

average rating

56
C. Create Action
A create action creates an object
 It tells a class to create an instance of itself
In the UML, create action is represented as an arrow with the stereotype <<create>> from the
object that invokes the create action to the created object

Object: Class : Class Object: Class

<<create>> <<create>>
: Class

Alternate Create Action notation

57
D. Destroy Action :A destroy action destroys an object
 It tells an object to destroy itself
 An object can perform a destroy action on another object, or on itself
 In the UML, a destroy action is represented as an arrow with the stereotype <<destroy>> from the object

that invokes the action to the destroyed object.

 A large X is also added at the end of the destroy arrow to denote that the object’s lifeline has been

terminated

Object: Class : Class

<<destroy>>
X

58
E. Send Action
 A send action sends a signal to an object
 A signal is an asynchronous communication between objects
 One object “throws” a signal to another object that “catches” the signal
 The sender of the signal does not expect a response from the receiver (unlike the sender of a call action)
 Exceptions are the most common type of signals
 In the UML, a send action is represented as an arrow with a half arrowhead at the lifeline of the
receiving object

: Class Object: Class

action name
59
 Modelling Sequence Diagram
Where is the starting point to built sequence diagrams or collaboration diagrams-
Use-Case and Class Diagrams.
 Each use cases in a use-case diagram has its corresponding sequence or collaboration
diagram
 You model the diagrams from the main flow of events, or the alternate flow of
events, or the scenarios, of each use case
 Every object that you have identified in the sequence or collaboration diagram,
MUST have its corresponding class in the class diagram.
Example: - Modelling a sequence diagram for the log-in use case from the on-line
Bookstore Case Study.
60
 Modelling Sequence Diagram --------
 The main-flow of events that are involved is: -
1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password. The CUSTOMER clicks the OK
button.
4. The system validates the log-in information against the ACCOUNT table in the database.
5. CUSTOMER is an authorised user; the system displays the Personal Home Page to the
CUSTOMER

61
 Modelling Sequence Diagram --------
 Actors: Customer
 Messages and Objects
1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password. The CUSTOMER clicks the
OK button.
4. The system validates the log-in information against the ACCOUNT table in the
database.
5. CUSTOMER is an authorised user; the system displays the Personal Home Page to
the CUSTOMER
62
 The Customer clicks the
:Customer :HomePage :LoginPage :Account
Login button on the Home
Page clickLogin( )

 The system displays the display( )

Login Page
 The Customer enters his or
enter userID
her user ID and password, and password

and then clicks the OK clickOK( )

validateLogin(userID
button.
, password)
 The system validates the
login OK
login information against the
display( )
persistent Account data and
then returns the Customer to
the Home Page.
Sequence Diagram
63
There are 3 types of analysis classes:
 Boundary Class
 Entity Class
 Control Class
 Instances of each of these analysis classes are called objects.
1. Boundary Objects
 is an object with which an actor associated with a use case interacts.
If the actor is human, the boundary object may be a window, screen, dialog box, or menu
If the actor is non-human, the boundary object may be Application Program Interfaces
(APIs)

64 Boundary Object
2. Entity Objects
 is an object that contains long-lived information, such as that associated with
databases.
will be mapped to a table (part of the database) in the design phase
 It can also contain transient objects, i.e. contents of lists in windows, or
search results.

Entity Object

65
3. Control Objects
 is an object that embodies (represents) application logic
 Correspond with system actions (not actions taken by actors)
 are often used to handle things such as coordination and sequencing
 are also useful for calculations involving multiple entity objects
Control Object
 will be mapped to codes during implementation phase
 used as a connecting tissue between boundary objects and entity objects.
Using the previous example (the log-in use case of the Online Bookstore), we can identify that:
 HomePage and Log-in Page objects are boundary objects,
 Account object is an entity object.
Therefore, taking this into account, we can draw a new Sequence diagram.

66
1. The Customer clicks the :Customer :HomePage :LoginPage :Account
Login button on the
Home Page clickLogin( )
2. The system displays the
display( )
Login Page
3. The Customer enters his
or her user ID and
enter userID
password, and then clicks
and password
the OK button
4. The system validates the clickOK( )
login information against validateLogin(userID
the persistent Account , password)
data …… and then login OK
returns the Customer to
the Home Page. display( )
.

67 Sequence Diagram
 Simple Example
On-line Bookstore is a web application that can be accessed by the store’s registered customer,
whereby each customer can order books, review one or more books sold in the book store, and
sell used books to other customers. Before performing any one of these transactions, the
customer must first log-in into the system using their user id and password kept in their account.

 Problem: Draw the sequence diagram for the above system.

From previous discussions, we know that the functional requirements for the Online Bookstore
can be seen from the use case diagram (as shown in the next slide)
 Each of the use cases in the use case diagram must have its corresponding interaction
diagram
 We will use the
68 scenarios in the ‘Main flow of events’ for each use case to model the
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out

Customer Order books

<<include>>

<<include>>
Sell used books Log-in

<<include>>

Use Case Functional Review books

Requirements
69 Diagram
 Use Case: Register
 Main flow of events:
1. The CUSTOMER clicks the REGISTER button on the
Home Page.
2. The system displays the Register Page.
3.The CUSTOMER enters all of the required information.
4. The CUSTOMER clicks the SEND button.
5. The system checks that all of the required information
were entered.
 If yes, the system update the CUSTOMER’s record in the
CUSTOMER and ACCOUNT tables in the database.
System displays OK message.
Objects:-
 CUSTOMER: actor
 CUSTOMER and ACCOUNT: Entity Objects
 Home Page and Register Page: Boundary Objects
70
 Register

:Customer :HomePage :RegisterPage

The customer clicks
the REGISTER button clickRegister( )
on the Home Page
The system displays
the Register Page display( )

The Customer enters

the required
information and enter information
then clicks the
SEND button.
clickSEND( ) verify info
The system checks
that all of the required
information were
entered. If yes, the <<create>>
system updates the :Account
CUSTOMER’s record
in the CUSTOMER <<create>>
and ACCOUNT tables display( ) :Customer
in the database. The
71
system displays OK
message
Use Case: Order Books
Main Flow of events: -
1. The CUSTOMER enters the keyword for a book and
clicks the SEARCH button on the personal Home Page.
2. The system displays the matching books on the web
Page.
3. The CUSTOMER chooses the desired book and clicks
the ADD TO SHOPPING CART button on the web
page.
4. The system adds the book into the CUSTOMER’s Order
table in the database.
Objects:
 Customer: actor
 Home Page: boundary object
 Book and Order: entity object

72
 Order books

:Customer :HomePage :Book :Order

The CUSTOMER
enters the keyword for
a book and clicks the enters keyword
SEARCH button on the
personal Home Page
clickSearch( )
search( )
The system displays
the matching books on displayMatch( )
the web Page
The CUSTOMER
chooses the desired
book and clicks the
ADD TO choose books
SHOPPING CART
button on the web clickAdd()
page.
<<create>>)
The system adds the
book into the
CUSTOMER’s Order
addBook( )
table in the database.
73
Use Case: Check-out
Main flow of events
1. The CUSTOMER clicks the Check out button on the Home Page
2. The system displays the books in the ORDER table of the
CUSTOMER on the web Page.
3. The CUSTOMER checks the order list for any inconsistency. If
nothing was found, CUSTOMER clicks the PROCEED button.
4. The system displays the Invoice page.
5. The Customer enters the relevant credit card information and clicks
OK.
6. The system checks that the credit card is valid. Then, the system
displays the Delivery Details page.
7. The CUSTOMER chooses destination for delivery, along with
delivery options. Then, he/she clicks the PROCEED button.
8. The system will display the check-out information for confirmation.
8. The CUSTOMER checks that all information is correct and then
clicks the OK button.
9. The system sends a confirmation via CUSTOMER’s e-mail.
Identify Objects: -
74
:Customer :HomePage :Order :InvoicePage :Customer :DeliveryPage
clickCheckOut( )
retrieve()
display( )

verify info
clickProceed( )
display( )

enter credit card info

clickOK()
validate( )

display( )

choose destination
clickOK()
display()
75
confirm and clickOK ()
Use case: Sell used books
 Main flow of events: -
1. The CUSTOMER clicks the Sell Used Books button on the
Home Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the
used books that he/she wants to sell.
4.The CUSTOMER clicks the SEND button on the webpage.
5.The system displays a confirmation page listing the
information that the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are
accurate. If yes, the CUSTOMER clicks the OK button on
the web page.
7. The system updates the USED BOOKS table in the
database.
Objects:
 Home Page, Used Books Page and Confirmation Page: boundary objects
 Customer and Used Books: entity objects
76
Sell used books

:Customer :HomePage :UsedBooksPag :ConfPage :Customer :UsedBook

e
clickUsedBooks( )

display( )

enter book info

clickSend( )
display( )

verify info
clickOK( )
add( )

add( )
77
Use case: Review
 Main flow of events: -
1. The CUSTOMER enters the keyword to search for a book and then
clicks the SEARCH button on the Personal Web Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER checks for the desired book and clicks
on the chosen book icon.
4. The system displays the book’s detail in the Book Detail
web page.
5. The CUSTOMER clicks the REVIEW button on the web page.
6. The system displays the Review Book web page.
7. The CUSTOMER clicks on the desired star button and the
click the OK button on the web page.
8. The system calculates the overall rating of the book and
updates the Book table in the database.
9. The system displays the Book Detail web pages that have
been updated.
Identify
78
all Objects and Draw the Sequence Diagram for the
above flow of events?
Activity Diagram

79
 Activity Modeling
 An activity diagram is a behavioral diagram that illustrates the flow of activities or actions within a system or

process.
 It is one of the Unified Modeling Language (UML) diagrams used to model the dynamic aspects of a system.

 Activity diagrams are particularly useful for modeling business processes, workflows, and system behaviors.

 They provide a visual representation of the sequence of actions, decision points, and concurrency within a

process.
 Activity diagrams describe the workflow behavior of a system.
 They are typically used for modeling:
 Business process,
 The logic captured by a single use case or usage scenario, or
 The detailed logic of a business rule.
 UML activity diagrams could potentially model the internal logic of a complex operation. 80
 4. Activity Modeling--------
Activity diagrams do not give detail about how objects behave or how objects
collaborate.
 Diagrams are read from top to bottom and have branches and forks to
describe conditions and parallel activities.
 A fork is used when multiple activities are occurring at the same time.
Activity diagrams show the sequence of activities in a process, including
sequential and parallel activities.
 Symbols are used for activities, decisions and so on.
 Arrows represent events that connect the activities.
81
82
 4. Activity Modeling--------
The diagram above shows a fork after activity1.
 This indicates that both activity2 and activity3 are occurring at the same time.
After activity2 there is a branch.
 The branch describes what activities will take place based on a set of conditions.
 All branches at some point are followed by a merge to indicate the end of the
conditional behavior started by that branch.
 After the merge all of the parallel activities must be combined by a join before
transitioning into the final activity state.

83
Activity Diagram Symbols

18-84
 Example:-Activity of performing selling an item to a
customer.

85
 Modeling Activity Diagrams
 Ask what happens first, second, and so on.
 Determine if the activities happen in sequence or parallel.
 Examine all the scenarios for a use case.
Swimlanes
 Included on activity diagrams to show partitioning
Show which activities:
 Occur on a browser
 Occur on a server
 Happen on a mainframe
 Are done by external partners
18-86

 Swimlane Boundaries

 When an event crosses swimlane boundaries, data must be transmitted.

 A Web form is sent to a server.

 Data are placed into middleware to transmit it between a server
and a mainframe.
 Data are transmitted to and from an external partner.

18-87
 More on Activity Diagrams

 An activity diagram is like a state diagram.

 Except most transitions are caused by internal events, such as the completion of a

computation.
 An activity diagram:

 Can be used to understand the flow of work that an object or component performs.
 Can also be used to visualize the interrelation and interaction between different use

cases.
 Is most often associated with several classes.

 One of the strengths of activity diagrams is the representation of concurrent

88
Activity diagrams – an example

89
 Representing concurrency

 Concurrency is shown using forks, joins and rendezvous.

1. A fork has one incoming transition and multiple outgoing
transitions.
–The execution splits into two concurrent threads.
2. A rendezvous has multiple incoming and multiple outgoing
transitions.
–Once all the incoming transitions occur all the outgoing
transitions may occur. 90
 Continued---

3. A join has multiple incoming transitions and one outgoing transition.

 The outgoing transition will be taken when all incoming transitions have

occurred.
 The incoming transitions must be triggered in separate threads.

 If one incoming transition occurs, a wait condition occurs at the join until

the other transitions occur.

Swimlanes
Activity diagrams are most often associated with several classes.

 The partition of activities among the existing classes can be explicitly shown using swimlanes.
91
Activity diagrams – an example with swimlanes

92
Note
• Activity diagrams are helpful for visualizing the sequence of steps in a
process, identifying decision points and parallel activities, and
understanding the overall flow of control. They are widely used in
software development, business process modeling, and system
analysis to document and communicate complex processes in a clear
and understandable manner.

93
 UI Prototyping
Is an iterative analysis task in which users are actually
participating in mocking up of the UI for a system
Steps
 Determine the need (from essential UI model which
was on a paper)
 Build the prototype using tools like HLL
 Consider the platform (web based – HTML or
Window based – VB)
 Evaluate the prototype
 By the SME
94