Case study-1

Library Information Management System

Problem Statement:
A Library Information System is to be developed for automating the various
functions of the Library. Faculty, Students and Employees of the Institute can
take the membership of the Library. Each member can issue a book up to
specific limit and specific duration. However, the limit may vary form one type
of member to the other type of member. The Library Management System
performs the cataloguing, managing members, Issue and Return of the Book.
 EXERCISE 1:
Aim:
Identify and create Use cases for the problem statement. Identify and create the Actors for the
problem statement.

Theory:
According to the UML specification a use case diagram is “a diagram that shows the
relationships among actors and use cases within a system.”  Use case diagrams are often used
to:

● Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model
● Communicate the scope of a development project
● Model your analysis of your usage requirements in the form of a system use case
model

Use case models should be developed from the point of view of your project stakeholders and
not from the (often technical) point of view of developers.  There are guidelines for:

● Use Cases

● Actors 

● Relationships 

● System Boundary Boxes

Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor.  A use
case is drawn as a horizontal ellipse on a UML use case diagram.

1. Use Case Names Begin With a Strong Verb

2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases.
Actors

An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use Case
diagrams). 

Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram. Draw Actors To The
Outside Of A Use Case Diagram. Name Actors With Singular, Business-Relevant Nouns
Associate Each Actor With One Or More Use Cases. Actors Model Roles, Not Positions. Use
<<system>> to Indicate System Actors. Actors Don’t Interact With One Another. Introduce
an Actor Called “Time” to Initiate Scheduled Events

Relationships

There are several types of relationships that may appear on a use case diagram:

● An association between an actor and a use case

● An association between two use cases
● A generalization between two actors
● A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional
open-headed arrowhead on one end of the line indicating the direction of the initial
 invocation of the relationship. Generalizations are depicted as a close-headed arrow with
the arrow pointing towards the more general modeling element.

  

System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name
suggests it indicates the scope of your system – the use cases inside the rectangle represent
the functionality that you intend to implement.  Indicate Release Scope with a System
Boundary Box. Avoid Meaningless System Boundary Boxes.
USE CASE DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM
 EXERCISE 2
Aim
Define Classes in the Logical View associated with each Use Case and define their structure.
Theory
Activity diagram is another important diagram in UML to describe the logical aspects of the
system. Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system. The control flow
is drawn from one operation to another. This flow can be sequential, branched, or concurrent.
Activity diagrams deal with all type of flow control by using different elements such as fork,
join, etc.
Activity diagrams are mainly used as a flowchart that consists of activities performed by the
system. Activity diagrams are not exactly flowcharts as they have some additional
capabilities. These additional capabilities include branching, parallel flow, etc.

Diagram Notations –

Initial State – The starting state before an activity takes place is depicted using the initial
state.

Action or Activity State – An activity represents execution of an action on objects or by

objects. We represent an activity using a rectangle with rounded corners. Basically any
action or event that takes place is represented using an activity.

Action Flow or Control flows – Action flows or Control flows are also referred to as paths
and edges. They are used to show the transition from one activity state to another.

Decision node and Branching – When we need to make a decision before deciding the
flow of control, we use the decision node.
Join – Join nodes are used to support concurrent activities converging into one. For join
notations we have two or more incoming edges and one outgoing edge.

Final State or End State – The state which the system reaches when a particular process
or activity ends is known as a Final State or End State. We use a filled circle within a circle
notation to represent the final state in a state machine diagram. A system or a process can
have multiple final states.
LOGICAL VIEW FOR LIBRARY MANAGEMENT SYSTEM
 EXERCISE 3
Aim
Draw sequence diagram for each Use Case identified in the problem statement.
Theory:
UML sequence diagrams model the flow of logic within the system in a visual manner,
enabling the user both to document and validate the logic, and are commonly used for both
analysis and design purposes. Sequence diagrams are the most popular UML artifact for
dynamic modeling, which focuses on identifying the behavior within your system. Sequence
diagrams, along with class diagrams and physical data models are the most important design-
level models for modern application development.
The dashed lines hanging from the boxes are called object lifelines, representing the life span
of the object during the scenario being modeled. The long, thin boxes on the lifelines are
activation boxes, also called method invocation boxes, which indicate processing is being
performed by the target object/class to fulfil a message.

SEQUENCE DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM

EXERCISE 4
Aim
Draw the collaboration diagram for the problem statement.
Theory:
Collaboration Diagram represents the interaction of the objects to perform the behavior of a
particular use case or a part of use case. The designers use the Sequence diagram and
Collaboration Diagrams to define and clarify the roles of the objects that perform a particular
flow of events of a use case. 

