1

CONTENTS

Problem statement
ANALYSIS
Use case view
Identification of Actors.
Identification of Use cases and sub use cases.
Flow of Events.
Construction of Use case diagram.
Build a business process model using Activity diagram.
Logical view
Identification of Analysis classes.
Identification of attributes of classes.
Class - Attributes, operations & Relationships.
Construction of UML static Class diagram
Construction of Sequence diagrams.
Construction of Collaboration diagrams
Constructing UML state chart diagram.
DESIGN
Component view
Construction of component diagram.
Deployment view
Construction of deployment diagram.
ADVANTAGES OF UML
 2

PROBLEM: Library System

ANALYSIS
USE CASE VIEW
2. Identification of Actors:

ACTOR: An actor is anything that interacts with a use case: human user, external hardware,
or another system. The term actor represents the role a user plays with respect to the system.
The actor in a system is represented as below.

NewClass

fig 1: Representation of actor

We have to identify the actors and understand how they will use and interact with the
system. Candidates for actors can be found through the answers to the following questions:
1. Who is interested in certain requirement?
2. Who will benefit from the use of the system?
3. Who will supply the system with this information, uses this
information and removes this information?
4. Who will support and maintain the system?
5. Does the system use an external resource?
6. Does one play several different roles?
7. Does several people play the same role?

3. Identification of Use Cases:

Use case:
A use case is a sequence of transactions in which each transaction invoked from
outside the system and engages internal objects to interact with one another and with in the
systems surroundings.
A use case describes the courses of events that will be carried out by the system. In its
simplest form, a use case can be described as a specific way of using the system from a user’s
(actor’s) perspective. A more detailed description might characterize a use case as:
 3

 a pattern of behavior the system exhibits

 a sequence of related transactions performed by an actor and the system
 delivering something of value to the actor

Use cases provide a means to:

 capture system requirements
 communicate with the end users and domain experts
 test the system
Graphical Depiction:
The basic shape of a use case is an ellipse:

NewUseCase

fig5: use case

The steps for finding use Cases:

1 For each actor, find the tasks and functions that the actor should be able to perform or
that the system needs the actor to perform. The use case should represent a course of
events that leads to a clear goal.
2 Name the use cases.
3 Describe the use cases briefly by applying terms with which the user is familiar. This
makes the description less ambiguous.

Naming a Use Case

Use case names should provide a general description of the use case function. The
name should express what happens when an instance of the use case performed. The
description of the use case should be descriptive and consistent.
 4

4. Flow of events:
A flow of events is a sequence of transactions performed by the system. They
typically contain very detailed information, written in terms of what the system should do,
not how the system accomplishes the task. Flow of events are created as a separate files or
documents is your favorite text editor and then attached or linked to use case using the files
tab of a model element. A flow of events should include:
1 When and how the use case starts and ends?
2 Use case/ actor interactions?
3 Data needed by the use case?
4 Normal sequence of events for the use case?
5 Alternate or exceptional flows?

5. Construction of Use Case diagram:

A use – case diagram is a graph of actors, a set of cases enclosed by a system
boundary, communication associations between the actors and the use cases, and
generalization among the use cases. A use case diagram shows the relationship among the
actors and use cases within system.

login manage user

browse manage titles

verify the list

manage items librarian

reserve the book

user identify browser

collect the book

manage librarian Master

librarian
cancel reservation

return the book

 5

6. Business process model using activity diagram:

An activity diagram is a variation or special case of a state machine, in which the
states are activities representing the performance of operations and the transitions are
triggered by the completion of the operations. Unlike state diagrams that focus on the events
occurring to a single object as it responds to messages, an activity diagram can be used to
model an entire business process. The purpose of an activity diagram is to provide a view of
flows and what is going on inside a use case or among several classes. However, activity
diagram can also used to represent a class’s method implementation.

An activity model is similar to a state chart diagram, where a token represents an

operation. An activity is shown as a round box, containing the name of the operation. When
an operation symbol appears within an activity diagram or other state diagram, it indicates the
execution of the operation. Executing a particular step within the diagram represents a state
within the execution of the overall method. An outgoing solid arrow attached to an activity
symbol indicates a transition triggered by the completion of the activity. The name of this
implicit event need not be written, but the conditions that depend on the result of the activity
or other values may be included. Several transitions with different conditions imply a
branching off of control.

