software Engineering

(CoSc3061)

Sem. II – 2023
Department of Computer Science
Chapter -2
UML
 An Overview of UML
What is modeling?

Modeling consists of building an abstraction of reality.

Abstractions are simplifications because:
They ignore irrelevant details and
They only represent the relevant details.
What is relevant or irrelevant depends on the purpose
of the model.
 An Overview of UML
Why model software?

Software is getting increasingly more complex

Windows XP > 40 mio lines of code
A single programmer cannot manage this amount
of code in its entirety.
Code is not easily understandable by developers who
did not write it
We need simpler representations for complex
systems
Modeling is a mean for dealing with complexity
 An Overview of UML
Why model software?

Once models of a system have been constructed,

these can be used for a variety of purposes during
software development, including :
• Analysis • Specification • Code generation • Design •
Visualize and understand the problem and the working
of a system • Testing, etc.
The UML models can not only be used to document
the results but also to arrive at the results themselves
 An Overview of UML
What is UML?
UML (Unified Modeling Language)
An emerging standard for modeling object-oriented software.
Resulted from the convergence of notations from three leading
object-oriented methods:
OMT (Object Management Technology James Rumbaugh)
OOSE (Ivar Jacobson)
Booch (Grady Booch)

It has successfully been used to model both large

and small problems
Supported by several CASE tools
Rational ROSE
Microsoft viso
TogetherJ
 Building Blocks of the UML

UML may be used to visualize, specify, construct, and

document the artifacts of a software system
It provides a set of notations (e.g. rectangles, lines,
ellipses, etc.) to create a visual model of the system
Like any other language, UML has its own syntax
(symbols and sentence formation rules) and semantics
(meanings of symbols and sentences)
UML is not a system design or development
methodology, but can be used to document object-
oriented and analysis results obtained using some
methodology.
 Building Blocks of the UML
UML Core Conventions
Rectangles are classes or instances
Ovals are functions or use cases
Instances are denoted with an underlined names
myWatch:SimpleWatch
Joe:Firefighter
Types are denoted with non underlined names
SimpleWatch
Firefighter
Diagrams are graphs
Nodes are entities
Arcs are relationships between entities
 Diagrams in the UML

UML can be used to construct nine different types of diagrams to

capture five different views of a system
The UML diagrams can capture the following five views of a
system:
User’s view
Structural view
Behavioral view
 Implementation view
 Environmental view
 Diagrams in the UML
Use case Diagrams
Describe the functional behavior of the system as seen by the user.
Class diagrams
Describe the static structure of the system: Objects, Attributes,
Associations
Sequence diagrams
Describe the dynamic behavior between actors and the system and
between objects of the system
Statechart diagrams
Describe the dynamic behavior of an individual object (essentially a
finite state automaton)
Activity Diagrams
Model the dynamic behavior of a system, in particular the
workflow (essentially a flowchart)
Implementation diagrams
Component diagrams
Deployment diagrams
 Use Case Diagrams
Use cases are used during requirements
elicitation and analysis to represent the
functionality of the system
use cases represent the different ways in which a
system can be used by the users
A simple way to find all the use cases of a
system is to ask the question: “What the
users can do using the system?”
It represent the functionality of the system
from a user’s point of view. They define the
boundaries of the system
 Use Case Diagrams

Used during requirements

elicitation to represent external
behavior

Actors represent roles, that is, a

Passenger type of user of the system
Use cases represent a sequence
of interaction for a type of
functionality
The use case model is the set of
PurchaseTicket all use cases. It is a complete
description of the functionality of
the system and its environment
 Use Case diagrams/Actors

An actor models an external entity

which communicates with the system:
User
External system
Physical environment
Passenger
An actor has a unique name and an
optional description.
Examples:
Passenger: A person in the train
GPS satellite: Provides the system with
GPS coordinates
 Use case Diagrams/ Use Case
A use case represents a class of functionality provided
by the system as an event flow.
A use case consists of six fields:
• Unique name: The name of the use case is uniquePurchaseTicket across the system so that
developers (and project participants) can unambiguously refer to the use case

• Participating actors: are actors interacting with the use case.

• Entry conditions: describe the conditions that need to be satisfied before the
use case is initiated.
• Flow of events: describes the sequence of actions of the use case, which are
be numbered for reference
• Exit conditions: describe the conditions that are satisfied after the
completion of the use case
• Special requirements: are requirements that are not related to the
functionality of the system
 Use Case Diagram: Example
