Part 1: Introduction to UML (A Study)

Introduction

The heart of object-oriented problem solving is the construction of a model. The model abstracts the
essential details of the underlying problem from its usually complicated real world. Several
modelling tools are wrapped under the heading of the UML, which stands for Unified Modelling
Language. The purpose of this course is to present important highlights of the UML.

At the centre of the UML are its nine kinds of modelling diagrams, which is described here.

1. Use case diagram

2. Class diagram
3. Object diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

The UML is applicable to object-oriented problem solving. Anyone interested in learning

UML must be familiar with the underlying tenet of object-oriented problem solving it all begins with
the construction of a model. A model is an abstraction of the underlying problem. The domain is the
actual world from which the problem comes. Models consist of objects that interact by sending each
other message. Think of an object as "alive." Objects have things they know (attributes) and things
they can do (behaviours or operations). The values of an object's attributes determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviours (methods or
functions) into a single distinct entity. Objects are instances of classes.

UML Diagrams:

The Unified Modelling Language is a language for specifying, constructing, visualizing, and
documenting the artefacts of a software-intensive system. Analogous to the use of architectural
blueprints in the construction industry, UML provides a common language for describing software
models, and it can be used in conjunction with a wide range of software lifecycles and development
processes.

1. Use Case Diagram:

Use Case diagrams identify the functionality provided by the system (use cases), the users
who interact with the system (actors), and the association between the users and the functionality.
Use Cases are used in the Analysis phase of software development to articulate the high-level
requirements of the system. The primary goals of Use Case diagrams include:

• Providing a high-level view of what the system does

• Identifying the users ("actors") of the system
• Determining areas needing human-computer interfaces.

Graphical Notation:

The basic components of Use Case diagrams are the Actor, the Use Case, and the Association.
Actor:

An Actor, as mentioned, is a user of the system, and is depicted using a stick figure. Therole
of the user is written beneath the icon. Actors are not limited to humans. If a system communicates
with another application, and expects input or delivers output, then that application can also be
considered an actor

Use Case:

A Use Case is functionality provided by the system, typically described as verb + object (e.g.
Register Car, Delete User). Use Cases are depicted with an ellipse. The name of the use case is
written within the ellipse.

Association:

Associations are used to link Actors with Use Cases, and indicate that an Actor participates in
the Use Case in some form. Associations are depicted by a line connecting the Actor and the Use
Case.

The following image shows how these three basic elements work together to form a use
case diagram.

Use case diagrams describe what a system does from the standpoint of an external observer.
The emphasis is on what a system does rather than how.

Use case diagrams are helpful in three areas.

• Determining features (requirements). New use cases often generate new requirements as
the system is analysed and the design takes shape.
• Communicating with clients. Their notational simplicity makes use case diagrams a good way
for developers to communicate with clients.
• Generating test cases. The collection of scenarios for a use case may suggest a suite of test
cases for those scenarios.
 2. Sequence Diagram:

Sequence diagrams document the interactions between classes to achieve a result, such as a use
case. Because UML is designed for object-oriented programming, these communications between
classes are known as messages. The Sequence diagram lists objects horizontally, and time vertically,
and models these messages over time.

Notation:

In a Sequence diagram, classes and actors are listed as columns, with vertical lifelines
indicating the lifetime of the object over time.

Object:

Objects are instances of classes, and are arranged horizontally. The pictorial representation
for an Object is a class (a rectangle) with the name prefixed by the object name (optional) and a
semi-colon.

Actor:

Actors can also communicate with objects, so they too can be listed as a column. An Actor is
modelled using the ubiquitous symbol, the stick figure.

Lifeline:

The Lifeline identifies the existence of the object over time. The notation for a Lifeline is a
vertical dotted line extending from an object.

Activation:

Activations, modelled as rectangular boxes on the lifeline, indicate when the object is
performing an action.

Message:

Messages, modelled as horizontal arrows between Activations, indicate the