An activity diagram is used mostly to show the internal state of an object, but external
events may appear in them. An external event appears when the object is in a “waits state”, a
state during which there is no internal activity by the object and the object is waiting for some
external event to occur as the result of an activity by another object. The two states are wait
state and activity state. More then one possible event might take the object out of the wait
state; the first one that occurs triggers the transition. A wait state is the “normal” state.

Activity diagrams express a decision when conditions are used to indicate different
possible transitions that depend on Boolean conditions of container object. The figure
provided for a decision is the traditional diamond shape, with one or more incoming arrows
and two or more outgoing arrows, each labeled by a distinct guard condition. All possible
outcomes should appear on one of the outgoing transitions.
You can attach activity diagrams to most model elements in the use case or logical
views. Activity diagrams cannot reside within the component view.
 6

Naming
The name of an activity must be unique and should declare the activity’s purpose. All
activity icons with the same name on an activity diagram represent the same activity.

Activity Diagram Tools:

You can use the following tools on the activity diagram toolbox to model activity diagrams:
 Activities
 Decisions
 End State
 Object
 Object Flow
 Start State
 States
 Swim lanes
 Synchronizations
 Transitions
The activity icon appears as a rectangle with rounded ends with a name (Take Order and
Process Order) and a compartment for actions:
Activity:
It is an ongoing non-atomic execution within a state machine.
Activities ultimately result in some action, which made up of executable atomic
computations.
Object:
An object has state, behavior, and identity. The structure and behavior of similar objects are
defined in their common class. Each object in a diagram indicates some instance of a class.
An object that is not named is referred to as a class instance.
Object flow:
It is useful to see the relationships between an operation and the objects that are its argument
values or results. The input to and outputs from an operation may be shown as an object flow
state.
State:
Is a condition/situation during the life of an object during which it satisfies some condition,
performs some activity, or waits for some event.
 7

Transition:

Is a relationship b/w two states indicating that an object in the 1 st state will perform certain

actions and enter the 2nd state when a specified event occurs and specified conditions are
satisfied.
On such a change of state, the transition is said to fire.
End State
An end state represents a final or terminal state on an activity diagram or state chart diagram.
Place an end state when you want to explicitly show the end of a workflow on an activity
diagram or the end of a state chart diagram. Transitions can only occur into an end state;
however, there can be any number of end states per context. You can label end states, if
desired. State Specifications are associated with each end state.
The end state icon is a filled circle inside a slightly larger unfilled circle that may contain a
name (End Process):
Start State
A start state (also called an "initial state") explicitly shows the beginning of a workflow on an
activity diagram or the beginning of the execution of a state machine on a state chart diagram.
You can have only one start state for each state machine because each workflow/execution of
a state machine begins in the same place. When you model nested states or nested activities,
one new start state can be created in each context. The start state icon is a small, filled circle
that may contain a name (Begin Process):
Swim lanes
Swim lanes are very similar to an object because they provide a way to tell who is performing
a certain role. Swim lanes only appear on activity diagrams. You should place activities
within swim lanes to determine which unit is responsible for carrying out the specific
activity.
When a swim lane is dragged onto an activity diagram, it becomes a swim lane view.
Synchronizations:
Synchronizations enable you to see a simultaneous workflow in an activity diagram or state
chart diagram. Synchronizations visually define forks and joins representing parallel
workflow.
 8

Forks and Joins

A fork construct is used to model a single flow of control that divides into two or more
separate, but simultaneous flows. A corresponding join should ideally accompany every fork
that appears on an activity diagram. A join consists of two of more flows of control that unite
into a single flow of control. All model elements (such as activities and states) that appear
between a fork and join must complete before the flow of controls can unite into one.

login

browse for
book

search
another book

issue the leave the

book library

7. Identification of Analysis Classes:

A class is a set of objects that share a common structure and common behavior (the
same attributes, operations, relationships and semantics). A class is an abstraction of real-
world items. When these items exist in the real world, they are instances of the class and
referred to as objects.
The following four approaches are used for identifying classes:
1. The noun phrase approach.
2. The common class patterns approach.
 9

3. Use Case driven approach.

4. Sequence/collaborators approach.

8. Identify the Responsibilities of Classes:

Classes, responsibilities, and collaborators is a technique used for identifying classes,
Responsibilities, and Collaborators can help us identify classes. Classes, Responsibilities, and
Collaborators is based on the idea that an object either can accomplish a certain responsibility
itself or it may require the assistance of other objects.. If it requires the assistance of other
objects, it must collaborate with those objects to fulfill its responsibility.

The Classes, Responsibilities, and Collaborators process consists of three steps

1. Identify classes’s responsibilities.
2. Assign responsibilities.
3. Identify collaborators.

9. Construction of Sequence Diagrams:

A sequence diagram is a graphical view of a scenario that shows object interaction in
a time-based sequence-what happens first, what happens next. Sequence diagrams establish
the roles of objects and help provide essential information to determine class responsibilities
and interfaces. A sequence diagram has two dimensions: the vertical dimension represents
time; the horizontal dimension represents different objects. The vertical line is called the
object’s lifeline. The lifeline represents the object’s existence during the interaction.
Jacobson popularized this form. An object is shown as a box at the top of a dashed vertical
line. A role is a slot for an object within a collaboration that describes the type of object that
may play the role and its relationships to other roles. However, a sequence diagram does not
show the relationships among the roles ort eh association among the objects. An object role is
shown as a vertical dashed line, the lifeline.
An arrow between the lifelines of two objects represents each message. The
order in which these messages occur is shown top to bottom on the page. Each message is
labeled with the message name. The label also can include the argument and some control
information and show self-delegation, a message that an object sends to itself, by sending the
message arrow back to the same lifeline. The horizontal ordering of the lifelines is arbitrary.
Often, call arrows or arrange to proceed in one direction across the page, but this is not
always possible and the order conveys no information.
 10

The sequence diagram is very simple and has immediate visual appeal---this is
its great strength. A sequence diagram is an alternative way to understand the over all flow of
control of a program. Instead of looking at the code and trying to find out the over all
sequence of behavior.
The following tools located on the sequence diagram toolbox, which enable to model
sequence diagram:
1. Object: An object has state, behavior and identity. The structure and behavior of
similar objects are defined in their common class. Each object in a diagram indicates
some instance of a class. An object that is not named is referred to as a class instance.
2. Message Icons: A message icon represents the communication between objects
indicating that an action will follow. The message icon is horizontal, solid arrow
connecting two-life line together.
3. Focus of Control: Focus of control (FOC) is an advanced notational technique that
enhances sequence diagram. It shows the period of time during which an object is
performing an action, either directly or through an underlying procedure.
4. Message to Self: A message to self is a tool that sends a message from one object
back to the same object. The sender of a message is the same as the receiver.
5. Note: A note captures the assumptions and decisions applied during analysis and
design. Notes may contain any information, including plain text, fragments of code, or
references to other documents.
6. Note Anchor: A note anchor connects a note to the element that it affects.
 11

:Member :Librarian :student issue :Title :Book

register
1: Request book
2: validate/ find borrowing limit

3: valid /borrow limit ok

4: find availability

5: availability ok

6: update issue details

7: update issue details

8: update available copy

9: issue book

10. Construction of Collaboration Diagrams:

Collaboration diagram is an interaction diagram that shows the order of
messages that implement an operation or transaction. Another type of interaction diagram is
the collaboration diagram. A collaboration diagram is a set of objects related in a particular
context, and interaction, which is a set of messages exchanged among the objects within
collaboration to achieve a desired outcome. In a collaboration diagram, objects are shown in
figures. As in a sequence diagrams, arrows indicate the message sent within the given use
case. In a collaboration diagram, numbering the messages indicates the sequence. Some
people argue that numbering the messages makes it more difficult to see the sequence than
drawing the lines on the page. However, since the collaboration diagram is more compressed,
other things can be shown more easily. A collaboration diagram provides several numbering
schemes.
Two types of Numbering Sequences are:
1. Flat Sequence
2. Decimal Sequence

