BCA III: PU Compiled By: GIRIJA 1

Unit 7: Object-Oriented Analysis and Design

a. Object-Oriented Life Cycle
b. The Unified Modeling Language
c. Use-Case Modeling
d. Object Modeling: Class Diagrams
e. Dynamic Modeling: State Diagrams
f. Dynamic Modeling: Sequence Diagrams

A. Object-Oriented Life Cycle

The Object-Oriented Life Cycle Model (OO-LC Model) is a software development methodology
that uses object-oriented programming (OOP) concepts throughout the entire development
process. In OOP, data (attributes) and the code that operates on that data (methods) are bundled
together into objects, which interact with each other to create a program.

The primary objectives of the Object-Oriented Model

 Object-oriented analysis: Object-oriented analysis develops an object-oriented model
of the application domain.
 Object-oriented design: Object-oriented design develops an object-oriented model of
the software system.
 Object-oriented programming/Implementation: Object-oriented programming realizes
the software design with an object-oriented programming language that supports the
direct implementation of objects, classes, and inheritance.

The OO-LC Model consists of the following phases:

Object-Oriented Analysis (OOA): In this phase, the system requirements are gathered and
analyzed from the user's perspective. The key objective is to identify the objects in the system
and their relationships. This is typically done through techniques such as use case modeling and
class diagramming.

Object-Oriented Design (OOD): In this phase, the object-oriented model developed in the OOA
phase is refined and translated into a blueprint for the system. This includes defining the classes,
their attributes, methods, and relationships. This is typically done through techniques such as
class diagramming and inheritance.

Object-Oriented Programming (OOP): In this phase, the design from the OOD phase is
implemented using an object-oriented programming language such as Java, C++, or Python. This
involves writing code for the classes, attributes, and methods defined in the design.
 BCA III: PU Compiled By: GIRIJA 2

Testing and Integration: In this phase, the individual components of the system are tested and
integrated to ensure that they work together correctly. This includes unit testing, integration
testing, and system testing.

Deployment and Maintenance: In this phase, the system is deployed to the production
environment and maintained over time. This includes fixing bugs, adding new features, and
making other changes as needed.

Advantages of the OO-LC Model:

 Reusable code: Objects can be designed to be reusable, which can save time and effort
in development and maintenance.
 Modular design: The system is broken down into modular components, which makes it
easier to develop, understand, and maintain.
 Flexibility: The OO-LC Model can be adapted to a wide variety of projects, regardless of
size or complexity.
 Maintainability: The object-oriented approach makes it easier to understand and
modify the code, which can save time and money in the long run.
 It uses encapsulation and data hiding process that allows a developer to build tamper-
proof systems.
 It enables software modularity, making it easier to manage and maintain complex
software.
 It allows developers to create new modules using existing models, saving time and
development cost of organizations.

Disadvantages of the OO-LC Model:

 Complexity: The OO-LC Model can be more complex to learn and understand than other
software development methodologies.
 Upfront time: It may take more time upfront to design and implement an object-oriented
system compared to other approaches.
 Not suitable for all projects: The OO-LC Model is not suitable for all types of projects, such
as those that are very small or simple.
 BCA III: PU Compiled By: GIRIJA 3

Difference Between SDLC and OOLC

B. The Unified Modeling Language

Unified Modeling Language (UML) is a general-purpose modeling language. The main aim of
UML is to define a standard way to visualize the way a system has been designed. It is quite
similar to blueprints used in other fields of engineering. UML is not a programming language, it
is rather a visual language.
The first thing to notice about the UML is that there are a lot of different diagrams (models) to
get used to. The reason for this is that it is possible to look at a system from many different
viewpoints. A software development will have many stakeholders playing a part.
For Example:
 Analysts

 Designers
 Coders
 Testers
 BCA III: PU Compiled By: GIRIJA 4

 QA
 The Customer
 Technical Authors

All of these people are interested in different aspects of the system, and each of them require a
different level of detail. For example, a coder needs to understand the design of the system and
be able to convert the design to a low level code. By contrast, a technical writer is interested in
the behavior of the system as a whole, and needs to understand how the product functions. The
UML attempts to provide a language so expressive that all stakeholders can benefit from at least
one UML diagram.
Here's a quick look at each one of these 13 diagrams in as shown in the UML 2 Diagram Structure
below:
Structure diagrams show the static structure of the system and its parts on different abstraction
and implementation levels and how they 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, there are seven types of structure diagram as follows:
 Class Diagram
 Component Diagram
 Deployment Diagram
 Object Diagram
 Package Diagram
 Composite Structure Diagram
 Profile Diagram

