GALGOTIAS COLLEGE OF

ENGINEERING AND TECHNOLOGY

GREATER NOIDA

B.Tech CSE

Software Engineering Lab

SUBJECT CODE: BCS-651

(2024-2025, Even Semester)

 SYLLABUS (AKTU)

BCS-651 - SOFTWARE ENGINEERING LAB

LIST OF EXPERIMENT

For any given case/ problem statements do the following:

1. Prepare a SRS document in line with the IEEE recommended standards.

2. Draw the use case diagram and specify the role of each of the actors. Also state the
precondition, post condition and function of each use case.
3. Draw the activity diagram.
4. Identify the classes. Classify them as weak and strong classes and draw the class diagram.
5. Draw the sequence diagram for any two scenarios.
6. Draw the collaboration diagram.
7. Draw the state chart diagram.
8. Draw the component diagram.
9. Perform forward engineering in java. (Model to code conversion)
10. Perform reverse engineering in java. (Code to Model conversion)
11. Draw the deployment diagram.
 LAB COURSE PLAN

Reference
Sr. No. Date Name of Experiment
Material

R1,W1, W2
Prepare a SRS document in line with the IEEE recommended
1 2025-02-16
standards..

R1,W1, W2
Draw the use case diagram and specify the role of each of the
2 2025-02-23
actors.

R1,W1, W2
Identify the classes. Classify them as weak and strong classes and
3 2025-03-01
draw the class diagram.

R1,W1, W2
4 2025-03-15 Draw the activity diagram.

R1,W1, W2
5 2025-03-22 Draw the sequence diagram for any two scenarios.

R1,W1, W2
6 25-03-29 Draw the collaboration diagram..

R1,W1, W2
7 2025-04-05 Draw the state chart diagram.

R1,W1, W2
8 2025-04-12 Draw the component diagram

R1,W1, W2
9 2025-04-19 Perform forward engineering in java

R1,W1, W2
10 2025-04-26 Perform reverse engineering in java

References/ Web Links:

R1: Software Engineering: A Practitioner’s Approach, 8/e Paperback by Roger S. Pressman, Bruce R.
Maxim

W1: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/

W2: http://vlabs.iitkgp.ac.in/se/
LIST OF EXPERIMENTS

Sr. No. Type of Experiment Name of Experiment

Prepare a SRS document in line with the IEEE recommended

1 SRS document
standards.

2 Use case Diagram Draw the use case diagram and specify the role of each of the actors.

Identify the classes. Classify them as weak and strong classes and
3 Class Diagram
draw the class diagram.

4 Activity diagram. Draw the activity diagram.

5 Sequence diagram Draw the sequence diagram for any two scenarios.

6 Collaboration diagram Draw the collaboration diagram.

7 State chart diagram Draw the state chart diagram.

8 Component diagram Draw the component diagram.

9 Forward engineering Perform forward engineering in java

10 Reverse engineering. Perform reverse engineering in java

 SE Lab(BCS651) PBL List
Sem:VI

S.No. Project title

1 Chat Bot app using data science in python
2 Home Maid
3 Evil Giant
4 calcibot
5 Notes Handling System

*Students can select topics of their choice also.

Lab Manual
 GALGOTIAS COLLEGE OF
ENGINEERING & TECHNOLOGY

Department of Computer Science and Engineering

KCS-651 Software Engineering Lab Manual

Submitted to Submitted By
(Teacher’s Name) (Student Name)
 List of Programme

Sr.
Type Name of experiment
N.
Prepare a SRS document in line with the IEEE
1 SRS document
recommended standards.
Draw the use case diagram and specify the role of each of
2 Use case Diagram
the actors.
Identify the classes. Classify them as weak and strong
3 Class Diagram
classes and draw the class diagram.

4 Activity diagram. Draw the activity diagram.

5 Sequence diagram Draw the sequence diagram for any two scenarios.

6 Collaboration diagram Draw the collaboration diagram.

7 State chart diagram Draw the state chart diagram.

8 Component diagram Draw the component diagram.

9 Forward engineering Perform forward engineering in java

10 Reverse engineering. Perform reverse engineering in java

 Experiment No: 1
Type of problem SRS document
List of program All Prepare a SRS document in line with the IEEE recommended
standards.
Template of SRS in IEEE format