Collaboration diagrams are also relatively easy to draw. They show the relationship between
objects and the order of messages passed between them. The objects are listed as icons and
arrows indicate the messages being passed between them. The numbers next to the messages
are called sequence numbers. As the name suggests, they show the sequence of the messages
as they are passed between the objects. There are many acceptable sequence numbering
schemes in UML.

Notations of a Collaboration Diagram

Objects:
The representation of an object is done by an object symbol with its name and class
underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
 The object is represented by specifying their name and class.
 It is not mandatory for every class to appear.
 A class may constitute more than one object.
 In the collaboration diagram, firstly, the object is created, and then its class is
specified.
 To differentiate one object from another object, it is necessary to name them.

Actors:
In the collaboration diagram, the actor plays the main role as it invokes the interaction. Each
actor has its respective role and name. In this, one actor initiates the use case.

Links:
The link is an instance of association, which associates the objects and actors. It portrays a
relationship between the objects through which the messages are sent. It is represented by a
solid line. The link helps an object to connect with or navigate to another object, such that the
message flows are attached to links.

Messages:
It is a communication between objects which carries information and includes a sequence
number, so that the activity may take place. It is represented by a labelled arrow, which is
placed near a link. The messages are sent from the sender to the receiver, and the direction
must be navigable in that particular direction. The receiver must understand the message.

COLLABORATION DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM

EXERCISE 5
Aim
Draw the Class Diagram for the problem statement.

Theory:
Class diagrams show the classes of the system, their inter-relationships, and the operations
and attributes of the classes. Class diagrams are typically used, although not all at once, to:

 Explore domain concepts in the form of a domain model

 Analyse requirements in the form of a conceptual/analysis model
 Depict the detailed design of object-oriented or object-based software

A class model is comprised of one or more class diagrams and the supporting specifications
that describe model elements including classes, relationships between classes, and interfaces.
There are guidelines

General issues
 Classes
 Interfaces
 Relationships
 Inheritance
 Aggregation and Composition

Because class diagrams are used for a variety of purposes – from understanding requirements
to describing your detailed design – it is needed to apply a different style in each
circumstance.This section describes style guidelines pertaining to different types of class
diagrams.

A class is effectively a template from which objects are created (instantiated).Classes define
attributes,information that is pertinent to their instances, and operations, functionality that the
objects support. Classes will also realize interfaces (more on this later).

Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements such
as classes, packages and objects. Class diagrams describe three different perspectives when
designing a system, conceptual, specification, and implementation. These perspectives
become evident as the diagram is created and help solidify the design.

INTERFACES

An interface is a collection of operation signature and/or attribute definitions that ideally

defines a cohesive set of behaviors. Interface a class or component must implement the
operations and attributes defined by the interface. Any given class or component may
implement zero or more interfaces and one or more classes or components can implement the
same interface.

RELATIONSHIPS

A relationship is a general term covering the specific types of logical connections found on a
class and object diagram.

Class diagrams also display relationships such as containment, inheritance, associations and
others.
The association relationship is the most common relationship in a class diagram. The
association shows the relationship between instances of classes.
Another common relationship in class diagrams is a generalization. A generalization is used
when two classes are similar, but have some differences.

AGGREGATION

Aggregation is a general term covering the specific types of logical connections found on a
class and object diagram.
Aggregation occurs when a class is a collection or container of other classes, but where the
contained classes do not have a strong life cycle dependency on the container-essentially, if
the container is destroyed, its contents are not.
ASSOCIATION
Association are semantic connection between classes. When an association connects two
classes, each class can send messages to other in a sequence or a collaboration diagram.
Associations can be bidirectional or unidirectional.

DEPENDENCIES
Dependencies connect two classes. Dependencies are always unidirectional and show that
one class, depends on the definitions in other class.

GENERALIZATION
The generalization relationship indicates that one of the two related classes (the supertype) is
considered to be a more general form of the other (the subtype). In practice, this means that
any instance of the subtype is also an instance of the supertype. The generalization
relationship is also known as the inheritance or “is a” relationship. The supertype in the
generalization relationship is also known as the “parent”, superclass, base class, or base type.
CLASS DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM
 CASE STUDY-2

Eastern State University Course Registration

Problem Statement:
At the beginning of each semester, students may request a course catalog
containing a list of course offerings for the semester. Information about each
course, such as professor, department and prerequisites will be included to help
students make informed decisions.

The new system will allow students to select four courses offering for the
coming semester. In addition, each student will indicate two alternative choices
in case a course offering becomes filled or canceled. No course offering will
have more than ten students or fewer than three students. A course offering with
fewer than three students will be cancelled. Once the registration process is
completed for as student, the registration system sends information to the billing
system so the student can be billed for the semester.

