0% found this document useful (0 votes)
4 views

Reference Manual - Software Engineering

Uploaded by

Aneesh Shinde
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

Reference Manual - Software Engineering

Uploaded by

Aneesh Shinde
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

List of Practical

(To be executed using Star UML or any similar software)

Sr. No. Aim

1 Study and implementation of class diagrams.

2 Study and implementation of Use Case Diagrams.

3 Study and implementation of Entity Relationship Diagrams.

4 Study and implementation of Sequence Diagrams.

5 Study and implementation of State Transition Diagrams.

6 Study and implementation of Data Flow Diagrams.

7 Study and implementation of Collaboration Diagrams.

8 Study and implementation of Activity Diagrams.

9 Study and implementation of Component Diagrams.

10 Study and implementation of Deployment Diagrams.


Practical-1

Aim: Study and implementation of class diagrams.

Class Diagram:
A class diagram is a fundamental concept in object-oriented modeling and
design. It represents the static structure of a system, illustrating the classes,
their attributes, methods, and relationships. The diagram showcases how various
classes are interconnected and how data flows between them. Class diagrams
serve as a blueprint for software development, helping developers understand,
visualize, and communicate the organization of a system's objects and their
interactions. They are widely used during the analysis and design phases of
software development to model the structure of a software application or
system.
Practical-2

Aim: Study and implementation of Use Case diagrams.

Use Case Diagram:


A use case diagram is a visual representation of the interactions between actors
(users or external systems) and a system. It showcases the various use cases or
functionalities that the system offers to its users, as well as the actors' roles in
utilizing those functionalities. Use case diagrams help to understand the
functional requirements of a system and provide a clear overview of its behavior
from an end-user perspective. They are a valuable tool during the early stages of
software development to capture and communicate user-system interactions and
aid in identifying and defining system boundaries and requirements.
Practical-3

Aim: Study and implementation of Entity Relationship diagrams.

Entity Relationship Diagram:


An Entity-Relationship (ER) diagram is a graphical representation of the essential
components of a database system, illustrating the entities, their attributes, and
the relationships between them. Entities represent real-world objects, and
attributes describe their properties. Relationships establish connections between
entities, defining how they are related to each other. ER diagrams are used in
database design to model and plan the structure of a database system, enabling
developers to visualize data entities and their associations. By creating an ER
diagram, developers can gain insights into the database's organization, optimize
data storage, and ensure data integrity and efficiency in database operations.

Practical-4
Aim: Study and implementation of Sequence diagrams.

Sequence Diagram:
A sequence diagram is a type of interaction diagram because it describes how—
and in what order—a group of objects works together. These diagrams are used
by software developers and business professionals to understand requirements
for a new system or to document an existing process. Sequence diagrams are
sometimes known as event diagrams or event scenarios.
Advantages of Sequence Diagram:
1. Visualization: Sequence diagrams offer a visual representation of
interactions, making it easier to grasp the flow of messages and actions
between objects or components.
2. Detecting Issues: They enable early detection of potential problems or
bottlenecks in the system's design, ensuring that issues are identified and
resolved before implementation.
3. Communication: They serve as a clear and concise communication tool,
aiding effective discussions and collaboration among team members and
stakeholders.
4. Validation: Sequence diagrams help validate system behavior and use
case scenarios, ensuring the system functions correctly during various
sequences of events.
Basic symbols and component

Symbol Name Description


Represents a class or object in UML. The object
symbol demonstrates how an object will behave in
Object symbol
the context of the system. Class attributes should not
be listed in this shape.

Represents the time needed for an object to complete


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

Shows entities that interact with or are external to


Actor symbol
the system.

Used in UML 2.0 notation to contain interactive


elements of the diagram. Also known as a frame, this
Package symbol
rectangular shape has a small inner rectangle for
labeling the diagram.
<<create>> Represents the passage of time as it extends
downward. This dashed vertical line shows the
Lifeline symbol sequential events that 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 circumstance


Option loop symbol
that will only occur under certain conditions.

Symbolizes a choice (that is usually mutually


exclusive) between two or more message sequences.
Alternative symbol
To represent alternatives, use the labeled rectangle
shape with a dashed line inside.

Common message symbols

Symbol Name Description


Represented by a solid line with a solid arrowhead.
Synchronous This symbol is used when a sender must wait for a
message symbol response to a message before it continues. The
diagram should show both the call and the reply.
Represented by a solid line with a lined arrowhead.
Asynchronous Asynchronous messages don't require a response
message symbol before the sender continues. Only the call should be
included in the diagram.
Asynchronous
return message Represented by a dashed line with a lined arrowhead.
symbol
Asynchronous
Represented by a dashed line with a lined arrowhead.
create message
This message creates a new object.
symbol
Reply message Represented by a dashed line with a lined arrowhead,
symbol these messages are replies to calls.
Delete message Represented by a solid line with a solid arrowhead,
symbol followed by an X. This message destroys an object.
Practical-5

Aim: Study and implementation of State Transition diagrams.

State Transition Diagram:


State Transition Diagrams are also known as Dynamic models. As the name
suggests, it is a type of diagram that is used to represent different transition
(changing) states of a System. It is generally used to graphically represent all
possible transition states a system can have and model such systems.
Symbol Type of State Description

Initial State In a System, it represents Starting state.

Final State In a System, it represents Ending state.

In a System, it represents a Simple state with


Simple State
no substructure.

In a System, it represents a Composite state


Composite with two or more parallel or concurrent states
State out of which only one state will be active at a
time and other states will be inactive.

You might also like