Contents
W1: https://www.visual-paradigm.com/guide/uml-unified-modeling-language/ .................... 3
W2: http://vlabs.iitkgp.ac.in/se/ ............................................................................................. 3
Purpose of Class Diagrams .............................................................................................. 12
How to Draw a Class Diagram? ....................................................................................... 12
Where to Use Class Diagrams?........................................................................................ 13
Purpose of Activity Diagrams .......................................................................................... 15
How to Draw an Activity Diagram? ................................................................................ 15
Where to Use Activity Diagrams? ................................................................................... 16
Contents of Collaboration Diagrams ............................................................................ 22
Purpose of Statechart Diagrams ....................................................................................... 24
How to Draw a Statechart Diagram?................................................................................ 24
Where to Use Statechart Diagrams?................................................................................. 25
Purpose of Component Diagrams .................................................................................... 27
How to Draw a Component Diagram? ............................................................................. 27
Where to Use Component Diagrams? .............................................................................. 28
Purpose of Deployment Diagrams ................................................................................... 33
How to Draw a Deployment Diagram? ............................................................................ 33
Where to Use Deployment Diagrams? ............................................................................. 34
 Experiment No: 2
Type of problem Use case Diagram
List of program All Draw the use case diagram and specify the role of each of the
actors.
Use Case Specification :<Use-Case Name>
1. Use Case Name

1.1 Brief Description

[ The description should briefly convey the role and purpose of the use case. A single paragraph should suffice for
this description.]
2. Flow of Events

2.1 Basic Flow

[ This use case starts when the actor does something. An actor always initiates use Cases. The use case should
describe what the actor does and what the system does in response. It should be phrased in the form of a dialog
between the actor and the system.
The use case should describe what happens inside the system, but not how or why. If information is exchanged be
specific about what is passed back and forth. For example, it is not very illuminating to say that the Actor enters
customer information; it is better to say the Actor enters the customer’s name and address. A Glossary of Terms is
often useful to keep the complexity of the use case manageable; you may want to define things like customer
information there, to keep the use case from drowning in details.
Simple alternatives may be presented within the text of the use case. If it only takes a few sentences to
describe what happens when there is an alternative; do it directly within the flow of events section. If the
alternative flows are more complex, use a separate section to describe it. For example An Alternative Flow
describes how to describe more complex alternatives.
A picture is sometimes worth a thousand words (though there is no substitute for clean, clear prose). If it improves
clarity, feel free to paste graphical depictions of user interfaces, process flows, or other figures into the use case to
improve its clarity. If a flow chart is useful to present a complex decision process, by all means use it! Similarly
for state-dependent behavior, a state-transition diagram often clarifies the behavior of a system better than pages
upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology,
notation or figures that your audience may not understand. Remember that your purpose is to clarify, not obscure.]

2.2 Alternative Flows

2.2.1 <First Alternative Flow>

[More complex alternatives should be described in a separate section, which is referred to in the basic flow of
events section. Think of the alternative flow sections like alternative behavior each alternative flow represents
alternative behavior (many times, because of exceptions that occur in the main flow). They may be as long as
necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the
events of the main flow of events are resumed unless otherwise stated.]
2.2.1.1 <An Alternative sub-flow>
[Alternative flows may in turn be broken down into sub-sections if it improves clarity.]
2.2.2 <Second Alternative Flow>

[There may be, and most likely will be, a number of alternative flows in a use case. Keep each alternative separate
to improve clarity. Using alternative flows improves the readability of the use case, as well as preventing use cases
from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual descriptions, and
their main purpose is to document the behavior of a system in a clear, concise and understandable way.]

3. Special Requirements

[A Special Requirement is typically a non-functional requirement that is specific to a use case but is not easily or
naturally specified in the text of the use case’s event flow. Examples of special requirements include legal and
regulatory requirements, application standards, and quality attributes of the system to be built, including usability,
reliability, performance or supportability requirements. Additionally, other requirements such as operating systems
and environments, compatibility requirements, and design constraints should be captured in this section.]

3.1 <First special requirement>

4. Preconditions
[A precondition (of a use case) is the state of the system that must be present prior to a use case being performed.]

4.1 <Precondition One>

5. Post Conditions
[A post condition (of a use case) is a list of possible states the system can be in immediately after a use case has
finished.]
5.1 <Post condition one>