Professor must be able to access the online system to indicate which courses
they will be teaching, and to see which students signed up for their course
offerings.

For each semester, there is a period of time that students can change their
schedule. Students must be able to access the system during this time to add or
drop courses.
 EXERCISE 1:
Aim:
Identify and create Use cases for the problem statement. Identify and create the Actors for the
problem statement.

Theory:
According to the UML specification a use case diagram is “a diagram that shows the
relationships among actors and use cases within a system.”  Use case diagrams are often used
to:

● Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model
● Communicate the scope of a development project
● Model your analysis of your usage requirements in the form of a system use case
model

Use case models should be developed from the point of view of your project stakeholders and
not from the (often technical) point of view of developers.  There are guidelines for:

● Use Cases

● Actors 

● Relationships 

● System Boundary Boxes

Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor.  A use
case is drawn as a horizontal ellipse on a UML use case diagram.

5. Use Case Names Begin With a Strong Verb

6. Name Use Cases Using Domain Terminology
7. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
8. Imply Timing Considerations By Stacking Use Cases.
Actors

An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use Case
diagrams). 

Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram. Draw Actors To The
Outside Of A Use Case Diagram. Name Actors With Singular, Business-Relevant Nouns
Associate Each Actor With One Or More Use Cases. Actors Model Roles, Not Positions. Use
<<system>> to Indicate System Actors. Actors Don’t Interact With One Another. Introduce
an Actor Called “Time” to Initiate Scheduled Events

Relationships

There are several types of relationships that may appear on a use case diagram:

● An association between an actor and a use case

● An association between two use cases
● A generalization between two actors
● A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional
open-headed arrowhead on one end of the line indicating the direction of the initial
 invocation of the relationship. Generalizations are depicted as a close-headed arrow with
the arrow pointing towards the more general modeling element.

  

System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name
suggests it indicates the scope of your system – the use cases inside the rectangle represent
the functionality that you intend to implement.  Indicate Release Scope with a System
Boundary Box. Avoid Meaningless System Boundary Boxes.
USE CASE DIAGRAM FOR UNIVERSITY MANAGEMENT SYSTEM
 EXERCISE 2
Aim
Define Classes in the Logical View associated with each Use Case and define their structure.

Theory:

Activity diagram is another important diagram in UML to describe the logical aspects of the
system. Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system. The control
flow is drawn from one operation to another. This flow can be sequential, branched, or
concurrent. Activity diagrams deal with all type of flow control by using different elements
such as fork, join, etc.
Activity diagrams are mainly used as a flowchart that consists of activities performed by the
system. Activity diagrams are not exactly flowcharts as they have some additional
capabilities. These additional capabilities include branching, parallel flow, etc.
Before drawing an activity diagram, we must have a clear understanding about the elements
used in activity diagram. The main element of an activity diagram is the activity itself. An
activity is a function performed by the system. After identifying the activities, we need to
understand how they are associated with constraints and conditions.

Diagram Notations –

Initial State – The starting state before an activity takes place is depicted using the initial
state.

Action or Activity State – An activity represents execution of an action on objects or by

objects. We represent an activity using a rectangle with rounded corners. Basically any
action or event that takes place is represented using an activity.

Action Flow or Control flows – Action flows or Control flows are also referred to as paths
and edges. They are used to show the transition from one activity state to another.
Decision node and Branching – When we need to make a decision before deciding the
flow of control, we use the decision node.

Join – Join nodes are used to support concurrent activities converging into one. For join
notations we have two or more incoming edges and one outgoing edge.

Final State or End State – The state which the system reaches when a particular process
or activity ends is known as a Final State or End State. We use a filled circle within a circle
notation to represent the final state in a state machine diagram. A system or a process can
have multiple final states.
LOGICAL VIEW FOR UNIVERSITY MANAGEMENT SYSTEM
 EXERCISE 3
Aim
Draw sequence diagram for each Use Case identified in the problem statement.

Theory:
UML sequence diagrams model the flow of logic within the system in a visual manner,
enabling the user both to document and validate the logic, and are commonly used for both
analysis and design purposes. Sequence diagrams are the most popular UML artifact for
dynamic modeling, which focuses on identifying the behavior within your system. Sequence
diagrams, along with class diagrams and physical data models are the most important design-
level models for modern application development.
The dashed lines hanging from the boxes are called object lifelines, representing the life span
of the object during the scenario being modeled. The long, thin boxes on the lifelines are
activation boxes, also called method invocation boxes, which indicate processing is being
performed by the target object/class to fulfil a message.

SEQUENCE DIAGRAM FOR UNIVERSITY MANAGEMENT SYSTEM

 EXERCISE 4