Behavior diagrams show the dynamic behavior of the objects in a system, which can be
described as a series of changes to the system over time, there are seven types of behavior
diagrams as follows:
 Use Case Diagram
 Activity Diagram
 State Machine Diagram
 Sequence Diagram
 Communication Diagram
 Interaction Overview Diagram
 Timing Diagram
 BCA III: PU Compiled By: GIRIJA 5

Know all these all types of diagram how it works on one system (Assume One System).

Why do we need UML?

 Complex applications need collaboration and planning from multiple teams and hence
require a clear and concise way to communicate amongst them.
 Businessmen do not understand code. So UML becomes essential to communicate with
non-programmers about essential requirements, functionalities, and processes of the
system.
 A lot of time is saved down the line when teams can visualize processes, user interactions,
and the static structure of the system.

C. Use-Case Modeling
The Use-case modeling is defined as a model which is used to show how users interact with the
system in order to solve a problem. As such, the use case model defines the user's objective, the
interactions between the system and the user, and the system's behavior required to meet these
objectives.
Various model elements/components are contained in use-case model which are:
 Actors: Represent any entity that interacts with the system, such as users, external
systems, or devices.
 Use Cases: Describe a sequence of actions between an actor and the system to achieve a
specific goal. Each use case represents a complete unit of functionality.
 BCA III: PU Compiled By: GIRIJA 6

 Relationships: Define how actors and use cases interact. These can be inclusions (one use
case includes another), extensions (a use case adds functionality to another), or
generalizations (a more specific use case inherits from a more general one).

We use a use-case diagram to graphically portray a subset of the model in order to make the
communication simpler. There will regularly be a numerous use-case diagram which is related to
the given model, each demonstrating a subset of the model components related to a specific
purpose.

Advanced Model Components

There are various components of the advanced model:

 Subject
 Use-Case Package
 Generalizations
 Dependencies

Subject
The subject component is used to represent the boundary of the system of interest.

Use-Case Package
We use the model component in order to structure the use case model to make simpler the
analysis, planning, navigation, and communication. Suppose there are various actors or use cases.
In that case, we can also use use-case packages in order to further structure the use-case model
in much the similar way we use directories or folders to organize the information on our hard-
disk.
For various reasons, we divide the use-case model into the use-case packages, containing:
 To help parallel development by partitioning the problem into bite-sized parts.
 To improve communication with various stakeholders by making packaging containing
actors, use cases and related to the specific stakeholder.

Generalizations
Generalizations mean the association between the actors in order to help re-use of common
properties.
Dependencies
In UML, various types of dependencies are defined between use cases. In particular,
<<include>> and <<extend>>.
 BCA III: PU Compiled By: GIRIJA 7

We use <<include>> dependency to comprise shared behavior from an included use case into a
base use case to use common behavior.
We use <<extend>> dependency to include optional behavior from an extended use-case into
an extended use case.
Importance of Use-Case Diagram
Use Cases have been broadly used over the last few years. There are various benefits of the use-
case diagram:
 Use-case diagram provides an outline related to all components in the system. Use-case
diagram helps to define the role of administrators, users, etc.
 The use-Case diagram helps to provide solutions and answers to various questions that
may pop up if you begin a project unplanned.
 It helps us to define the needs of the users extensively and explore how it will work.

Basic Use-Case Diagram Symbols and Notations

System
With the help of the rectangle, we can draw the boundaries of the system, which includes use-
cases. We need to put the actors outside the system's boundaries.

Use-Case
With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals
in order to represent the functions of the system.

Actors
Actors mean the system's users. If one system is the actor of the other system, then with the
actor stereotype, we have to tag the actor system.
 BCA III: PU Compiled By: GIRIJA 8

Relationships
With the simple line we can represent relationships between an actor and use cases. For
relationships between use-case, we use arrows which are labeled either "extends" or "uses".
The "extends" relationship shows the alternative options under the specific use case. The "uses"
relationship shows that single use-case is required to accomplish a job.

Guidelines for Better Use-Cases

Actors
 The actor's name should be meaningful and relevant to the business
If the use-case interacting with the outside organization, then we have to give the actor's
name with the function instead of the organization name, such as Airline company is
better than the PanAir).
 Place inheriting actors below the parent actor