Name: Purchase ticket Event flow:
1. Passenger selects the number
Participating actor: Passenger of zones to be traveled.
2. Distributor displays the amount
Entry condition: due.
• Passenger standing in front of 3. Passenger inserts money, of at
ticket distributor. least the amount due.
• Passenger has sufficient 4. Distributor returns change.
money to purchase ticket. 5. Distributor issues ticket.

Exit condition: Anything missing?

• Passenger has ticket.
Exceptional cases!
 Use Case Diagrams: relationship
Use case diagrams can include four types of relationships:
Communication : Actors and use cases communicate when information is
exchanged between them. Communication relationships are depicted by a solid line
between the actor and use case symbol

 Inclusion :We reduce the complexity of the model by identifying commonalities in

different use cases.

 Extension : A use case can extend another use case by adding events , it allows
you to show optional system behavior

Generalization: are a third mechanism for reducing the complexity of a

model. A use case can specialize a more general one by adding more detail.
 The <<extends>> Relationship
<<extends>> relationships
represent exceptional or seldom
invoked cases.
Passenger The exceptional event flows are
factored out of the main event
flow for clarity.
Use cases representing
PurchaseTicket exceptional flows can extend
more than one use case.
<<extends>> The direction of a <<extends>>
relationship is to the extended
<<extends>> use case
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
 The <<includes>> Relationship

<<includes>> relationship
represents behavior that is
Passenger factored out of the use case.
identifying commonalities in
different use cases
PurchaseMultiCard
<<includes>> behavior is
PurchaseSingleTicket factored out for reuse, not
<<includes>> because it is an exception.
<<includes>> The direction of a
<<includes>> relationship is to
the using use case (unlike
CollectMoney <<extends>> relationships).
<<extends>> <<extends>>

NoChange Cancel
 Use Case Diagrams: Summary
Use case diagrams represent external behavior
Use case diagrams are useful as an index into the use cases
Use case descriptions provide meat of model, not the use
case diagrams.
All use cases need to be described for the model to be
useful.
 Class Diagrams
Class diagrams describe the structure of
the system in terms of classes and objects
A class is a definition of objects that
share the same properties, relationships
and behavior.
An object is an instance of a class.
The properties of a object are called
attributes and the behavior is
expressed in operations.
 Class Diagrams
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/distinct
boundaries and form a part of a balanced distribution
of responsibilities across the system
 Class Diagrams
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

TarifSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TarifSchedule

A class represent a concept

A class encapsulates state (attributes) and behavior (operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information.
 Class Diagrams/Instance

tarif_1974:TarifSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

An instance represents a phenomenon.

The name of an instance is underlined and can contain the class of the
instance.
The attributes are represented with their values.
 Class Diagrams/ Relationships
Association
Associations are needed to enable objects to communicate with each
other .
An association describes a connection between classes.
The association relation between two objects is called object connection
or link .
Association between two classes is represented by drawing a straight
line between the concerned classes.
The name of the association is written alongside the association line.
An arrowhead may be placed on the association line to indicate the
reading direction of the association.
 Class Diagrams/ Relationships
Association/ multiplicity
On each side of the association relation, the multiplicity is noted as an
individual number or as a value range.
The multiplicity indicates how many instances of one class are
associated with each other.
Value ranges of multiplicity are noted by specifying the minimum and
maximum value, separated by two dots.
 Class Diagrams/ Relationships
Association/ multiplicity
1-to-1 and 1-to-many Associations

Country Has-capital City

name:String name:String

One-to-one association

Point
Polygon
* x: Integer

y: Integer
draw()

One-to-many association
 Class Diagrams/ Relationships
Association/ multiplicity
Many-to-Many Associations

Lists

StockExchange * * Company

tickerSymbol
 Class Diagrams/ Relationships
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

27
 Class Diagrams/ Relationships
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

28
 Class Diagrams/ Relationships
Cont…
Graphically, a generalization is rendered as a
solid directed line with a large open
arrowhead, pointing to the parent
ParentClass

ChildClass
attributes
operations
29
 Class Diagrams/ Relationships
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
30 each specialized class to its more-general parent
 Class Diagrams/ Relationships
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()

3
1
 Class Diagrams/ Relationships
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
32
 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

3
3
 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

3
4
 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)
3
5
 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

3
6
 Things that are found in the
problem: -
Account
Password
Customer
Book
Review
can be divided into CustomerReview and
EditorialReview
3
7
 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
3
8
 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

3
9
 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