6. Extension Points

[Extension points of the use case.]

6.1 <Name of extension point>

[Definition of the location of the extension point in the flow of events.]

 Experiment No: 3
Type of problem Class Diagram
List of program All Identify the classes. Classify them as weak and strong classes
and draw the class diagram.
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only
used for visualizing, describing, and documenting different aspects of a system but also for constructing
executable code of the software application.

Class diagram describes the attributes and operations of a class and also the constraints imposed on the
system. The class diagrams are widely used in the modeling of objectoriented systems because they are
the only UML diagrams, which can be mapped directly with object-oriented languages.

Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is
also known as a structural diagram.

Purpose of Class Diagrams

The purpose of class diagram is to model the static view of an application. Class diagrams are the only
diagrams which can be directly mapped with object-oriented languages and thus widely used at the time
of construction.

UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the
application, however class diagram is a bit different. It is the most popular UML diagram in the coder
community.

The purpose of the class diagram can be summarized as −

● Analysis and design of the static view of an application.

● Describe responsibilities of a system.

● Base for component and deployment diagrams.

● Forward and reverse engineering.

How to Draw a Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software applications. It is
very important to learn the drawing procedure of class diagram.

Class diagrams have a lot of properties to consider while drawing but here the diagram will be
considered from a top level view.

Class diagram is basically a graphical representation of the static view of the system and represents
different aspects of the application. A collection of class diagrams represent the whole system.

The following points should be remembered while drawing a class diagram −

● The name of the class diagram should be meaningful to describe the aspect of the system.

● Each element and their relationships should be identified in advance.

● Responsibility (attributes and methods) of each class should be clearly identified

 ● For each class, minimum number of properties should be specified, as unnecessary properties will
make the diagram complicated.

● Use notes whenever required to describe some aspect of the diagram. At the end of the drawing it
should be understandable to the developer/coder.

● Finally, before making the final version, the diagram should be drawn on plain paper and
reworked as many times as possible to make it correct.

The following diagram is an example of an Order System of an application. It describes a particular

aspect of the entire application.

● First of all, Order and Customer are identified as the two elements of the system. They have a
one-to-many relationship because a customer can have multiple orders.

● Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.

● The two inherited classes have all the properties as the Order class. In addition, they have
additional functions like dispatch () and receive ().

The following class diagram has been drawn considering all the points mentioned above.

Where to Use Class Diagrams?

Class diagram is a static diagram and it is used to model the static view of a system. The static view
describes the vocabulary of the system.

Class diagram is also considered as the foundation for component and deployment diagrams. Class
diagrams are not only used to visualize the static view of the system but they are also used to construct
the executable code for forward and reverse engineering of any system.

Generally, UML diagrams are not directly mapped with any object-oriented programming languages but
the class diagram is an exception.

Class diagram clearly shows the mapping with object-oriented languages such as Java, C++, etc. From
practical experience, class diagram is generally used for construction purpose.

In a nutshell it can be said, class diagrams are used for −

● Describing the static view of the system.

● Showing the collaboration among the elements of the static view.

● Describing the functionalities performed by the system.

● Construction of software applications using object oriented languages.

 Experiment No: 4
Type of problem Activity diagram.
List of program All Draw the activity diagram.
Activity diagram is another important diagram in UML to describe the dynamic 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

Purpose of Activity Diagrams

The basic purposes of activity diagrams is similar to other four diagrams. It captures the dynamic
behavior of the system. Other four diagrams are used to show the message flow from one object to
another but activity diagram is used to show message flow from one activity to another.

Activity is a particular operation of the system. Activity diagrams are not only used for visualizing the
dynamic nature of a system, but they are also used to construct the executable system by using forward
and reverse engineering techniques. The only missing thing in the activity diagram is the message part.

It does not show any message flow from one activity to another. Activity diagram is sometimes
considered as the flowchart. Although the diagrams look like a flowchart, they are not. It shows different
flows such as parallel, branched, concurrent, and single.

The purpose of an activity diagram can be described as −

● Draw the activity flow of a system.

● Describe the sequence from one activity to another.

● Describe the parallel, branched and concurrent flow of the system.

How to Draw an Activity Diagram?

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, swimlane, 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.

Before drawing an activity diagram, we should identify the following elements −