We have to place the inheriting actors below the parent actor because it makes the
actors more readable and easily highlights the use-cases, which are exact for that actor.
 External Systems are actors
If send-email is our use-case and when the use-case interrelates with the email
management software, then in this case, the software is an actor to that specific user-
case.
Use-Cases
 The name of the use-case begins with a verb
The use-case models action, so the name of the use-case must start with a verb.
 The name of the use-case must be descriptive
The use-case is created to provide more information to others who are looking at a
diagram, such as instead of "Print," "print Invoice is good.
 Put the use-cases to the right of the included use-cases.
In order to add clarity and enhance readability, we have to place the included use-cases
to the right of the invoking use-cases.
 BCA III: PU Compiled By: GIRIJA 9

 Place inheriting use-case below the parent use-case

In order to enhance the diagram's readability, we have to place the inheriting use-case
below the parent use-case.
Systems/Packages
 Give descriptive and meaningful names to these objects.
 Use them carefully and only if needed.
Relationships
 When we are using <<extend>> arrow, points to the base use-case.
 When we are using <<include>> then arrow points to the comprised use-case.
 Actor and use-case relationship do not display arrows.
 <<extend>> may have an optional extension condition.
 <<include>> and <<extend>> both are shown as dashed arrows.

Example: Use Case Diagram for Customer Relationship Management of Internet Service
Provider.

Fig: Admin Use Case

BCA III: PU Compiled By: GIRIJA 10

Fig: Customer Use Case

Fig: Employee Use Case

 BCA III: PU Compiled By: GIRIJA 11

D. Object Modeling: Class Diagrams

The class diagram is one of the types of UML diagrams which is used to represent the static
diagram by mapping the structure of the systems using classes, attributes, relations, and
operations between the various objects.
A class diagram has various classes, each has three-part:

 the first partition contains a Class name which is the name of the class or entity which is
participated in the activity,
 the Second partition contains class attributes that show the various properties of the
class,
 the third partition contains class operations which shows various operations performed
by the class, relationships shows the relation between two classes.

UML Class Notation

Class notation is a graphical representation used to depict classes and their relationships in
object-oriented modeling.

1. Class Name:
 The name of the class is typically written in the top compartment of the class box and
is centered and bold.
2. Attributes:
 Attributes, also known as properties or fields, represent the data members of the
class. They are listed in the second compartment of the class box and often include the
visibility (e.g., public, private) and the data type of each attribute.
 BCA III: PU Compiled By: GIRIJA 12

3. Methods:
 Methods, also known as functions or operations, represent the behavior or
functionality of the class. They are listed in the third compartment of the class box and
include the visibility (e.g., public, private), return type, and parameters of each
method.
4. Visibility Notation:
 Visibility notations indicate the access level of attributes and methods. Common
visibility notations include:
 + for public (visible to all classes)
 - for private (visible only within the class)
 # for protected (visible to subclasses)
 ~ for package or default visibility (visible to classes in the same package)

Parameter Directionality
In class diagrams, parameter directionality refers to the indication of the flow of information
between classes through method parameters. It helps to specify whether a parameter is an
input, an output, or both. This information is crucial for understanding how data is passed
between objects during method calls.

There are three main parameter directionality notations used in class diagrams:
 In (Input):
 An input parameter is a parameter passed from the calling object (client) to the
called object (server) during a method invocation.
 It is represented by an arrow pointing towards the receiving class (the class
that owns the method).
 Out (Output):
 An output parameter is a parameter passed from the called object (server)
back to the calling object (client) after the method execution.
 It is represented by an arrow pointing away from the receiving class.
 BCA III: PU Compiled By: GIRIJA 13

 InOut (Input and Output):

 An InOut parameter serves as both input and output. It carries information
from the calling object to the called object and vice versa.
 It is represented by an arrow pointing towards and away from the receiving
class.

Class Diagram Relationships:

Classes are interrelated to each other in specific ways. In particular, relationships in class
diagrams include different types of logical connections. The following are such types of logical
connections that are possible in UML:
 Association
 Directed Association
 Reflexive Association
 Multiplicity
 Aggregation
 Composition
 Inheritance/Generalization
 Realization

Association

Association is a broad term that encompasses just about any logical connection or relationship
between classes. For example, passengers and airline may be linked as above.
 BCA III: PU Compiled By: GIRIJA 14

Directed Association

Directed Association refers to a directional relationship represented by a line with an

