Noida Institute of Engineering & Technology,
Greater Noida
Branch: Computer Science and Engineering Semester: VIth (3rd
Year)
Software Engineering Programming Lab (ACSE-653)
Academic Session: (2023-24)
NOIDA INSTITUTE OF ENGINEERING & TECHNOLOGY
DEPARTMENT OF Computer Science and Engineering Session: 2023-24 (Odd
Semester)
Submitted by : Anurag Gupta
Submitted To : Dr. Poornima Tyagi , Mr. Punit Kumar
1|Page
INDEX
S. NO. Practical Page No Grade Signature
2|Page
Practical 1:
To prepare a SRS document in line with the IEEE recommended standards.
Description: A software requirements specification (SRS) is a document that captures
complete description about how the system is expected to perform. It is usually signed off at the end of
requirements engineering phase and it acts as an agreement between client/customers and developers.
SRS document in line with the IEEE Format
1. Introduction
1. Purpose
2. Scope
3. Definitions
4. References
5. Overview
2. General Description
1. Product Perspective
2. Product Functions
3. User Characteristics
4. General Constraints
5. Assumptions and Dependencies
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Functional Requirement 1
3.1.1.1 Introduction
3.1.1.2 Inputs
3.1.1.3 Processing
3.1.1.4 Outputs
3.1.2 Functional Requirement 2
…
3.2 External Interface Requirements
3.2.1 User Interface
3.2.2 Hardware Interfaces
3.2.3 Software Interfaces
3.2.4 Communication Interfaces
3.3 Performance Requirements
3.4 Design Constraints
3.4.1 Standards Compliance
3|Page
3.4.2 Hardware Limitations
3.5 Attributes
3.5.1 Security
3.5.2 Maintainability
3.6 Other Requirements
3.6.1 Database
4. System Features
5. Other Non functional Requirements
➢ 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.
➢ Draw the activity diagram.
➢ Identify the classes. Classify them as weak and strong classes and draw the class diagram.
➢ Draw the sequence diagram for any two scenarios.
➢ Draw the collaboration diagram.
➢ Draw the state chart diagram.
➢ Draw the component diagram.
➢ Draw the deployment diagram
Description for an ATM System (Problem Statement)
The software to be designed will control a simulated automated teller machine (ATM)
having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and
display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in
multiples of Rs. 100, Rs. 500 and Rs. 1000), a printer for printing customer receipts, and a
keyoperated switch to allow an operator to start or stop the machine. The ATM will communicate
with the bank's computer over an appropriate communication link. (The software on the latter is
not part of the requirements for this problem.)
The ATM will service one customer at a time. A customer will be required to insert an
ATM card and enter a personal identification number (PIN) - both of which will be sent to the
bank for validation as part of each transaction. The customer will then be able to perform one or
more transactions. The card will be retained in the machine until the customer indicates that
he/she desires no further transactions, at which point it will be returned - except as noted below.
The ATM must be able to provide the following services to the customer:
1. A customer must be able to make a cash withdrawal from any suitable account linked to the
card, in multiples of Rs. 100 or Rs. 500 or Rs. 1000. Approval must be obtained from
the bank before cash is dispensed.
2. A customer must be able to make a deposit to any account linked to the card,
4|Page
consisting of cash and/or checks in an envelope. The customer will enter the
amount of the deposit into the ATM, subject to manual verification when the envelope is
removed from the machine by an operator. Approval must be obtained from the bank
before physically accepting the envelope.
3. A customer must be able to make a transfer of money between any two accounts linked to
the card.
4. A customer must be able to make a balance inquiry of any account linked to the card.
5. A customer must be able to abort a transaction in progress by pressing the Cancel key
instead of responding to a request from the machine.
The ATM will communicate each transaction to the bank and obtain verification that it was
allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once
it has been approved. In the case of a deposit, a second message will be sent to the bank
indicating that the customer has deposited the envelope. (If the custom-er fails to deposit the
envelope within the timeout period, or presses cancel instead, no second message will be
sent to the bank and the deposit will not be credited to the customer.)
If the bank determines that the customer's PIN is invalid, the customer will be
required to re-enter the PIN before a transaction can proceed. If the customer is unable to
successfully enter the PIN after three tries, the card will be permanently retained by the
machine, and the customer will have to contact the bank to get it back If a transaction fails
for any reason other than an invalid PIN, the ATM will display an explanation of the
problem, and will then ask the customer whether he/she wants to do another transaction.
The ATM will provide the customer with a printed receipt for each successful transaction
The ATM will have a key-operated switch that will allow an operator to start and
stop the servicing of customers. After turning the switch to the "on" position, the operator
will be required to verify and enter the total cash on hand. The machine can only be turned
off when it is not servicing a customer. When the switch is moved to the "off" position, the
machine will shut down, so that the operator may remove deposit envelopes and reload the
machine with cash, blank receipts, etc.
INTRODUCTION ABOUT LAB
5|Page
CASE tools known as Computer-aided software engineering tools is a kind of
componentbased development which allows its users to rapidly develop information systems. The
main goal of case technology is the automation of the entire information systems development life
cycle process using a set of integrated software tools, such as modelling, methodology and
automatic code generation. Component based manufacturing has several advantages over custom
development. The main advantages are the availability of high quality, defect free prod-ucts at low
cost and at a faster time. The prefabricated components are customized as per the requirements of
the customers. The components used are pre-built, ready-tested and add value and differentiation by
rapid customization to the targeted customers. However the products we get from case tools are only
a skeleton of the final product required and allot of programming must be done by hand to get a
fully finished, good product.
Characteristics of CASE:
Some of the characteristics of case tools
It is a graphic oriented tool.
It supports decomposition of process.
Some typical CASE tools are:
Unified Modelling Language
Data modelling tools, and
Source code generation tools
Introduction to UML (Unified Modelling Language):
The unified modelling language (UML) is a standard language for writing software blue prints.
The UML is a language for
Visualizing
Specifying
Constructing
Documenting
The artifacts of a software system:
UML is a language that provides vocabulary and the rules for combing words in that
vocabulary for the purpose of communication.
A modelling language is a language whose vocabulary and rules focus on the concept and
physical representation of a system. Vocabulary and rules of a language tell us how to create and
real well formed models, but they don’t tell you what model you should create and when should
create them.
Visualizing
The UML is more than just a bunch of graphical symbols. In UML each symbol has
welldefined semantics. In this manner one developer can write a model in the UML and another
developer or even other tools can interpret the model unambiguously.
Specifying
6|Page
UML is used for specifying means building models that are precise, unambiguous and
complete. UML addresses the specification of all the important analysis, design and implementation
decisions that must be made in developing and deploying a software intensive system.
Constructing
UML is not a visual programming language but its models can be directly connected to a
variety of programming languages. This means that it is possible to map from a model in the UML
to a programming language such as java, C++ or Visual Basic or even to tables in a relational
database or the persistent store of an object-oriented database. This mapping permits for-ward
engineering. The generation of code from a UML model into a programming language. The reverse
engineering is also possible you can reconstruct a model from an implementation back into the
UML.
Documenting
UML is a language for Documenting. A software organization produces all sorts of arti-facts
in addition to raw executable code. These artifacts include Requirements, Architecture, De-sign,
Source code, Project plans, Test, Prototype, and Release. Such artifacts are not only the deliverables
of a project, they are also critical in controlling, measuring and communicating about a system
during its development and after its deployment.
Conceptual model of the UML:
To understand the UML, we need to form a conceptual model of the language and this
requires learning three major elements.
The UML Basic Building Blocks.
The Rules that direct how those building blocks may be put together. Some common
mchanisms that apply throughout the UML. As UML describes the real time systems it is very
important to make a conceptual model and then proceed gradually. Conceptual model of UML can
be mastered by learning the following three major elements:
UML building blocks
Rules to connect the building blocks.
Common mechanisms of UML.
UML building blocks. The building blocks of UML can be defined as:
Things
Relationships
Diagrams
Things: Things are the most important building blocks of UML.
Things can be:
7|Page
Structural
Behavioural
Grouping
An notational
Structural things:
Class: A class is the descriptor for a set of objects with similar structure, behaviour, and
relationships.
It is represented by a rectangle.
Interface: An interface is a specified for the externally-visible operations of a class, component, or
other
classifier (including subsystems) without specification of internal structure. It is represented
by a
circle.
Relations:
Association
Dependency
Generalization
Realization
In addition to this there are
Directed Association
Aggregation and
Composition
Association:
An association is a structural relationship that specifies the relation between two objects when they
are at the same level (peer level systems).
An Association can specify the relationship, role of the class and Multiplicity.
8|Page
An Association used in class diagram, Component diagram,
deployment diagram, usecase diagrams.
The multiplicity can be represented as 1-1..*,*,0…1. It is
represented as follows:
Directed Association:
Links a semantic association between two classes in the UML diagram.
Directed association is used in class diagram, Component diagram, deployment diagram,
usecase diagrams.
Symbol:
Aggregation:
Links a semantic association between two classes in the UML diagram.
Aggregation is used in class diagram. Symbol:
Composition:
Links a semantic association between two classes in the UML diagram.
Composition is used in class diagram. Symbol:
Generalization:
Generalization is a specification relationship in which objects of the specialized element (the
child) are substitutable for objects of the generalization element (the parent). It is used in class
diagram.
Symbol:
Dependency:
A dependency is a semantic relationship in which if there is any change occurred in one object that
may affect other object.
Dependency is used in class diagram, Component diagram, deployment diagram, use case
diagrams.
Symbol:
------------------------------------------
Realization:
Realization is a Specified tool that can be represented by providing a relationship with classifier.
Dependency is used in class diagram, Component diagram, deployment diagram, use case
diagrams.
Symbol:
----------------------------------------------
9|Page
Class diagrams:
A class diagram is that which represents a set of classes, interfaces, and collaborations and their
relationships, graphically a class diagram is a collection of vertices and arcs. It consists of three
compartments.
Name
Attributes
Operations
Uses: A class diagram is used to model the static design view of a system.
Object diagrams:
An object diagram shares the same common properties of all other diagrams.
Name
Attributes
Operations
Uses: An object diagram is used to model the static design view of a system.
Use Case Diagrams:
A use case diagram shares the common properties as all diagrams. It distinguishes in the contents of
use cases, actors, dependency, and generalization relationships.
Actor
Uses: A Usecase diagram is used to model the static design view of a system.
Interaction Diagrams:
An Interaction diagram shares the same common properties as all other diagrams. It differs in its
contents
Objects
Links
Messages
It includes two diagrams – Sequence and Collaboration
10 | P a g e
Sequence Diagrams:
A sequence diagram emphasizes the time ordering of messages. Sequence diagrams have two
features that distinguish them from collaboration diagrams.
(i)Object life time
(ii)The focus of control
Collaboration Diagrams:
A collaboration diagram emphasizes the organization of the objects that participate in an interaction
Collaboration diagrams have two features that distinguish them from sequence diagrams.
(i)Path
(ii) The Sequence number
Object: It is an instance of a class.
Symbol: Object name
Stimulus: A Stimulus is a communication between two Instances that conveys information with the
expectation that action will ensue. A Stimulus will cause an Operation to be invoked, raise a Signal,
or cause an Instance to be created or destroyed.
Symbol:
It can be annotated by a name. It has a property as Action kind.
Call:
Send:
Return: ------------------------------------------
Create:
<<create
>>
Destroy:
<<destroy>>
Uses: Interaction diagrams are used to model the dynamic aspects of a system. It is obtained in two
ways:
(i) To model flows of control by time ordering. (ii)
To model flows of control by organization.
11 | P a g e
State Chart Diagrams:
State: A state is a condition during the life of an object or an interaction during which it satisfies
some condition, performs some action, or waits for some event. It is represented by a rounded
rectangle.
Symbol:
State Name
Sub machine State: A submachine state is a syntactical convenience that facilitates reuse and
modularity. It is shorthand that implies a macro-like expansion by another state machine and is
Sub state name semantically equivalent to a
composite state.
Symbol:
Initial State:
An initial is a kind of pseudo state that represents the starting point in a region of a state ma-chine.
It has a single outgoing transition to the default state of the enclosing region, and has no incoming
transitions. There can be one (and only one) initial state in any given region of a state machine. It
is not itself a state but acts as a marker.
Symbol:
Final State: A final state represents the last or "final" state of the enclosing composite state.There
may be more than one final state at any level signifying that the composite state can end in different
ways or conditions. When a final state is reached and there are no other enclosing states it means
that the entire state machine has completed its transitions and no more transitions can occur.
Symbol:
Junction Point: Junction Point chains together transitions into a single run-to-completion path.May
have multiple input and/or output transitions. Each complete path involving a junction is logically
12 | P a g e
independent and only one such path fires at one time. May be used to construct branches and
merges.
Symbol:
Transition: A transition is a directed relationship between a source state vertex and a targetstate
vertex. It may be part of a compound transition, which takes the state machine from one state
configuration to another, representing the complete response of the state machine to a par-ticular
event instance.
Symbol:
Activity Diagram:
It represents the different activities in the system.
Action State: An action state represents the execution of an atomic action, typically the invocation
of an operation. An action state is a simple state with an entry action whose only exit transition is
triggered by the implicit event of completing the execution of the entry action. The state therefore
corresponds to the execution of the entry action itself and
the outgoing transition is activated as soon as the action has completed its execution.
Symbol:
Sub Activity State: A sub activity state represents the execution of a non-atomic sequence ofsteps
that has some duration; that is, internally it consists of a set of actions and possibly waiting for
events. That is, a sub activity state is a hierarchical action, where an associated sub activity graph is
executed.
Symbol:
Sub Activity Name
Initial State: An initial is a kind of pseudo state that represents the starting point in a region of
astate machine. It has a single outgoing transition to the default state of the enclosing region, and
13 | P a g e
has no incoming transitions. There can be one (and only one) initial state in any given region of a
state machine. It is not itself a state but acts as a marker.
Symbol:
Final State: A final state represents the last or "final" state of the enclosing composite state.There
may be more than one final state at any level signifying that the composite state can end in different
ways or conditions. When a final state is reached and there are no other enclosing states it means
that the entire state machine has completed its transitions and no more transitions can occur.
Symbol:
Decision: A state diagram (and by derivation an activity diagram) expresses a decision whenguard
conditions are used to indicate different possible transitions that depend on Boolean conditions of
the owning object
Component Diagrams:
Package: A package is a grouping of model elements. Packages themselves may be nestedwithin
other packages. A package may contain subordinate packages as well as other kinds of model
elements. All kinds of UML model elements can be organized into packages. Symbol:
Component: A component represents a modular, deployable, and replaceable part of a system
that encapsulates implementation and exposes a set of interfaces. Symbol:
14 | P a g e
Artifact: An Artifact represents a physical piece of information that is used or produced by a
software development process. Examples of Artifacts include models, source files, scripts, and
binary executable files. An Artifact may constitute the implementation of a deployable compo-nent.
Symbol:
<<Artifact>>
Deployment Diagrams:
Node: A node is a run-time physical object that represents a computational resource, generally
having at least a memory and often processing capability as well, and upon which components may
be deployed.
Symbol:
Node
Name
Node Instance: A node instance is an instance of a node. A collection of component instances may
reside on the node instance.
Symbol:
NodeName
Artifact: An Artifact represents a physical piece of information that is used or produced by a
software development process. Examples of Artifacts include models, source files, scripts, and
binary executable files. An Artifact may constitute the implementation of a deployable compo-nent.
Symbol:
<<Artifacts>>
ARCHITECTURE OF UML
15 | P a g e
Any real-world system is used by different users. The users can be developers, testers, business people,
analysts and many more. So before designing a system the architecture is made with different perspectives
in mind. The most important part is to visualize the system from different viewer’s perspective. The better
we understand the better we make the system. UML plays an important role in defining different
perspectives of a system. These perspectives are:
Design
Implementation
Process
Deployment
And the centre is the Use Case view which connects all these four. A Use case represents the
functionality of the system. So the other perspectives are connected with use case.
Design of a system consists of classes, interfaces, and collaboration. UML provides class diagram,
object diagram to support this. Implementation defines the components assembled together er to
make a complete physical system. UML component diagram is used to support implementation
perspective.
Process defines the flow of the system. So the same elements as used in Design are also used to
support this perspective.
Deployment represents the physical nodes of the system that forms the hardware. UML deployment
diagram is used to support this perspective.
Automatic Teller Machine
USE CASE DIAGRAM
Overview:
To model a system the most important aspect is to capture the dynamic behavior. To clarify
a bit in details, dynamic behavior means the behavior of the system when it is running operating. So
only static behavior is not sufficient to model a system rather dynamic behavior is more important
than static behavior. In UML there are five diagrams available to model dynamic nature and use
case diagram is one of them. Now as we have to discuss that the use case diagram is dynamic in
nature there should be some internal or external factors for making the interaction. These internal
and external agents are known as actors. So use case diagrams are consists of actors, use cases and
their relationships. The diagram is used to model the system/subsystem of an application. A single
use case diagram captures a particular functionality of a system. So to model the entire system
numbers of use case diagrams are used.
Purpose:
The purpose of use case diagram is to capture the dynamic aspect of a system. But this
definition is too generic to describe the purpose. Because other four diagrams (activity, sequence,
collaboration, and State chart) are also having the same purpose. So we will look into some specific
purpose which will distinguish it from other four diagrams. Use case diagrams are used to gather the
requirements of a system including internal and external influences. These requirements are mostly
16 | P a g e
design requirements. So when a system is analyzed to gather its functionalities use cases are
prepared and actors are identified.
So in brief, the purposes of use case diagrams can be as follows:
Used to gather requirements of a system.
Used to get an outside view of a system.
Identify external and internal factors influencing the system.
Show the interacting among the requirements are actors
17 | P a g e
Practical 1:To Prepare a SRS document in line with the IEEE recommended standards.
1. Introduction
1. Purpose
2. Scope
3. Definitions
4. References
5. Overview
2. General Description
1. Product Perspective
2. Product Functions
3. User Characteristics
4. General Constraints
5. Assumptions and Dependencies
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Func Req 1
3.1.1.1 Introduction
3.1.1.2 Inputs
3.1.1.3 Processing
3.1.1.4 Outputs
3.1.2 Func Req 2
…
3.2 External Interface Requirements
3.2.1 User Interface
3.2.2 Hardware Interfaces
3.2.3 Software Interfaces
3.2.4 Communication Interfaces
3.3 Performance Requirements
3.4 Design Constraints
3.4.1 Standards Compliance
3.4.2 Hardware Limitations
18 | P a g e
3.5 Attributes
3.5.1 Security
3.5.2 Maintainability
3.6 Other Requirements
3.6.1 Database
Practical 2:TO PREPARE THE USE CASE DIAGRAM FOR ATM.
Withdrawal Use Case
A withdrawal transaction asks the customer to choose a type of account to withdraw from
(e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of
possible amounts. The system verifies that it has sufficient money on hand to satisfy the request
before sending the transaction to the bank. (If not, the customer is informed and asked to enter a
different amount.) If the transaction is approved by the bank, the appropriate amount of cash is
dispensed by the machine before it issues a receipt. A withdrawal transaction can be can-celled by
the customer pressing the Cancel key any time prior to choosing the dollar amount.
Deposit Use Case
19 | P a g e
A deposit transaction asks the customer to choose a type of account to deposit to (e.g.
checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The
transaction is initially sent to the bank to verify that the ATM can accept a deposit from this
customer to this account. If the transaction is approved, the machine accepts an envelope from the
customer containing cash and/or checks before it issues a receipt. Once the envelope has been
received, a second message is sent to the bank, to confirm that the bank can credit the customer’s
account – contingent on manual verification of the deposit envelope contents by an operator later.
A deposit transaction can be cancelled by the customer pressing the Cancel key any time
prior to inserting the envelope containing the deposit. The transaction is automatically cancelled if
the customer fails to insert the envelope containing the deposit within a reasonable period of time
after being asked to do so.
Transfer Use Case
A transfer transaction asks the customer to choose a type of account to transfer from (e.g.
checking) from a menu of possible accounts, to choose a different account to transfer to, and to type
in a dollar amount on the keyboard. No further action is required once the transaction is approved by
the bank before printing the receipt.
A transfer transaction can be cancelled by the customer pressing the Cancel key any time
prior to entering a dollar amount.
Inquiry Use Case
An inquiry transaction asks the customer to choose a type of account to inquire about from a
menu of possible accounts. No further action is required once the transaction is approved by the
bank before printing the receipt. An inquiry transaction can be cancelled by the customer pressing
the Cancel key any time prior to choosing the account to inquire about.
Validate User usecase:
This usecase is for validate the user i.e check the pin number, when the bank reports that the
customer’s transaction is disapproved due to an invalid PIN. The customer is required to re-enter the
PIN and the original request is sent to the bank again. If the bank now approves the transaction, or
disapproves it for some other reason, the original use case is continued; otherwise the process of
reentering the PIN is repeated. Once the PIN is successfully re-entered
If the customer fails three times to enter the correct PIN, the card is permanently retained, a
screen is displayed informing the customer of this and suggesting he/she contact the bank, and the
entire customer session is aborted.
PrintBill usecase
This usecase is for printing corresponding bill after transactions (withdraw or deposit ,or
balance enquiry, transfer) are completed.
Update Account
This use case is for updating corresponding user accounts after transactions (withdraw or
deposit or transfer) are completed.
20 | P a g e
Practical 3: To prepare the ACTIVITY DIAGRAM.
Activity diagram is basically a flow chart to represent the flow form one activity to another.
The activity can be described as an operation of the system. So the control flow is drawn from one
operation to another. This flow can be sequential, branched or concurrent. Ac-tivity diagrams deals
with all type of flow by using elements like fork, join etc.
Contents
Initial/Final State , Activity , Fork & Join , Branch , Swimlanes
Fork
A fork represents the splitting of a single flow of control into two or more concur-rentFlow
of control. A fork may have one incoming transition and two or more outgoing transitions, each of
which represents an independent flow of control. Below fork the activities associated with each of
these path continues in parallel. Join
A join represents the synchronization of two or more concurrent flows of control. A join
may have two or more incoming transition and one outgoing transition. Above the join the activities
associated with each of these paths continues in parallel.
Branching
A branch specifies alternate paths takes based on some Boolean expression Branch is
represented by diamond Branch may have one incoming transition and two or more outgoing one on
each outgoing transition, you place a Boolean expression shouldn’t overlap but they should cover all
possibilities.
Swimlane:
Swimlanes are useful when we model workflows of business processes to partition the
activity states on an activity diagram into groups. Each group representing the business organization
responsible for those activities ,these groups are called Swimlanes .
21 | P a g e
Activity diagram for ATM
22 | P a g e
23 | P a g e