Aim
Draw the collaboration diagram for the problem statement.

Theory:
Collaboration Diagram represents the interaction of the objects to perform the behavior of a
particular use case or a part of use case. The designers use the Sequence diagram and
Collaboration Diagrams to define and clarify the roles of the objects that perform a particular
flow of events of a use case. 

Collaboration diagrams are also relatively easy to draw. They show the relationship between
objects and the order of messages passed between them. The objects are listed as icons and
arrows indicate the messages being passed between them. The numbers next to the messages
are called sequence numbers. As the name suggests, they show the sequence of the messages
as they are passed between the objects. There are many acceptable sequence numbering
schemes in UML.

Notations of a Collaboration Diagram

Objects:
The representation of an object is done by an object symbol with its name and class
underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
 The object is represented by specifying their name and class.
 It is not mandatory for every class to appear.
 A class may constitute more than one object.
 In the collaboration diagram, firstly, the object is created, and then its class is
specified.
 To differentiate one object from another object, it is necessary to name them.

Actors:
In the collaboration diagram, the actor plays the main role as it invokes the interaction. Each
actor has its respective role and name. In this, one actor initiates the use case.

Links:
The link is an instance of association, which associates the objects and actors. It portrays a
relationship between the objects through which the messages are sent. It is represented by a
solid line. The link helps an object to connect with or navigate to another object, such that the
message flows are attached to links.

Messages:
It is a communication between objects which carries information and includes a sequence
number, so that the activity may take place. It is represented by a labelled arrow, which is
placed near a link. The messages are sent from the sender to the receiver, and the direction
must be navigable in that particular direction. The receiver must understand the message.
COLLABORATION DIAGRAM FOR UNIVERSITY MANAGEMENT SYSTEM
 EXERCISE 5
Aim
Draw the Class Diagram for the problem statement.

Theory:
Class diagrams show the classes of the system, their inter-relationships, and the operations
and attributes of the classes. Class diagrams are typically used, although not all at once, to:

 Explore domain concepts in the form of a domain model

 Analyse requirements in the form of a conceptual/analysis model
 Depict the detailed design of object-oriented or object-based software

A class model is comprised of one or more class diagrams and the supporting specifications
that describe model elements including classes, relationships between classes, and interfaces.
There are guidelines

General issues
  Classes
 Interfaces
 Relationships
 Inheritance
 Aggregation and Composition

Because class diagrams are used for a variety of purposes – from understanding requirements
to describing your detailed design – it is needed to apply a different style in each
circumstance.This section describes style guidelines pertaining to different types of class
diagrams.

A class is effectively a template from which objects are created (instantiated).Classes define
attributes,information that is pertinent to their instances, and operations, functionality that the
objects support. Classes will also realize interfaces (more on this later).

Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements such
as classes, packages and objects. Class diagrams describe three different perspectives when
designing a system, conceptual, specification, and implementation. These perspectives
become evident as the diagram is created and help solidify the design.

INTERFACES

An interface is a collection of operation signature and/or attribute definitions that ideally

defines a cohesive set of behaviors. Interface a class or component must implement the
operations and attributes defined by the interface. Any given class or component may
implement zero or more interfaces and one or more classes or components can implement the
same interface.

RELATIONSHIPS

A relationship is a general term covering the specific types of logical connections found on a
class and object diagram.
Class diagrams also display relationships such as containment, inheritance, associations and
others.
The association relationship is the most common relationship in a class diagram. The
association shows the relationship between instances of classes.
Another common relationship in class diagrams is a generalization. A generalization is used
when two classes are similar, but have some differences.

AGGREGATION

Aggregation is a general term covering the specific types of logical connections found on a
class and object diagram.
Aggregation occurs when a class is a collection or container of other classes, but where the
contained classes do not have a strong life cycle dependency on the container-essentially, if
the container is destroyed, its contents are not.

ASSOCIATION
Association are semantic connection between classes. When an association connects two
classes, each class can send messages to other in a sequence or a collaboration diagram.
Associations can be bidirectional or unidirectional.

DEPENDENCIES
Dependencies connect two classes. Dependencies are always unidirectional and show that
one class, depends on the definitions in other class.
GENERALIZATION
The generalization relationship indicates that one of the two related classes (the supertype) is
considered to be a more general form of the other (the subtype). In practice, this means that
any instance of the subtype is also an instance of the supertype. The generalization
relationship is also known as the inheritance or “is a” relationship. The supertype in the
generalization relationship is also known as the “parent”, superclass, base class, or base type.
CLASS DIAGRAM FOR UNIVERSITY MANAGEMENT SYSTEM