arrowhead. The arrowhead depicts a container-contained directional flow.

Reflexive Association

This occurs when a class may have multiple functions or responsibilities. For example, a staff
member working in an airport may be a pilot, aviation engineer, ticket dispatcher, guard, or
maintenance crew member. If the maintenance crew member is managed by the aviation
engineer there could be a managed by relationship in two instances of the same class.
 BCA III: PU Compiled By: GIRIJA 15

Multiplicity

Multiplicity is the active logical association when the cardinality of a class in relation to another
is being depicted. For example, one fleet may include multiple airplanes, while one commercial
airplane may contain zero to many passengers. The notation 0..* in the diagram means “zero to
many”.

Aggregation

Aggregation refers to the formation of a particular class as a result of one class being aggregated
or built as a collection. For example, the class “library” is made up of one or more books, among
other materials. In aggregation, the contained classes are not strongly dependent on the lifecycle
of the container. To show aggregation in a diagram, draw a line from the parent class to the child
class with a diamond shape near the parent class.
 BCA III: PU Compiled By: GIRIJA 16

Composition

The composition relationship is very similar to the aggregation relationship. with the only
difference being its key purpose of emphasizing the dependence of the contained class to the life
cycle of the container class. That is, the contained class will be obliterated when the container
class is destroyed. For example, a shoulder bag’s side pocket will also cease to exist once the
shoulder bag is destroyed.

To show a composition relationship in a UML diagram, use a directional line connecting the two
classes, with a filled diamond shape adjacent to the container class and the directional arrow to
the contained class.

Inheritance/Generalization

Inheritance/Generalization refers to a type of relationship wherein one associated class is a child

of another by virtue of assuming the same functionalities of the parent class. In other words, the
child class is a specific type of the parent class. To show inheritance in a UML diagram, a solid line
from the child class to the parent class is drawn using an unfilled arrowhead.
 BCA III: PU Compiled By: GIRIJA 17

Realization

Realization denotes the implementation of the functionality defined in one class by another
class. To show the relationship in UML, a broken line with an unfilled solid arrowhead is drawn
from the class that defines the functionality of the class that implements the function. In the
example, the printing preferences that are set using the printer setup interface are being
implemented by the printer.

Purpose of Class Diagrams

The main purpose of using class diagrams is:
 This is the only UML that can appropriately depict various aspects of the OOPs concept.
 Proper design and analysis of applications can be faster and efficient.
 It is the base for deployment and component diagram.
 It incorporates forward and reverse engineering.

Benefits of Class Diagrams

 Modeling Class Structure:
 Class diagrams help in modeling the structure of a system by representing
classes and their attributes, methods, and relationships.
 This provides a clear and organized view of the system’s architecture.
 Understanding Relationships:
 Class diagrams depict relationships between classes, such as associations,
aggregations, compositions, inheritance, and dependencies.
 This helps stakeholders, including developers, designers, and business analysts,
understand how different components of the system are connected.
 Communication:
 Class diagrams serve as a communication tool among team members and
stakeholders. They provide a visual and standardized representation that can
be easily understood by both technical and non-technical audiences.
 BCA III: PU Compiled By: GIRIJA 18

 Blueprint for Implementation:

 Class diagrams serve as a blueprint for software implementation. They guide
developers in writing code by illustrating the classes, their attributes, methods,
and the relationships between them.
 This can help ensure consistency between the design and the actual
implementation.
 Code Generation:
 Some software development tools and frameworks support code generation
from class diagrams.
 Developers can generate a significant portion of the code from the visual
representation, reducing the chances of manual errors and saving development
time.
 Identifying Abstractions and Encapsulation:
 Class diagrams encourage the identification of abstractions and the
encapsulation of data and behavior within classes.
 This supports the principles of object-oriented design, such as modularity and
information hiding.

How to draw Class Diagrams

Drawing class diagrams involves visualizing the structure of a system, including classes, their
attributes, methods, and relationships. Here are the steps to draw class diagrams:
1. Identify Classes:
 Start by identifying the classes in your system. A class represents a blueprint for
objects and should encapsulate related attributes and methods.
2. List Attributes and Methods:
 For each class, list its attributes (properties, fields) and methods (functions,
operations). Include information such as data types and visibility (public, private,
protected).
3. Identify Relationships:
 Determine the relationships between classes. Common relationships include