4
0
 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)
4 Book
1
 Review
Attributes:NONE
Operations: NONE

CustomerReview
Attributes: NONE

Operations: assignRatings(rating : Int),

computeAvgRating() : double
EditorialReview
Attributes: NONE

Operations: NONE
4
2
 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

4
3
 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
4
4
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()
4
5
 Summary

basic, 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
4
6
 Sequence Diagrams

In every system, objects do not just sit idle;

they interact with one another by passing
messages.
In the UML, the dynamic aspects of a system
is modelled using interactions
An interaction sets the stage for its behaviour by
introducing
all the objects that work together to carry out some
action,
the messages that are dispatched from object to object
 Sequence Diagrams

Used during requirements analysis

To refine use case descriptions
to find additional objects (“participating objects”)
Used during system design
to refine subsystem interfaces
Classes are represented by columns
Messages are represented by arrows
Activations are represented by narrow rectangles
Lifelines are represented by dashed lines
 Sequence Diagrams
A sequence diagram is an interaction diagram
that emphasizes the time ordering of
messages
A sequence diagram is formed by: -
 Placing the objects that participate in the interaction at
the top of the diagram, along the X-axis
 The object that initiates the interaction is placed on the left
most, and the other subordinate objects are placed to the right
Placing the messages that these objects send and receive
along the Y-axis, in order of increasing time from top to
bottom
 Sequence Diagrams

A sequence diagram has four key elements:

Object, Lifeline, Focus of Control and
Message
Objects appear along the top margin
Each object has a lifeline, which is a
dashed line that represent the life and
perhaps death of the object
Most objects will be in existence for the
duration of the interaction
Objects may also be created or destroyed
during the interaction
 Sequence Diagrams

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
Messages show the actions that
objects perform on each other and on
themselves
 Sequence Diagrams
We built sequence diagrams or collaboration
diagrams from the use-case and class diagrams that
were built before.
Each use cases in a use-case diagram has its
corresponding sequence or collaboration
diagram
We 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 we have identified in the
sequence or collaboration diagram, MUST have
its corresponding class in the class diagram
 Sequence Diagrams
Example: - Modelling a sequence diagram for the log-in
use case from the on-line Bookstore Case Study.
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
 Sequence Diagrams

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.
5. The system validates the log-in information against the
ACCOUNT table in the database.
6. CUSTOMER is an authorised user; the system displays
the Personal Home Page to the CUSTOMER
 :Customer :HomePage :LoginPage :Account
The Customer clicks
the Login button on clickLogin( )
the Home Page

The system displays

display( )
the Login Page

The Customer enters

his or her user ID
and password, and enter userID and password
then clicks the OK
button. clickOK( )
validateLogin(userID,
The system validates password)
the login information
against the persistent login OK
Account data
display( PersonalPage)
The system then
returns the Customer
to the Home Page.

55 Login Sequence Diagram

 Robustness Analysis
Sometimes when drawing an interaction
diagram, we may be confused about the
objects that are involved.
Because each object that we use in an
interaction diagram MUST have its
corresponding classes in the class diagram, we
may find ourselves in a situation where we
have already determined the objects that are
needed in an interaction diagram but the
objects do not have their corresponding
classes in our class diagram.
56
Robustness analysis involves analysing the
text of a use case and identifying a first-
guess set of objects that will participate in
the use case, and then classifying these
objects based on their characteristics.
It involves defining analysis classes
There are 3 types of analysis classes:
boundary classes
entity classes
control classes
Instances of each of these analysis classes are
57called objects.
Boundary Objects
is an object with which an actor
associated with a use case interacts. (More
of Interfacing)
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)
boundary object

58
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 temporary objects, i.e.
contents of lists in windows, or search
results. entity object

59
Control Objects
is an object that embodies 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
will be mapped to codes during implementation
phase
used as a connecting tissue between boundary
objects and entitycontrol
objects .
object
60
Using the previous example (the log-in
use case of the Online Bookstore), we
can identify that
the HomePage and Log-in Page objects
are boundary objects,
whereas the Account object is an entity
object.
Therefore, taking this into account, we
can draw a new interaction diagram.

61
 :Customer :HomePage :LoginPage :Account

The Customer clicks

clickLogin( )
the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK clickOK( )
button. validateLogin(userID,
password)
The system validates
the login information login OK
against the persistent
Account data
display( )

The system then

returns the Customer
to the Home Page.

62 Login Sequence Diagram

 Summary