● Activities

● Association

● Conditions
 ● Constraints

Once the above-mentioned parameters are identified, we need to make a mental layout of the entire flow.
This mental layout is then transformed into an activity diagram.

Following is an example of an activity diagram for order management system. In the diagram, four
activities are identified which are associated with conditions. One important point should be clearly
understood that an activity diagram cannot be exactly matched with the code. The activity diagram is
made to understand the flow of activities and is mainly used by the business users

Following diagram is drawn with the four main activities −

● Send order by the customer

● Receipt of the order

● Confirm the order

● Dispatch the order

After receiving the order request, condition checks are performed to check if it is normal or special order.
After the type of order is identified, dispatch activity is performed and that is marked as the termination
of the process.

Where to Use Activity Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is to
model the control flow from one activity to another. This control flow does not include messages.

Activity diagram is suitable for modeling the activity flow of the system. An application can have
multiple systems. Activity diagram also captures these systems and describes the flow from one system
to another. This specific usage is not available in other diagrams. These systems can be database,
external queues, or any other system.

We will now look into the practical applications of the activity diagram. From the above discussion, it is
clear that an activity diagram is drawn from a very high level. So it gives high level view of a system.
This high level view is mainly for business users or any other person who is not a technical person.

This diagram is used to model the activities which are nothing but business requirements. The diagram
has more impact on business understanding rather than on implementation details.

Activity diagram can be used for −

● Modeling work flow by using activities.

● Modeling business requirements.

● High level understanding of the system's functionalities.

● Investigating business requirements at a later stage.

 Experiment No: 5
Type of problem Sequence diagram
List of program All Draw the sequence diagram for any two scenarios.
Sequence Diagram Document
The Sequence Diagram Document should contain the following information:
A sequence diagram for each Use case of your system.

A brief description on the symbols used in the sequence diagram explaining the reason for the usage of
that particular symbol.

A brief description on the flow of each event in each sequence diagram.

Basic Sequence Diagram Notations

Class Roles or Participants
Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate
class roles, but don't list object attributes.

Activation or Execution Occurrence

Activation boxes represent the time an object needs to complete a task. When an object is busy executing
a process or waiting for a reply message, use a thin gray rectangle placed vertically on its lifeline.

Messages
Messages are arrows that represent communication between objects. Use half-arrowed lines to represent
asynchronous messages. Asynchronous messages are sent from an object that will not wait for a response
from the receiver before continuing its tasks. For message types, see below.

Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.

Destroying Objects
Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X. This object is
removed from memory. When that object's lifeline ends, you can place an X at the end of its lifeline to
denote a destruction occurrence.

Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for exiting
the loop at the bottom left corner in square brackets [ ].
Types of Messages in Sequence Diagrams

Synchronous Message
A synchronous message requires a response before the interaction can continue. It's usually drawn using a
line with a solid arrowhead pointing from one object to another.

Asynchronous Message
Asynchronous messages don't need a reply for interaction to continue. Like synchronous messages, they
are drawn with an arrow connecting two lifelines; however, the arrowhead is usually open and there's no
return message depicted.

Reply or Return Message

A reply message is drawn with a dotted line and an open arrowhead pointing back to the original lifeline.

Self Message
A message an object sends to itself, usually shown as a U shaped arrow pointing back to itself.

Create Message
This is a message that creates a new object. Similar to a return message, it's depicted with a dashed line
and an open arrowhead that points to the rectangle representing the object created.

Delete Message
This is a message that destroys an object. It can be shown by an arrow with an x at the end.

Found Message
A message sent from an unknown recipient, shown by an arrow from an endpoint to a lifeline.

Lost Message
A message sent to an unknown recipient. It's shown by an arrow going from a lifeline to an endpoint, a
filled circle or an x.

Sequence Diagram Examples

The best way to understand sequence diagrams is to look at some examples of sequence diagrams.
Click on any of these sequence diagrams included in SmartDraw and edit them:

Sequence Diagram - Log On Scenario

Sequence Diagram - Shopping Cart
 Experiment No: 6
Type of problem Collaboration diagram
List of program All Draw the collaboration diagram.

Collaboration diagrams are used to show how objects interact to perform the behavior of a particular use
case, or a part of a use case. Along with sequence diagrams, collaborations are used by designers to define
and clarify the roles of the objects that perform a particular flow of events of a use case. They are the
primary source of information used to determining class responsibilities and interfaces.