associations, aggregations, compositions, inheritance, and dependencies. Understand
the nature and multiplicity of these relationships.
4. Create Class Boxes:
 Draw a rectangle (class box) for each class identified. Place the class name in the top
compartment of the box. Divide the box into compartments for attributes and
methods.
5. Add Attributes and Methods:
 Inside each class box, list the attributes and methods in their respective
compartments. Use visibility notations (+ for public, – for private, # for protected, ~ for
package/default).
6. Draw Relationships:
 Draw lines to represent relationships between classes. Use arrows to indicate the
direction of associations or dependencies. Different line types or notations may be
used for various relationships.
 BCA III: PU Compiled By: GIRIJA 19

7. Label Relationships:
 Label the relationships with multiplicity and role names if needed. Multiplicity
indicates the number of instances involved in the relationship, and role names clarify
the role of each class in the relationship.
8. Review and Refine:
 Review your class diagram to ensure it accurately represents the system’s structure
and relationships. Refine the diagram as needed based on feedback and requirements.
9. Use Tools for Digital Drawing:
 While you can draw class diagrams on paper, using digital tools can provide more
flexibility and ease of modification. UML modeling tools, drawing software, or even
specialized diagramming tools can be helpful.

Class Diagram Example

A class diagram describing the sales order system is given below.
 BCA III: PU Compiled By: GIRIJA 20

E. Dynamic Modeling: State Diagrams

A state diagram (also known as a state machine or statechart diagram) is an illustration of all the
possible behavioral states a software system component may exhibit and the various state
changes it's predicted to undergo over the course of its operations.

Using standard Unified Modeling Language (UML) notation, a state diagram somewhat resembles
an operational flowchart that outlines the various state-altering processes that occur within a
system.

Benefits and uses of state diagrams

State diagrams can be useful in a variety of application development scenarios, particularly in
cases of object-oriented programming (OOP), for a number of reasons. Some of its most
prominent benefits include its ability to do the following:

 List the events responsible for altering system states.

 Model dynamic behaviour and activity of a system.
 Demonstrate the response of a system to different types of stimuli.
 Represent finite state machines visually.
 Illustrate the entire lifecycle of an object.

Basic components and notations

A state is shown as a rectangle with rounded corners. It may have one or more compartments.
The compartments are all optional. They are as follows:
 Name compartment holds the (optional) name of the state as a string. States without
names are “anonymous” and are all distinct. It is undesirable to show the same-named
state twice in the same diagram.
 The initial state is shown by a solid circle.
 The final state is shown by a bull’s eye.

Initial state
We use a black filled circle represent the initial state of a System or a Class.
 BCA III: PU Compiled By: GIRIJA 21

Transition
We use a solid arrow to represent the transition or change of control from one state to another.
The arrow is labelled with the event which causes the change in state.

State
We use a rounded rectangle to represent a state. A state represents the conditions or
circumstances of an object of a class at an instant of time.
 BCA III: PU Compiled By: GIRIJA 22

Fork
We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from
the parent state and outgoing arrows towards the newly created states. We use the fork
notation to represent a state splitting into two or more concurrent states.

Join
We use a rounded solid rectangular bar to represent a Join notation with incoming arrows from
the joining states and outgoing arrow towards the common goal state. We use the join notation
when two or more states concurrently converge into one on the occurrence of an event or
events.
 BCA III: PU Compiled By: GIRIJA 23

Self-transition
We use a solid arrow pointing back to the state itself to represent a self transition. There might
be scenarios when the state of the object does not change upon the occurrence of an event.
We use self transitions to represent such cases.

Composite state
We use a rounded rectangle to represent a composite state also. We represent a state with
internal activities using a composite state.
 BCA III: PU Compiled By: GIRIJA 24

Final State
We use a filled circle within a circle notation to represent the final state in a state machine
diagram.

How to draw a State diagram in UML?

Below are the steps of how to draw the State Machine Diagram in UML:
Step1. Identify the System:
 Understand what your diagram is representing.
 Whether it’s a machine, a process, or any object, know what different situations or
conditions it might go through.
 BCA III: PU Compiled By: GIRIJA 25

Step2. Identify Initial and Final States:

 Figure out where your system starts (initial state) and where it ends (final state).
 These are like the beginning and the end points of your system’s journey.

Step3. Identify Possible States:

 Think about all the different situations your system can be in.
 These are like the various phases or conditions it experiences.
 Use boundary values to guide you in defining these states.