communicationsbetween objects.
 Below is a sequence diagram for making a hotel reservation. The object initiating the
sequence of messages is a Reservation window.

Example

Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a
message call. An arrow goes from the sender to the top of the activation bar of the message on the
receiver's lifeline. The activation bar represents the duration of execution of the message.

3. Activity Diagram:

Activity diagrams are used to document workflows in a system, from the business level
down to the operational level. When looking at an Activity diagram, you'll notice elements from
State diagrams. In fact, the Activity diagram is a variation of the state diagram where the "states"
represent operations, and the transitions represent the activities that happen when the operation is
complete. The general purpose of Activity diagrams is to focus on flows driven by internal processing
vs. external event.

Activity States:
 Activity states mark an action by an object. The notations for these states are rounded
rectangles, the same notation as found in State chart diagrams.

Transition:

When an Activity State is completed, processing moves to another Activity State.Transitions

are used to mark this movement. Transitions are modelled using arrows.

Swim lane:

Swim lanes divide activities according to objects by arranging objects in column format and
placing activities by that object within that column. Objects are listed at the top of the column, and
vertical bars separate the columns to form the swim lanes.

Initial State:

The Initial State marks the entry point and the initial Activity State. The notation for the
Initial State is the same as in State chart diagrams, a solid circle. There can only be one Initial State
on a diagram.

Final State:

Final States mark the end of the modelled workflow. There can be multiple Final States on a
diagram, and these states are modelled using a solid circle surrounded by another circle.

Synchronization Bar:

Activities often can be done in parallel. To split processing ("fork"), or to resume processing
when multiple activities have been completed ("join"), Synchronization Bars are used. These are
modelled as solid rectangles, with multiple transitions going in and/or out.
Example

4. Component Diagram:

Component diagrams fall under the category of an implementation diagram, a kind of

diagram that models the implementation and deployment of the system. A Component Diagram, in
particular, is used to describe the dependencies between various software components such as the
dependency between executable files and source files. This information is similar to that within
make files, which describe source code dependencies and can be used to properly compile an
application.

Component:

A component represents a software entity in a system. Examples include source code files,
programs, documents, and resource files. A component is represented using a rectangular box, with
two rectangles protruding from the left side, as seen in the image to the right.
Dependency:

A Dependency is used to model the relationship between two components. The notation for
a dependency relationship is a dotted arrow, pointing from a component to the component it
depends on.

5. Class Diagram:

A Class diagram gives an overview of a system by showing its classes and the relationships
among them. Class diagrams are static -- they display what interacts but not what happens when
they do interact.

UML class notation is a rectangle divided into three parts: class name, attributes, and
operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes
are the connecting links.

Our class diagram has three kinds of relationships.

 Association -- a relationship between instances of the two classes. There is an association
between two classes if an instance of one class must know about the other in order to perform its
work. In a diagram, an association is a link connecting two classes.

Aggregation -- an association in which one class belongs to a collection. An aggregation has a

diamond end pointing to the part containing the whole

Generalization -- an inheritance link indicating one class is a superclass of the other. A

generalization has a triangle pointing to the superclass.

An association has two ends. An end may have a role name to clarify the nature of the
association. A navigability arrow on an association shows which direction the association can be
traversed or queried. The arrow also lets you know who "owns" the association's implementation.
The multiplicity of an association end is the number of possible instances of the class associated with
a single instance of the other end. Multiplicities are single numbers or ranges of numbers.

This table gives the most common multiplicities.

Multiplicities Meaning
0..1 Zero or One instance.
n..m n to m instances
0..* or * No limit on the number of instances
1 Exactly one instance
1 .. * At least one instance

Every class diagram has classes, associations, and multiplicities. Navigability and roles are optional
items placed in a diagram to provide clarity.

6. Packages and Object Diagrams:

To simplify complex class diagrams, you can group classes into packages. A package is a
collection of logically related UML elements. The diagram below is a business model in whichthe
classes are grouped into packages.
 Packages appear as rectangles with small tabs at the top. The package name is on the tab or
inside the rectangle. The dotted arrows are dependencies. One package depends on another if
changes in the other could possibly force changes in the first.Object diagrams show instances
instead of classes. They are useful for explaining small pieces with complicated relationships,
especially recursive relationships.

Thissmallclassdiagram showsthata university department can contain

lotsofotherDepartments.

The object diagram below instantiates the class diagram, replacing it by a concrete
example.

Each rectangle in the object diagram corresponds to a single instance. Instance names are
underlined in UML diagrams. Class or instance names may be omitted from object diagrams as long
as the diagram meaning is still clear.

7. Collaboration Diagrams:

Collaboration diagrams are also interaction diagrams. They convey the same information as
sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a
sequence diagram, object roles are the vertices and messages are the connecting links.The object-
role rectangles are labelled with either class or object names (or both). Class names are preceded by
colons (:). Each message in a collaboration diagram has a sequence number. The top-level message is
numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix
but suffixes of 1, 2, etc. according to when they occur.
 8. State Chart Diagrams:

Objects have behaviours and state. The state of an object depends on its current activity or
condition. A state chart diagram shows the possible states of the object and the transitions that
cause a change in state. From each state comes a complete set of transitions that determine the
subsequent state.

States are rounded rectangles. Transitions are arrows from one state to another. Events or
conditions that trigger transitions are written beside the arrows.
 9. Component and deployment Diagrams:

A component is a code module. Component diagrams are physical analogue of class

diagram. Deployment diagrams show the physical configurations of software and hardware.

The following deployment diagram shows the relationships among software and hardware
components involved in real estate transactions.

The physical hardware is made up of nodes. Each component belongs on a node.Components are
shown as rectangles with two tabs at the upper left.
 Part 2: Problem Statement
An ideal problem statement should possess the following qualities [1]

• The first step in develop anything is to state the requirements.

• A problem statement should state what is to be done and not how it is to be done.
• It should be a statement of need
• The statement should indicate which features are mandatory and which are optional.
• Avoid describing system internals
• Specify protocols for interaction and performance specifications
• Specify other software engineering standards i.e. future extensions, modular construction etc
• Objectives should be clearly stated.
• The problem statement may have more or less detail and must serve as the starting point for
understanding the problem

Example [Computerized Banking System]:

Design software to support a computerized banking system for maintaining the accounts of
customers. Every customer has a unique account number to access his own account. A customer can
login with his account number to deposit, withdraw and to enquire his account details. All the
money transactions will be managed by the cashier. Any person who wishes to open an account with
the National Bank can give his personal details required and create a new account with minimum
balance of rupees two hundred (Rs.200/-). All this information will be uploaded on the computer by
the data entry operator. Once the data are fed on the database, it can’t be changed by anyone
except the manager. Manager has his own password to access the database

Example [Automated Teller Machine]:

Design the software to support a computerized banking network including both human cashiers and
(ATMs) to be shared by a consortium of banks. Each bank provides its own computer to maintain its
own accounts and process transactions against them. Cashier stations are owned by individual banks
and communicate directly with their own bank's computers. Human cashiers enter account and
transaction data. ATMs communicate with a central computer which clears transactions with the
appropriate banks. An ATM accepts a cash card, interacts with the user, communicates with the
central system to carry out the transaction, dispense cash, and prints receipts. The system requires
appropriate record keeping and security provisions. The system must handle concurrent accesses to
the same account correctly. The banks will provide their own software for their own computers.

Example [Hospital Management]:

Design the software to manage a local hospital that consists of many wards. Each ward is
allocated with many patients. Each patient is assigned to one doctor, who has overall responsibility
for the patients in his or her care. Other doctors are assigned to the same patient on an advisory
basis. Each patient is prescribed drugs by the doctor responsible for that patient. Each nurse is
assigned to a ward and nurses all patients on the ward, though is given special responsibility for
some patients. Each patient is assigned to one nurse in this position of responsibility. One of the
doctors is attached to each ward as an overall medical advisor
 Part 3: Use Case
• Use Cases are used to
o Model the behaviour of a system / Subsystem / Element
o Model the context of a system
o Model the requirements of a system
• A use case is a description of a set of sequence of actions, that a system performs to yield an
observable result of value to an actor
• Every use case must have a name that distinguishes it from other use cases
• Use case names are usually short verb phrases naming some behaviour
• An actor represents a set of roles the user play when interacting with the use cases.
• An actor may represent a role played by a human, a hardware device or even another
system
• One object may play the part of multiple actors
• Generalization relationships can be applied on actors
• A use case describes what a system does but it does not specify how it does it.
• A use case can participate in several relationships, in addition to association with actors

Relationship Function Notation

Association The communication path between an actor
and a use case that it participates in
<<extend>> The insertion of additional behavior into a <<extend>>
base use case that does not know about it

<<include>> The insertion of additional behavior into a <<include>>

base use case that explicitly describes it

Generalization Parent child relationship as in inheritance

To model the behaviour / Context of a system

• Identify the boundaries of the system by deciding the behaviour part of it and external
entities
• Identify the actors that surround the system
• Organize actors as generalization
• For each actor, consider the interaction of actor with use cases
• Organize the use cases by applying include and extend relationships
Example
 Part 4: Software Requirement Specification (SRS)

Introduction
A software requirements specification (SRS) is a complete description of a software
system that is to be developed and also it should describe the functional requirements and non
functional requirements of the system. The essential qualities of an SRS document are
correctness, Unambiguousness, completeness, consistency, verifiability, modifiability and
traceability.
The content and qualities of a good software requirements specification (SRS) are
described by Software Engineering Standards Committee of the IEEE Computer Society. The
document has several sample SRS outlines. For detailed description refer the IEEE document
attached as annexure. SRS outline that needs to be followed for completing this exercise is
given below.
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies

3. Specifc requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Classes/Objects
3.2.1 Class/Object 1
3.2.1.1 Attributes (direct or inherited)
3.2.1.1.1 Attribute 1
.
.
.
3.2.1.1.n Attribute n
3.2.1.2 Functions (services, methods, direct or inherited)
3.2.1.2.1 Functional requirement 1.1
.
.
.
3.2.1.2.m Functional requirement 1.m
3.2.1.3 Messages (communications received or sent)
3.2.2 Class/Object 2
.
.
.
3.2.p Class/Object p
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
 Example1 [Baking System]: Software Requirement Specification

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.1.1 System interfaces
2.1.2 User interfaces
2.1.3 Hardware interfaces
2.1.4 Software interfaces
2.1.5 Communication interfaces
2.1.6 Memory
2.1.7 Operations
2.1.8 Site adaption requirements
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
2.6 Apportioning requirements
3. Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communication interfaces
3.2 Classes/ Objects
3.2.1 Class Bank
3.2.1.1 Attributes
3.2.1.1.1 name
3.2.1.1.2 addr
3.2.1.1.3 ph_no
3.2.1.1.4 bal
3.2.1.1.5 acc_no
3.2.1.2 Functions
3.2.1.2.1 new_account()
3.2.2 Class user
3.2.2.1 Attributes
3.2.2.1.1 dep
3.2.2.1.2 draw

3.2.2.2 Functions
3.2.2.2.1 deposit()
 3.2.2.2.2 withdraw()
3.2.2.2.3 display()
3.2.3 Class manager
3.2.3.1 Attributes
3.2.3.1.1 manager_id
3.2.3.2 Functions
3.2.3.2.1 enquiry()
3.3 Performance requirements
3.4. Design constraints
3.5. Software system attributes