Unlike a sequence diagram, a collaboration diagram shows the relationships among the objects. Sequence
diagrams and collaboration diagrams express similar information, but show it in different ways.
Collaboration diagrams show the relationships among objects and are better for understanding all the
effects on a given object and for procedural design.

Because of the format of the collaboration diagram, they tend to better suited for analysis activities.
Specifically, they tend to be better suited to depicting simpler interactions of smaller numbers of objects.
As the number of objects and messages grows, the diagram becomes increasingly hard to read. In
addition, it is difficult to show additional descriptive information such as timing, decision points, or other
unstructured information that can be easily added to the notes in a sequence diagram.

Contents of Collaboration Diagrams

You can have objects and actor instances in collaboration diagrams, together with links and messages
describing how they are related and how they interact. The diagram describes what takes place in the
participating objects, in terms of how the objects communicate by sending messages to one another. You
can make a collaboration diagram for each variant of a use case's flow of events.

A collaboration diagram that describes part of the flow of events of the use
case Receive Deposit Item in the Recycling-Machine System.

Objects

An object is represented by an object symbol showing the name of the object and its class underlined,
separated by a colon:

objectname :classname

You can use objects in collaboration diagrams in the following ways:

● An object's class can be unspecified. Normally you create a collaboration diagram with objects first
and specify their classes later.
● The objects can be unnamed, but you should name them if you want to discriminate different objects
of the same class.
● An object's class can itself be represented in a collaboration diagram, if it actively participates in the
collaboration.

Actors

Normally an actor instance occurs in the collaboration diagram, as the invoker of the interaction. If you
have several actor instances in the same diagram, try keeping them in the periphery of the diagram.

Links

Links are defined as follows:

● A link is a relationship among objects across which messages can be sent. In collaboration diagrams,
a link is shown as a solid line between two objects.
● An object interacts with, or navigates to, other objects through its links to these objects.
● A link can be an instance of an association, or it can be anonymous, meaning that its association is
unspecified.
● Message flows are attached to links, see Messages.

Messages

A message is a communication between objects that conveys information with the expectation that
activity will ensue. In collaboration diagrams, a message is shown as a labeled arrow placed near a link.
This means that the link is used to transport, or otherwise implement the delivery of the message to the
target object. The arrow points along the link in the direction of the target object (the one that receives the
message). The arrow is labeled with the name of the message, and its parameters. The arrow may also be
labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence
numbers are often used in collaboration diagrams, because they are the only way of describing the relative
sequencing of messages.

A message can be unassigned, meaning that its name is a temporary string that describes the overall
meaning of the message. You can later assign the message by specifying the operation of the message's
destination object. The specified operation will then replace the name of the message.

Experiment No: 7
Type of problem State chart diagram
List of program All Draw the state chart diagram.
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a system.

A Statechart diagram describes a state machine. State machine can be defined as a machine which
defines different states of an object and these states are controlled by external or internal events.

Activity diagram explained in the next chapter, is a special kind of a Statechart diagram. As Statechart
diagram defines the states, it is used to model the lifetime of an object.

Purpose of Statechart Diagrams

Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a system. They
define different states of an object during its lifetime and these states are changed by events. Statechart
diagrams are useful to model the reactive systems. Reactive systems can be defined as a system that
responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are defined as a
condition in which an object exists and it changes when some event is triggered. The most important
purpose of Statechart diagram is to model lifetime of an object from creation to termination.

Statechart diagrams are also used for forward and reverse engineering of a system. However, the main
purpose is to model the reactive system.

Following are the main purposes of using Statechart diagrams −

● To model the dynamic aspect of a system.

● To model the life time of a reactive system.

● To describe different states of an object during its life time.

● Define a state machine to model the states of an object.

How to Draw a Statechart Diagram?

Statechart diagram is used to describe the states of different objects in its life cycle. Emphasis is placed
on the state changes upon some internal or external events. These states of objects are important to
analyze and implement them accurately.

Statechart diagrams are very important for describing the states. States can be identified as the condition
of objects when a particular event occurs.

Before drawing a Statechart diagram we should clarify the following points −

● Identify the important objects to be analyzed.

● Identify the states.

● Identify the events.