The disadvantage of interaction diagrams is that they are great only for
representing a single sequential process; they begin to break down when you want to
 12

represent conditional looping behavior. However, conditional behavior can be

represented n sequence or collaboration diagrams for each scenario.

The main guideline in developing interaction diagrams is simplicity. The

interaction diagram uses its clarity with more complex conditional behavior. An
interaction basically is used to examine the behavior of objects within a single use case. It
is good at showing collaboration among the objects but not so good at precise definition
of the behavior.

Difference between sequence and collaboration:

 Sequence diagram show time based object interaction while collaboration

diagram shows how objects associate with each other.
 Sequence diagrams are easier to read.
 Collaboration diagrams use the layout to indicate how objects are statically
connected.
 The create collaboration diagram command creates a collaboration diagram
from information contained in the sequence diagram. The create sequence diagram
command creates a sequence diagram from information contained in the interaction
collaboration diagram.
 13

7: update issue details

1: Request book 2: vlidate
:member :Librarian :student issue register

9: issue book 3: valid

4: find availability
8: update avilable copy 6: update issues

:title :book
5: avilable ok

11. Identification of Attributes of Classes:

Attribute:
An attribute is the description of a named slot of a specified type in class; each object of a
class separately holds a value of the type.
Guidelines for identifying attributes of classes are as follows:
1. Attributes usually correspond to nouns followed by prepositional phrases. Attributes
also may correspond to adjectives or adverbs.
2. Keep the class simple; state only enough attributes or adverbs.
3. Attributes are less likely to be fully described to define the object state.
4. Omit derived attributes.
5. Do not carry discovery attributes to excess.
6. The following questions help in identifying the responsibilities of classes and
deciding what data elements to keep track
7. What information about an object should we keep track of?
8. What services must a class provide?
 14

12. Identification of Relationships Among Classes:

The relationship among objects is based on the assumptions each makes about
other objects, including what operations can be performed and what behavior results.
Three types of relationships among objects are

Association:
Association represents a physical or conceptual connection between two or more
objects. The binary associations are shown as lines connecting two class symbols.
Ternary and higher – order associations are shown as diamonds connecting to a class
symbol by lines, and the association name is written above or below the line.
Identifying Associations:
Identifying associations begins by analyzing the interaction between classes. After
all, any dependency relationship between two or more classes is an association. You must
examine the responsibilities to determine dependencies. If an object is responsible for a
specific task and lacks all the necessary knowledge needed to perform the task, then the
object must delegate the task to another object that possesses such knowledge. The
following questions that can help us to identify associations.

 Is the class capable of fulfilling the required task by itself?

 If not, what does it need?
 From what other class can it acquire what it needs?
Super – Sub Class Relationships
A class s part of a hierarchy of classes, where the top class is the most general one and
from it descends all other, more specialized classes. The super-sub class relationship
represents the inheritance relationships between related classes, and the class hierarchy
determines the lines of inheritance between classes. Class inheritance is useful for number of
reasons. you want to create a number of classes that are similar in all but a few
characteristics. I versions of their super classes.
Guidelines For Identifying Super-Sub relationship, A Generalization:
The following are guidelines for identifying super-sub relationships in the application:
 15

Top down: Look for noun phrases composed of various adjectives in a class name. Avoid
excessive refinement. Specialize only when the subclasses have significant behavior.
Bottom-up: Look for classes with similar attributes or methods. In most cases, you can group
them by moving the common attributes and methods to an abstract class.
Reusability: Move the attributes and behaviors as high as possible in the hierarchy. At the
same time, do not create very specialized classes at the top of hierarchy. This is easier said
than done.
Multiple inheritances: Avoid excessive use of multiple inheritances. Multiple inheritance
brings with it complications such as how to determine which behavior to get from which
class, particularly when several ancestors define the same method. It also more difficult to
understand programs written in a multiple inheritance system. One way of achieving the
benefits of multiple inheritances is to inherit from the most appropriate class and add an
object of another class as an attribute.