1. Introduction:
This document aims at defining the overall software requirements for “National
Bank’s banking system. Efforts have been made to define all requirements exhaustively and
accurately.
The final product will have only the features specified in this document.
1.1. Purpose
This problem describes the capabilities that will be provided by the software application
“Banking system”. It also states the various required constraints by which the system will be
abide.
The intended audience for this document is development team, testing team and end
users of the product.
1.2. Scope
The software product “Banking system” manages all the customer details. The system also
simplifies the banking process such as deposit and withdrawal. It facilitates the manager to
maintain all the details. The application greatly simplifies the efforts of the staff and speeds up
all the banking process.
1.3 Definitions Acronyms and Abbreviation
The following are used throughout this document.
DBA - Data Base Administrator
DEO - Data Entry Operator
ID - Identification number
1.4 References
1) National Bank Website: To obtain information about all banks polices.
2) IEEE Recommended Practice for SRS-IEEE standard 830-1993.
1.5 Overview
The rest of this SRS document describes the various system requirements,
interfaces, features and functionalities in details.
2. Overall description:
A person can create an account in the National bank, by providing all his personal
details demanded by the bank. The database of the bank maintains all the information about its
customers. Only the manager has the authority to make any changes in the customer profile.
The customer can deposit, withdraw and view his current account information using his unique
account number.
2.1 Product Perspective
The application will be windows based, self contained and independent software
product.
2.1.1 System Interfaces
Keyboard
Mouse
2.1.2 User Interfaces
The application will have a user-friendly menu based interface. It will provide the
following screens.
1. National Bank home page:
There will be a welcome screen giving options such as user account manager
account new account and exit. We can login with whichever option required.
2. There will be a screen to capture the user information required.
3. User Account Screen:
There will be a screen providing options such as deposit, withdraw, display and
exit. We can choose appropriate option as per our need.
4. Manager Account Screen:
There will be a screen with options such as edit, enquiry, and exit. Manager can
select appropriate option needed.
2.1.3 Hardware Interfaces
(1) Screen resolution of at least 800×600 required for proper and complete viewing of
screen. Higher resolution would not be a problem.
(2) Standalone system network based not a concern, as it will be possible to run the
application on any of these.
2.1.4 Software Interfaces
1. Any windows based operating system (Windows 95/98/2000/XP/NT).
2. A Java Development Kit jdk1.6.0 is required.
2.1.5 Communication Device: None
2.1.6 Memory Constraints
At least 64MB RAM and 2GB space on hard disk will be required for running the
application.
2.1.7 Operations
This product will not release any automated aspects of the database.Database
backup and recovery will also have to be handled by the DBA.
However the system will provide a ‘RESET SYSTEM’ function that will delete
(upon confirmation from the administrator) all the existing information from the database.
2.1.8 Site Adaptation Requirements
The terminals at client site will have to support the hardware and software
interfaces specified in above section.
2.2 Product Functions
The system will allow access only to authorized users with specific roles say
Manager, DBA, Cashier and Customer. Depending upon the user’s role he/she will be able
to access any specific module of the system.
A summary of the major functions, that the software will perform are listed below:

1. A login facility for enabling only authorizes access to the system.

 2. User (with role DEO) will be able to ass information about customers. iii.
User (with role Manager) will be able to make any modifications to the
Information.
3. User (with role Cashier) will be able to perform the money transactions with the
Customer.
4. User (with role Customer) will be deposit/withdraw amount
2.4 Constraints
The security to safeguard the information about the Customers and their account
details must be maintained. To achieve this, the manager ID must be kept confidential.
2.5 Assumption and Dependencies
All the Customers maintain a SB account with the bank.
2.6 Apportioning of requirements
Not required.
3. Specific requirements:
3.1 External Interface Requirements:
3.1.1 User Interfaces
The application will have a user-friendly menu based interface. It will
provide the following screens.

1. National Bank home page:

There will be a welcome screen giving options such as user account, manager
account, new account and exit. We can login with whichever option required.
2. There will be a screen to capture the user information required.
3. User Account Screen:
There will be a screen providing options such as deposit, withdraw, display and
exit. We can choose appropriate option as per our need.
4. Manager Account Screen:
There will be a screen with options such as edit, enquiry, and exit. Manager can
select appropriate option needed.
3.1.2. Hardware Interfaces
(1) Screen resolution of at least 800×600 required for proper and complete viewing of
screen. Higher resolution would not be a problem.
(2) Standalone system network based not a concern, as it will be possible to run the
application on any of these.
3.1.3 Software Interfaces
(1) Any windows based operating system (Windows 95/98/2000/XP/NT).
(2) A Java Development Kit jdk1.6.0 is required.
3.1.4 Communication Interfaces: None.
3.2. Classes/Objects
3.2.1 Class Bank
3.2.1.1. Attributes
3.2.1.1.1. string name[]
3.2.1.1.2. string addr[]
3.2.1.1.3. string ph_no[]
3.2.1.1.4 int bal[]
3.2.1.1.5 int acc_no[]
 3.2.1.2. Functions
3.2.1.2.1. New_account()
This function is used to create a new account with National Bank.An user
has to enter his personal details like name, address and phone number to create an
account.
3.2.2. Class User
3.2.2.1. Attributes
3.2.2.1.1. int dep
3.2.2.1.1 int draw
3.2.2.2 Fuctions
3.2.2.2.1. deposit()
An user can deposit amount to his account using his
account number.
3.2.2.2.2. withdraw()
An user can withdraw amount from his account using his
account number. User cannot exceed his credit limits.
3.2.2.2.3. display()
This function helps the user to view all his account details
and balance using his account number.
3.2.3. Class Manager
3.2.3.1. Attributes
3.2.3.1.1. int manager_id
3.2.3.2. Functions
3.2.3.2.1. edit()
Using this function, manager can alter the data and
information regarding users.
3.2.3.2.2 enquiry()
This function retrieves all the stored data about the user and
lists it.
3.3. Performance Requirements: None
3.4. Design Requirements: None
3.5. Software System Attributes
3.5.1. Security
This application will be password protected. Users will have to enter correct
account number to access. Manager can access with secured ID.
3.5.2. Maintainability
The application will be designers in a maintainable manner. It will be easy to
incorporates new requirements in the individual modules.
3.5.3. Portability
The application will be easily portable on any windows based system that has
jdk1.6.0 installed in it.
3.6. Other Requirements
None
 Part 5 Data Flow Diagram

What is Data Flow Diagram (DFD)?

A data flow diagram (DFD) represents the flow of information within a system or a
process. Data flow Diagrams can range from simple to in-depth, multi-level DFDs that dig
progressively deeper into how the data is handled.

Symbols and Notations Used in DFDs (Gane and Sarson)

1. External Entity
An outside system that sends or receives data, communicating with the system being
diagrammed. They are the sources and destinations of information entering or leaving the system

2. Process
It represents any process that changes the data, producing an output. It might perform
computations, or sort data based on logic, or direct the data flow based on business rules. Process
Name should have to parts. A verb part and a noun part. Example: “Submit payment.”

3. Data Store
Data stores are files or repositories that hold information for later use, such as a database
table
 4. Data Flow
The data flow the route that data takes between the external entities, processes and data
stores

The content and qualities of a good software requirements specification (SRS) are described by
Software Engineering Standards Committee of the IEEE Computer Society. The document has
several sample SRS outlines. For detailed description refer the IEEE document attached as
annexure. SRS outline that needs to be followed for completing this exercise is given below.

Rules of Data Flow Diagram

1. An entity cannot provide data to another entity without some processing occurred

2. Data cannot move directly from an entity to a data store without being processed.

3. Data cannot move directly from a data store without being processed.
 4. Data cannot move directly from one data store to another without being processed.