No single interaction diagram can capture
everything about a system’s dynamic aspect
may need to use many interaction diagrams
to model the dynamic aspects of a system as
a whole, as well as its subsystem,
operations, classes, use cases and
collaborations.

63
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

64
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 scenarios in the ‘Main flow of
events’ for each use case to model the interaction
diagram

65
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out

Order books
<<include>>

Customer
<<include>>
Sell used Log-in
books

<<include>>

Review books

66 Use Case Functional Requirements Diagram

 Log-in

:Customer :HomePage :LoginPage :Account

The Customer clicks

clickLogin( )
the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK clickOK( )
button. validateLogin(userID,
The system validates password)
the login information
against the persistent login OK
Account data …
display( )
… and then returns the
Customer to the Home
Page.
67
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

68
 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 then enter information
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.
69 The
system displays OK
message
Case Study: 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
70
 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.
71
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.
7. The CUSTOMER checks that all information is correct and then clicks the
OK button.
8. The system sends a confirmation via CUSTOMER’s e-mail.
Objects: -
Home Page, Invoice Page and Delivery Page: boundary objects
Customer and Order: entity objects
72
:Customer :HomePage :Order :InvoicePage :Customer :DeliveryPage
clickCheckOut( )
retrieve()
display( )

verify info
clickProceed( )
display( )

enter credit card info

clickOK()
validate( )

display( )

choose destination
clickOK()
display()
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:
HomePage, UsedBooksPage and ConfirmationPage: boundary objects
Customer and Used Books: entity objects

74
:Customer :HomePage :UsedBooksPage :ConfPage :Customer :UsedBook

clickUsedBooks( )

display( )

enter book info

clickSend( )
display( )

verify info
clickOK( )
add( )
add( )
75
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.
Objects?
Diagram?
76
 State chart Diagrams
A state chart diagram is normally used to model
how the state of an object changes in its lifetime
State chart diagrams are good at describing how
the behavior of an object changes across several
use case executions
A state chart is a hierarchical model of a system
and introduces the concept of a composite state
(also called nested state).
The basic elements of the state chart diagram
are as follows:
Initial state- This is represented as a filled circle.
Final state- This is represented by a filled circle inside a larger circle
State- These are represented by rectangles with rounded corners.
 Transition- A transition is shown as an arrow between two states.
 State chart Diagrams
An example state chart for the order object of the Trade House Automation
software
 Activity Diagrams

Activity diagrams describe the workflow behavior

of a system.
They are typically used for business process
modeling, for modeling the logic captured by a
single use case or usage scenario, or for modeling
the detailed logic of a business rule.
UML activity diagrams could potentially model the
internal logic of a complex operation.
In many ways UML activity diagrams are the
object-oriented equivalent of flow charts.
 Activity Diagrams
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.
Activity Diagrams
 Cont…
The diagram on previous slide 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.

8
2
 Cont…
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.

8
3
 Example to illustrate the activity of performing selling an
item to a customer.

8
4
 Creating 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.

885
5
 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
Help to divide tasks among team members

886
6
 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.
87
 Swimlanes
Activity diagrams are most often associated
with several classes.
The partition of activities among the
existing classes can be explicitly shown
using swimlanes.

88
 Activity diagrams – an example with
swimlanes

89
 Component Diagram
A component diagram describes the organization of the physical components
in a system.
Basic Component Diagram Symbols and Notations

Component
A component is a physical building block of
the system. It is represented as a rectangle
with tabs.

Interface
An interface describes a group of operations
used or created by components.

Dependencies
Draw dependencies among components
using dashed arrows.
 Component Diagram
Component Diagram For Library Management System

Component diagram is essentially class diagram that focus on a system’s component.

 Deployment Diagram
Deployment diagrams depict the physical resources in a system including
nodes, components, and connections.

Basic Deployment Diagram Symbols and Notations

Node
A node is a physical resource that
executes code components

Association
Association refers to a physical connection
between nodes, such as
Ethernet.

Components and Nodes

Place components inside the node that
deploys them.
 Deployment Diagram
Deployment Diagram For Library Management System

The deployment diagram captures the configuration of the run time

element of the application
 UML Summary

UML provides a wide variety of notations for representing

many aspects of software development
Powerful, but complex language
Can be misused to generate unreadable models
Can be misunderstood when using too many exotic features

For now we concentrate on a few notations:

Functional model: Use case diagram
Object model: class diagram
Dynamic model: sequence diagrams, statechart and activity
diagrams