A-Part – Of Relationships – Aggregation

A – part – of relationship, also called aggregation, represents the situation here a
class consists of several component classes. A class that is composed of other classes does
not behave like its parts; actually it behaves very differently. Two major properties of a part –
of – relationship are transitivity and ant symmetry. The following questions are used to
identify the responsibilities.
1. Does the part class belong to a problem domain?
2. Is the a part class within the system’s responsibilities?
3. Does the a part class capture more than a single value?
4. Does it provide a useful abstraction in dealing with the problem domain?

A – Part – Of Relationship Patterns:

To identify a – part – of structures, Cord and Yourdon provide the following
guidelines.
Assembly: An assembly is constructed from its parts and an assembly- part situation
physically exists.
Container: A physical whole encompasses but is not constructed from physical parts.
 16

Collection - member: A conceptual whole encompasses parts that may be physical or

conceptual.

14. Construction of UML Static Class Diagram:

The UML class diagram, also refereed to as object modeling, is the main static
analysis diagram. These diagrams show the static structure of the model. A class diagram a
collection of static modeling elements, such as classes and their relationships, connected as
graph to each other and to their contents. Class diagram do not show temporal information,
which is required in dynamic modeling.

 Shows a set of classes, interfaces and collaborations and their relationships.

 Class diagrams address the static design view of a system.
 Class diagrams that include active classes address the static process view of a system.
Object modeling is the process by which the logical objects in the real world are represented
by the actual objects in the program. To effectively develop a model of the real world and to
determine the objects required in the system, you first must ask what objects are needed to
model the system. Answering the following questions will help you to stay focused on the
problem at hand and determine what is inside the problem domain and what is outside it:
 What are the goals of the system?
 What must the system accomplish?

A class diagram is a picture for describing generic descriptions of possible systems. Class
diagrams and collaboration diagrams are alternate representations of object models. Class
diagrams contain classes and object diagrams contain objects, but it is possible to mix classes
and objects when dealing with various kinds of metadata, so the separation is not rigid.
Class diagrams are more prevalent than object diagrams. Normally you will build
class diagrams plus occasional object diagrams illustrating complicated data structures or
message-passing structures.
Attribute:
An attribute is the description of a named slot of a specified type in class; each object of a
class separately holds a value of the type.
Method:
 17

The implementation of an operation. It specifies the algorithm or procedure that

produces the results of an operation.

Relationship:
The relationship among objects is based on the assumptions each makes about
other objects, including what operations can be performed and what behavior results.
Three types of relationships among objects are

 Association
 Generalization
 Aggregation
13.Analyzing the Object Behavior By Constructing UML State Chart
Diagram:

State chart diagrams model the dynamic behavior of individual classes or any other
kind of object. They show the sequences of states that an object goes through, the events that
cause a transition from one state to another and the actions that result from a state change.
State chart diagrams are closely related to activity diagrams. The main difference
between the two diagrams is state chart diagrams are state centric, while activity diagrams are
activity centric. A state chart diagram is typically used to model the discrete stages of an
object’s lifetime, whereas an activity diagram is better suited to model the sequence of
activities in a process.

Each state represents a named condition during the life of an object during which it
satisfies some condition or waits for some event. A state chart diagram typically contains one
start state and multiple end states. Transitions connect the various states on the diagram. As
with activity diagrams, decisions, synchronizations, and activities may also appear on state
chart diagrams.
 18

enquiry perform reserve reserve renew renew cancel cancel

enquiry book book reseve

borrow

borrow return return exit

book book

DESIGN

16. Class - Attributes, operations & Relationships.

Attributes identified in object – oriented analysis must be refined with an eye on

implementation during this phase. In the analysis phase name of the attribute is sufficient.
However, in the design phase, detailed information must be added to the model. The main
goal of this activity is to refine existing attributes that can elevate the system into
implementation.

Attribute types:
The three basic types of attributes are
 Single-value attribute.
 Multiplicity or multi valued attribute.
 Reference to anther object, or instance connection.
Attributes represent the state of an object. Hen the state of the object changes, these
changes are reflected in the value of attributes.
UML Attribute Presentation:
The following is the attribute presentation suggested by UML.
 19