Further, the following also have to be avoided.

• Black holes - A processing step may have input flows but no output flows.
 • Miracles - A processing step may have output flows but no input flows.
• Grey holes - A processing step may have outputs that are greater than the sum of its
inputs

DFD Levels
A data flow diagram can dive into progressively more detail by using levels. DFD levels
are numbered 0, 1 or 2, and occasionally go to even Level 3. DFD Level 0 is also called a Context
Diagram. It’s a basic overview of the whole system or process being analyzed or modeled

Example1: DFD Level 0 [Hotel Room Reservation System]

DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram.
You will highlight the main functions carried out by the system
DFD level 2 goes one level deeper into complex parts of level 1.
 Part 6: Structural Modelling

Structure diagram shows static structure of the system and its parts on different
abstraction and implementation levels and how those parts are related to each other. The
elements in a structure diagram represent the meaningful concepts of a system, and may include
abstract, real world and implementation concepts.

Class Diagram
Class diagram is a static structure diagram which describes structure of a system at the
level of classifiers (classes, interfaces, etc.). It shows some classifiers of the system, subsystem or
component, different relationships between classifiers, their attributes and operations,
constraints.

Example1: Student Attendance Management System

Package Diagram
Package diagram is UML structure diagram which shows structure of the designed system
at the level of packages. The following elements are typically drawn in a package diagram:
package, packageable element, dependency, element import, package import, package merge.

Example1: Student Attendance Management System

 Part 7: Behavioral Modelling

Behavioral models describe the internal behavior of a system. It focusses on the dynamic
view of the system. Types of behavioral diagrams are
1. Use case Diagrams: - To model the requirements of the system. It also models the context
of the system.
2. Interaction Diagrams: - To model the interaction among objects. Interaction is a behavior
that comprises a set of messages exchanged among the objects to accomplish a purpose.
Types of Interaction diagrams are
a. Sequence Diagram: - To model the control flow by time ordering
b. Communication Diagram: - To model the control flow by object organization.
3. State Chart Diagrams: - To model the control flow of objects as state machines. A state
machine portrays the sequence of states which an object undergoes due to events and
their responses to events.
4. Activity Diagrams: - An activity diagram shows the flow from activity to activity. An activity
is an ongoing non-atomic execution within a state machine.

A Quick Overview of the Various Parts of a Sequence Diagram

Lifeline Notation

They represent the different objects or parts that interact with each other in the system
during the sequence.

Activation Bars
It is used to indicate that an object is active (or instantiated) during an interaction
between two objects. The length of the rectangle indicates the duration of the objects staying
active.
Messages (Synchronous and Asynchronous)
Return Message

Reflexive Message
Example1: Online Shopping Portal Payment Processing
Communication Diagram
In the example of the notation for a communication diagram, objects are represented by
rectangles. Messages passed between objects are represented by labeled arrows that start with
the sending object and end with the receiving object. The sample messages passed between
objects are labeled 1: message1, 2: message2, 3: message3, etc., where the numerical prefix to
the message name indicates its order in the sequence. Messages that objects send to themselves
are indicated as loops

Example: Online Shopping Portal Payment Processing

Activity Diagram
Activity Diagrams describe how activities are coordinated to provide a service which can be at
different levels of abstraction.
Example: Online Shopping Portal Payment Processing
State Machine Diagram
State machine diagram typically are used to describe state-dependent behavior for an
object. An object responds differently to the same event depending on what state it is in. State
machine diagrams are usually applied to objects but can be applied to any element that has
behavior to other entities such as: actors, use cases, methods, subsystems systems and etc. and
they are typically used in conjunction with interaction diagrams

Example: Online Shopping Portal Payment Processing

Reference:
1. James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen,
“Object Oriented Modelling and Design” Prentice Hall India 2001
2. IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-
1998 (Revision of IEEE Std 830-1993)