Following is an example of a Statechart diagram where the state of Order object is analyzed

The first state is an idle state from where the process starts. The next states are arrived for events like
send request, confirm request, and dispatch order. These events are responsible for the state changes of
order object.
During the life cycle of an object (here order object) it goes through the following states and there may
be some abnormal exits. This abnormal exit may occur due to some problem in the system. When the
entire life cycle is complete, it is considered as a complete transaction as shown in the following figure.
The initial and final state of an object is also shown in the following figure.

Where to Use Statechart Diagrams?

From the above discussion, we can define the practical applications of a Statechart diagram. Statechart
diagrams are used to model the dynamic aspect of a system like other four diagrams discussed in this
tutorial. However, it has some distinguishing characteristics for modeling the dynamic nature.

Statechart diagram defines the states of a component and these state changes are dynamic in nature. Its
specific purpose is to define the state changes triggered by events. Events are internal or external factors
influencing the system.

Statechart diagrams are used to model the states and also the events operating on the system. When
implementing a system, it is very important to clarify different states of an object during its life time and
Statechart diagrams are used for this purpose. When these states and events are identified, they are used
to model it and these models are used during the implementation of the system.

If we look into the practical implementation of Statechart diagram, then it is mainly used to analyze the
object states influenced by events. This analysis is helpful to understand the system behavior during its
execution.

The main usage can be described as −

● To model the object states of a system.

● To model the reactive system. Reactive system consists of reactive objects.

● To identify the events responsible for state changes.

● Forward and reverse engineering.
 Experiment No: 8
Type of problem Component diagram
List of program All Draw the component diagram.
Component diagrams are different in terms of nature and behavior. Component diagrams are used to
model the physical aspects of a system. Now the question is, what are these physical aspects? Physical
aspects are the elements such as executables, libraries, files, documents, etc. which reside in a node.

Component diagrams are used to visualize the organization and relationships among components in a
system. These diagrams are also used to make executable systems.

Purpose of Component Diagrams

Component diagram is a special kind of diagram in UML. The purpose is also different from all other
diagrams discussed so far. It does not describe the functionality of the system but it describes the
components used to make those functionalities.

Thus from that point of view, component diagrams are used to visualize the physical components in a
system. These components are libraries, packages, files, etc.

Component diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment.

A single component diagram cannot represent the entire system but a collection of diagrams is used to
represent the whole.

The purpose of the component diagram can be summarized as −

● Visualize the components of a system.

● Construct executables by using forward and reverse engineering.

● Describe the organization and relationships of the components.

How to Draw a Component Diagram?

Component diagrams are used to describe the physical artifacts of a system. This artifact includes files,
executables, libraries, etc

The purpose of this diagram is different. Component diagrams are used during the implementation phase
of an application. However, it is prepared well in advance to visualize the implementation details.

Initially, the system is designed using different UML diagrams and then when the artifacts are ready,
component diagrams are used to get an idea of the implementation.

This diagram is very important as without it the application cannot be implemented efficiently. A well-
prepared component diagram is also important for other aspects such as application performance,
maintenance, etc.

Before drawing a component diagram, the following artifacts are to be identified clearly −

● Files used in the system.

● Libraries and other artifacts relevant to the application.

 ● Relationships among the artifacts.

After identifying the artifacts, the following points need to be kept in mind.

● Use a meaningful name to identify the component for which the diagram is to be drawn.

● Prepare a mental layout before producing the using tools.

● Use notes for clarifying important points.

Following is a component diagram for order management system. Here, the artifacts are files. The
diagram shows the files in the application and their relationships. In actual, the component diagram also
contains dlls, libraries, folders, etc.

In the following diagram, four files are identified and their relationships are produced. Component
diagram cannot be matched directly with other UML diagrams discussed so far as it is drawn for
completely different purpose.

The following component diagram has been drawn considering all the points mentioned above.

Where to Use Component Diagrams?

We have already described that component diagrams are used to visualize the static implementation view
of a system. Component diagrams are special type of UML diagrams used for different purposes.

These diagrams show the physical components of a system. To clarify it, we can say that component
diagrams describe the organization of the components in a system.

Organization can be further described as the location of the components in a system. These components
are organized in a special way to meet the system requirements.