Step4. Label Triggering Events:

 Understand what causes your system to move from one state to another.
 These causes or conditions are the events.
 Label each transition with what makes it happen.

Step5. Draw the Diagram with appropriate notations:

 Now, take all this information and draw it out.
 Use rectangles for states, arrows for transitions, and circles or rounded rectangles for
initial and final states.
 Be sure to connect everything in a way that makes sense.

Let’s understand State diagram with the help of an example, ie. MIS for College :

Fig: Teacher Module

BCA III: PU Compiled By: GIRIJA 26

Fig: Student Module

Fig: Admin Module

 BCA III: PU Compiled By: GIRIJA 27

F. Dynamic Modeling: Sequence Diagrams

The sequence diagram represents the flow of messages in the system and is also termed as an
event diagram. It helps in envisioning several dynamic scenarios. It portrays the communication
between any two lifelines as a time-ordered sequence of events, such that these lifelines took
part at the run time. In UML, the lifeline is represented by a vertical bar, whereas the message
flow is represented by a vertical dotted line that extends across the bottom of the page. It
incorporates the iterations as well as branching.
Purpose of a Sequence Diagram
1. To model high-level interaction among active objects within a system.
2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Benefits of sequence diagrams

Sequence diagrams can be useful references for businesses and other organizations. Try
drawing a sequence diagram to:
 Represent the details of a UML use case.
 Model the logic of a sophisticated procedure, function, or operation.
 See how objects and components interact with each other to complete a process.
 Plan and understand the detailed functionality of an existing or future scenario.

Basic symbols and components

To understand what a sequence diagram is, you should be familiar with its symbols and
components. Sequence diagrams are made up of the following icons and elements:

Symbol Name Description

Represents a class or object in UML. The

object symbol demonstrates how an
Object symbol object will behave in the context of the
system. Class attributes should not be
listed in this shape.
BCA III: PU Compiled By: GIRIJA 28

Represents the time needed for an

object to complete a task. The longer the
Activation box
task will take, the longer the activation
box becomes.

Shows entities that interact with or are

Actor symbol
external to the system.

Used in UML 2.0 notation to contain

interactive elements of the diagram.
Package symbol Also known as a frame, this rectangular
shape has a small inner rectangle for
labeling the diagram.

Represents the passage of time as it

extends downward. This dashed vertical
line shows the sequential events that
Lifeline symbol occur to an object during the charted
process. Lifelines may begin with a
labeled rectangle shape or an actor
symbol.

Used to model if/then scenarios, i.e., a

Option loop
circumstance that will only occur under
symbol
certain conditions.

Symbolizes a choice (that is usually

mutually exclusive) between two or
Alternative
more message sequences. To represent
symbol
alternatives, use the labeled rectangle
shape with a dashed line inside.
 BCA III: PU Compiled By: GIRIJA 29

Common message symbols

Use the following arrows and message symbols to show how information is transmitted between
objects.
Symbol Name Description

Represented by a solid line with a solid

arrowhead. This symbol is used when a
Synchronous sender must wait for a response to a
message symbol message before it continues. The
diagram should show both the call and
the reply.

Represented by a solid line with a lined

arrowhead. Asynchronous messages
Asynchronous
don't require a response before the
message symbol
sender continues. Only the call should
be included in the diagram.

Asynchronous
Represented by a dashed line with a
return message
lined arrowhead.
symbol

Asynchronous Represented by a dashed line with a

create message lined arrowhead. This message creates
symbol a new object.

Represented by a dashed line with a

Reply message
lined arrowhead, these messages are
symbol
replies to calls.

Represented by a solid line with a

Delete message
solid arrowhead, followed by an X.
symbol
This message destroys an object.
 BCA III: PU Compiled By: GIRIJA 30

Example 1: Sequence diagram for student portal.

Example 2: Sequence diagram for teacher portal.

 BCA III: PU Compiled By: GIRIJA 31

More diagram used in software design:

Activity Diagram:
 Illustrates flow of control in a system.
 Models sequential and concurrent activities.
 Focuses on workflow and event causes
 BCA III: PU Compiled By: GIRIJA 32

Deployment Diagram:

 Represents system hardware and software.

 Shows distribution of software artifacts.
 Used for distributed or deployed systems.
 BCA III: PU Compiled By: GIRIJA 33

Component Diagram:

 Organizes physical components in a system.

 Models implementation details.
 Illustrates relationships between software elements.
BCA III: PU Compiled By: GIRIJA 34