Visibility name: type – expression

Where visibility is one of the following:
+ public visibility
# protected visibility
- private visibility
Type – expression is a language-dependent specification of the implementation type of an
attribute.
Initial-value: is a language-dependent expression for the initial value of the newly created
object. The initial value is optional.

UML Operation Presentation:

The following operation presentation has been suggested by the UML. The operation syntax
is this:
Visibility name: ( parameter – list): return- type- expression
Where visibility is one of:
+ public visibility
# protected visibility
- private visibility
Here, name is the name of the operation.
Parameter-list: is a list of parameters, separated by commas, each specified by
name: type-expression = default value
return- type-expression: is a language-dependent specification of the implementation of the
value returned by the method. If return- type is omitted, the operation does not return a value.
 20

Book
book id
Member
authour M name
issuing date uses mid no
returning date
+0...* a address
borrow limit
remove book()
renew book() add member()
borrow book() delete member()
return book()

+0...*

Staff Student
Title reserve
copy of tid
price
t reserved +0...*
t issued
t copies

remove()
add()

Librarian

17.Component Diagram:

Component diagrams mainly contain

Components
Interfaces
Dependency, generalization, association and realization diagrams.
Uses of Component Diagrams:
The component diagrams are mainly used to model the static implementation view of a
system. This view primarily supports the configuration management of a system's parts, made
up of components that can be assembled in various ways to produce a running system.
While modeling the static implementation of a system, component diagrams are typically
used in one of the following ways.
a. To model source code:
With most contemporary object-oriented programming languages , code is cut
using integrated development environments that store the source code in files. We
 21

can use component diagrams to model the configuration management of these

files, which represent work-product components.
b. To model executable releases:
A release is a relatively complete and consistent set of artifacts delivered to an
internal or external user. In the context of components, a release focuses on the
parts necessary to deliver a running system. When you model a release using
component diagrams, you are visualizing, specifying and documenting the
decisions about the physical parts that constitute your software.-that is its
deployment diagrams.
c. To model physical databases:
The model of a physical database represents the storage of that information in the
tables of a relational database or the pages of an object-oriented database.
Component diagrams are used to represent these kinds of physical databases.
d. To model adaptable system:
The components in a static system enter the scene, participate in an execution, and
then depart whereas the components or mobile agents in a dynamic system
migrate for purposes of load balancing and failure recovery. The component
diagrams are used in conjunction with some of the UML diagrams for modeling
behavior to represent these kinds of systems.

student issue
register

librarian
item
 22

18. Deployment Diagram

The UML component diagrams model the dependencies between software components.
• Deployment diagrams depict the relationships between the software and hardware
system components.
• UML deployment diagrams model the physical computational nodes on which the
software will be deployed.
• They can also show the configuration or deployment of run-time elements, software
components, processes, and objects.
• Component diagrams for systems are usually combined in a single deployment
diagram
• The nodes in a system execute the code for the software components.
• 3-D boxes represent the nodes in a deployment diagram.
• Physical connections between the nodes appear in the form of connecting lines in a
deployment diagram.

Student/staff

library
database

library
manager
 23

USES / ADVANTAGES OF UML

1. UML is effective for modeling large, complex software systems

2. It is simple to learn for most developers, but provides advanced features for expert
analysts, designers and architects
3. It can specify systems in an implementation-independent manner
4. 10-20% of the constructs are used 80-90% of the time
5. Structural modeling specifies a skeleton that can be refined and extended with
additional structure and behavior
6. Use case modeling specifies the functional requirements of system in an
object-oriented manner
7. Analyze existing source code and reverse-engineer it into a set of UML diagrams.
execute UML models, typically in one of two ways:
8. Execute your model interpretively in a way that lets you confirm that it really does
what you want, but without the scalability and speed that you'll need in your deployed
application.
9. Work only within a restricted application domain generate program language code
from UML, producing most of a bug-free, deployable application that runs quickly if the code
generator incorporates best-practice scalable patterns for,
A number of tools on the market generate Test and Verification Suites from UML models.

*******