As we have already discussed, those components are libraries, files, executables, etc. Before
implementing the application, these components are to be organized. This component organization is also
designed separately as a part of project execution.

Component diagrams are very important from implementation perspective. Thus, the implementation
team of an application should have a proper knowledge of the component details

Component diagrams can be used to −

● Model the components of a system.

● Model the database schema.

● Model the executables of an application.

● Model the system's source code.

 Experiment No: 9
Type of problem Forward engineering
List of program All Perform forward engineering in java.
Forward engineering is the process of transforming a model into code through a mapping to an
implementation language. Forward engineering results in a loss of information, because models written in
the UML are semantically richer than any current object-oriented programming language. In fact, this is a
major reason why you need models in addition to code. Structural features, such as collaborations, and
behavioral features, such as interactions, can be visualized clearly in the UML, but not so clearly from raw
code.
To forward engineer a class diagram,
● Identify the rules for mapping to your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
● Depending on the semantics of the languages you choose, you may want to constrain your use of
certain UML features. For example, the UML permits you to model multiple inheritance, but
Smalltalk permits only single inheritance. You can choose to prohibit developers from modeling
with multiple inheritance (which makes your models language-dependent), or you can develop
idioms that transform these richer features into the implementation language (which makes the
mapping more complex).
● Use tagged values to guide implementation choices in your target language. You can do this at the
level of individual classes if you need precise control. You can also do so at a higher level, such as
with collaborations or packages.
● Use tools to generate code.
Figure 8-4 illustrates a simple class diagram specifying an instantiation of the chain of responsibility
pattern. This particular instantiation involves three classes: Client, EventHandler, and GUIEventHandler.
The classes Client and EventHandler are abstract, whereas GUIEventHandler is
concrete. EventHandler has the usual operation expected of this pattern (handleRequest), although two
private attributes have been added for this instantiation.

Figure 8-4. Forward Engineering

All of these classes specify a mapping to Java, as noted in their stereotype. Forward engineering the
classes in this diagram to Java is straightforward, using a tool. Forward engineering the
class EventHandler yields the following code.
public abstract class EventHandler {
EventHandler successor;
private Integer currentEventID;
private String source;

EventHandler() {}
public void handleRequest() {}

}
 Experiment No: 10
Type of problem Reverse engineering.
List of program All Perform reverse engineering in java
Reverse engineering is the process of transforming code into a model through a mapping from a specific
implementation language. Reverse engineering results in a flood of information, some of which is at a
lower level of detail than you'll need to build useful models. At the same time, reverse engineering is
incomplete. There is a loss of information when forward engineering models into code, and so you can't
completely recreate a model from code unless your tools encode information in the source comments that
goes beyond the semantics of the implementation language.
To reverse engineer a class diagram,
● Identify the rules for mapping from your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
● Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new
model or modify an existing one that was previously forward engineered. It is unreasonable to
expect to reverse engineer a single concise model from a large body of code. You need to select
portion of the code and build the model from the bottom.
● Using your tool, create a class diagram by querying the model. For example, you might start with
one or more classes, then expand the diagram by following specific relationships or other
neighboring classes. Expose or hide details of the contents of this class diagram as necessary to
communicate your intent.
● Manually add design information to the model to express the intent of the design that is missing or
hidden in the code.
 Experiment No: 10
Type of problem Deployment diagram
List of program All Draw the deployment diagram.
Deployment diagrams are used to visualize the topology of the physical components of a system, where
the software components are deployed.

Deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams
consist of nodes and their relationships.

Purpose of Deployment Diagrams

The term Deployment itself describes the purpose of the diagram. Deployment diagrams are used for
describing the hardware components, where software components are deployed. Component diagrams
and deployment diagrams are closely related.

Component diagrams are used to describe the components and deployment diagrams shows how they are
deployed in hardware.

UML is mainly designed to focus on the software artifacts of a system. However, these two diagrams are
special diagrams used to focus on software and hardware components.

Most of the UML diagrams are used to handle logical components but deployment diagrams are made to
focus on the hardware topology of a system. Deployment diagrams are used by the system engineers.

The purpose of deployment diagrams can be described as −

● Visualize the hardware topology of a system.

● Describe the hardware components used to deploy software components.

● Describe the runtime processing nodes.

How to Draw a Deployment Diagram?

Deployment diagram represents the deployment view of a system. It is related to the component diagram
because the components are deployed using the deployment diagrams. A deployment diagram consists of
nodes. Nodes are nothing but physical hardware used to deploy the application.

Deployment diagrams are useful for system engineers. An efficient deployment diagram is
very important as it controls the following parameters −

● Performance

● Scalability

● Maintainability

● Portability

Before drawing a deployment diagram, the following artifacts should be identified −

● Nodes
 ● Relationships among nodes

Following is a sample deployment diagram to provide an idea of the deployment view of

order management system. Here, we have shown nodes as −

● Monitor

● Modem

● Caching server

● Server

The application is assumed to be a web-based application, which is deployed in a clustered environment

using server 1, server 2, and server 3. The user connects to the application using the Internet. The control
flows from the caching server to the clustered environment.

The following deployment diagram has been drawn considering all the points mentioned above.

Where to Use Deployment Diagrams?

Deployment diagrams are mainly used by system engineers. These diagrams are used to describe the
physical components (hardware), their distribution, and association.

Deployment diagrams can be visualized as the hardware components/nodes on which the software
components reside.

Software applications are developed to model complex business processes. Efficient software
applications are not sufficient to meet the business requirements. Business requirements can be described
as the need to support the increasing number of users, quick response time, etc.

To meet these types of requirements, hardware components should be designed efficiently and in a cost-
effective way.

Now-a-days software applications are very complex in nature. Software applications can be standalone,
web-based, distributed, mainframe-based and many more. Hence, it is very important to design the
hardware components efficiently.

Deployment diagrams can be used −

● To model the hardware topology of a system.

● To model the embedded system.

● To model the hardware details for a client/server system.

● To model the hardware details of a distributed application.

● For Forward and Reverse engineering.

 Quizzes
(Attached within the Folder)
 Sample Viva Questions
1. Define software engineering?
2. What are the categories of software?
3. Define testing?
4. What is white box testing?
5. What is black box testing?
6. What is verification and validation?
7. Define cyclomatic complexity?
8. What is error tracking?
9. What are case tools?
10. What is data design?
11. Define cohesion and coupling?
12. What are the different types of cohesion?
13. What are the different types of coupling?
14. What is user interface design?
15. Define process?
16. What are the SCM activities?
17. What is SDLC?
18. What are SDLC models available?
19. What are the advantages and disadvantages of white box testing?
20. What is meant by loop testing?
21. What is meant by smoke testing?
22. What is alpha and beta tests?
23. What is meant by system testing?
24. What are the advantages and disadvantages of black box testing?
25. Define prototype?
26. What is transform mapping?
27. List the metrics for specifying non functional requirements?
28. Mention the various types of maintenance?
29. What are various phases of SDLC?
30. What is software project management?
31. What is SRS?
32. Which SDLC model is the best?
33. Mention some project management tools.
34. What are software requirements?
35. What is feasibility study?
36. What are functional requirements?
37. What are non-functional requirements?
38. What is concurrency and how it is achieved in software?

ASSESSMENT PROCESS
ASSESSMENT TOOLS
 ⮚ Direct assessment tools:
✔ Quizzes
✔ Project Based Learning (PBL)
✔ External University Examinations.
⮚ Indirect assessment tool:
✔ Course exit survey.

INTERNAL AND EXTERNAL ATTAINMENT LEVELS

● Internal Assessment for theory and laboratory courses
✔ Attainment Level 1: Less than 60 % students scoring more than target marks.
✔ Attainment Level 2: 60 % to less than 70 % students scoring more than target
marks.
✔ Attainment Level 3: Greater than or equal to 70 % students scoring more than
target marks.
● External Assessment for theory and laboratory courses
✔ Attainment Level 1: Less than 50 % students scoring more than target marks.
✔ Attainment Level 2: 50 % to less than 60 % students scoring more than target
marks. Attainment Level 3: Greater than or equal to 60% students scoring more
than target marks.

Assessment Tools
Course
Outcomes
Direct Indirect

CO 1 Quiz 1, PBL, External University

Examinations

CO 2 Quiz 2, PBL, External University

Examinations
CO 3 Quiz 3, PBL, External University Course Exit Survey
Examinations
CO 4 Quiz 4, PBL, External University
Examinations
CO 5 Quiz 5, PBL, External University
Examinations