Lab File

On
Software Engineering
(KCS651)
Submitted for
Bachelor of Technology
In
Computer Science and Engineering
At

Krishna Engineering College, Ghaziabad

2020-21

Submitted To Submitted by
Ms. Shaili Singhal Ambuj Singh
Assistant Professor 1816110024
KEC, Ghaziabad
Exp. No. Practical Name Page No.

Prepare a Requirement document in by using Entity Relationship

Diagram.

To Draw a sample activity diagram for real project or system

Identify the classes. Classify them as weak and strong classes and draw
the class diagram.
Show how Project management is carried out in GanttProject.

Identification of basic blocks from a program and determining its

cyclomatic complexity

program
 Lab-1

Experiment Name: Identification of Software Requirement

Objective: Identify Functional and Non Functional Requirements from problem statement

Description:

The SE VLabs Institute has been recently setup to provide state-of-the-art research facilities
in the field of Software Engineering. Apart from research scholars (students) and professors,
it also includes quite a large number of employees who work on different projects undertaken
by the institution.
As the size and capacity of the institute is increasing with the time, it has been proposed to
develop a Library Information System (LIS) for the benefit of students and employees of the
institute. LIS will enable the members to borrow a book (or return it) with ease while sitting at
his desk/chamber. The system also enables a member to extend the date of his borrowing if
no other booking for that particular book has been made. For the library staff, this system aids
them to easily handle day-to-day book transactions. The librarian, who has administrative
privileges and complete control over the system, can enter a new record into the system when
a new book has been purchased, or remove a record in case any book is taken off the shelf.
Any non-member is free to use this system to browse/search books online. However, issuing
or returning books is restricted to valid users (members) of LIS only.
The final deliverable would a web application (using the recent HTML 5), which should run
only within the institute LAN. Although this reduces security risk of the software to a large
extent, care should be taken no confidential information (eg., passwords) is stored in plain
text
Solution

(1) Identification of Functional requirements

The above problem statement gives a brief description of the proposed system. From
the above, even without doing any deep analysis, we might easily identify some of the
basic functionality of the system:
New user registration: Any member of the institute who wishes to avail the facilities
of the library has to register himself with the Library Information System. On successful
registration, a user ID and password would be provided to the member. He has to use
this credentials for any future transaction in LIS.
Search book: Any member of LIS can avail this facility to check whether any particular
book is present in the institute's library. A book could be searched by its:
Title
Authors name
Publisher's name
User login: A registered user of LIS can login to the system by providing his employee
ID and password as set by him while registering. After successful login, "Home" page
for the user is shown from where he can access the different functionalities of LIS:
search book, issue book, return book, reissue book. Any employee ID not registered
with LIS cannot access the "Home" page -- a login failure message would be shown to
him, and the login dialog would appear again. This same thing happens when any
registered user types in his password wrong. However, if incorrect password has been
provided for three time consecutively, the security question for the user (specified while
registering) with an input box to answer it are also shown. If the user can answer the
security question correctly, a new password would be sent to his email address. In case
the user fails to answer the security question correctly, his LIS account would be
blocked. He needs to contact with the administrator to make it active again.
Issue book: Any member of LIS can issue a book against his account provided that:
The book is available in the library i.e. could be found by searching for it
in LIS
No other member has currently issued the book
Current user has not issued the maximum number of books that can
If the above conditions are met, the book is issued to the member.
Note that this FR would remain incomplete if the "maximum number of books that can
be issued to a member" is not defined. We assume that this number has been set to
 four for students and research scholars, and to ten for professors.
Once a book has been successfully issued, the user account is updated to reflect the
same.

Return book: A book is issued for a finite time, which we assume to be a period of 20
days. That is, a book once issued should be returned within the next 20 days by the
corresponding member of LIS. After successful return of a book, the user account is
updated to reflect the same.
Reissue book: Any member who has issued a book might find that his requirement is
not over by 20 days. In that case, he might choose to reissue the book, and get the
permission to keep it for another 20 days. However, a member can reissue any book at
most twice, after which he has to return it. Once a book has been successfully reissued,
the user account is updated to reflect the information.
In a similar way we can list other functionality offered by the system as well. However,
certain features might not be evident directly from the problem system, but which,
nevertheless, are required. One such functionality is "User Verification". The LIS
should be able to judge between a registered and non-registered member. Most of the
functionality would be available to a registered member. The "New User Registration"
would, however, be available to non-members. Moreover, an already registered user
shouldn't be allowed to register himself once again.
Having identified the (major) functional requirements, we assign an identifier to each
of them for future reference and verification.
Following table shows the list:
 (2) Identification of non-functional requirements

Having talked about functional requirements, let's try to identify a few non-functional
requirements.
Performance Requirements:
This system should remain accessible 24x7
At least 50 users should be able to access the system altogether
at any given time
Security Requirements:
This system should be accessible only within the institute LAN
The database of LIS should not store any password in plain text -
- a hashed value has to be stored
Software Quality Attributes
Database Requirements
Design Constraints:
The LIS has to be developed as a web application, which should
work with Firefox 5, Internet Explorer 8, Google Chrome 12, Opera
10
The system should be developed using HTML 5
Once all the functional and non-functional requirements have been identified, they are
documented formally in SRS, which then serves as a legal agreement.
 Lab-2

Experiment Name: Prepare a SRS document in line with the IEEE recommended
standards.

A sample of basic SRS

1. Introduction
1.1 Purpose
1.2 Document conventions

1.3 Intended audience

1.4 Additional information
1.5 Contact information/SRS team members
1.6 References
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies
3. External Interface Requirements
3.1 User interfaces

3.2 Hardware interfaces

3.3 Software interfaces
3.4 Communication protocols and interfaces
4. System Features
4.1 System feature

4.1.1 Description and priority

4.1.2 Action/result
4.1.3 Functional requirements 4.2 System
feature B
5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation

5.6 User documentation

6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list

Appendix B: To be determined
Solution : SRS FOR ATM

SOFTWARE REQUIREMENT SPECIFICATION

ATM

Version 1.0

March 8, 2021

AN AUTOMATED TELLER MACHINE

 Table of Contents

Introduction
Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview

The Overall Description

Product Perspective
Product Functions
User Characteristics
Constraints
Assumptions and Dependencies

External interface Requirements

User Interfaces
Hardware Interfaces
Software Interfaces
Communications Interfaces

4. System Features
5. Other Non-Functional Requirements
Performance Requirements
Capacity
Dynamic Requirements
Quality
Software System Attributes
Reliability
Availability
Security
Maintainability
Business Rules

Other Requirements .............................................................................

Appendix A: Glossary
Appendix S: Analysis Model
1.3 Definitions, Acronyms, and Abbreviations.

AC Alternate Current

AIMS ATM Information Management System.

ATM An unattended electronic machine in a public place, connected bank customer

to obtain cash withdrawals and other banking services.

A system of writing and printing for blind or visually impaired people, in which
varied arrangements of raised dots representing letters and numerals are identified
Braille by touch

Smart Card
Card software guard.

SRS Software Requirements Specification.

Tactile
keyboard Special keyboard designed to aid the visually impaired.

TCP/IP Transmission Control Protocol/Internet Protocol.

V Volts
 Lab-3

Experiment Name: Entity Relationship Diagram

Software Requirements: SmartDraw, MS Word.

Outcome: Can produce the requirements in Entity Relationship diagram.

Objective: Prepare a Requirement document in by using Entity Relationship Diagram.

Description: An Entity Relationship (ER) Diagram is a type o

such as people, objects or concepts relate to each other within a system. ER Diagrams are most often
used to design or debug relational databases in the fields of software engineering, business information
systems, education and research.

Components: An ER diagram is a means of visualizing how the information a system produces is

related. There are five main components of an ERD:

Entities, which are represented by rectangles. An entity is an object or concept about which you
want to store information. A weak entity is an entity that must defined by a foreign key
relationship with another entity as it cannot be uniquely identified by its own attributes alone.

Actions, which are represented by diamond shapes, show how two entities share information in
the database. In some cases, entities can be self-linked. For example, employees can supervise
other employees.
Attributes, which are represented by ovals. A key attribute is the unique, distinguishing
characteristic of the entity. For example, an employee's social security number might be the
employee's key attribute.

A multivalued attribute can have more than one value. For example, an employee entity can have
multiple skill values.

A derived attribute is based on another attribute. For example, an employee's monthly salary is
based on the employee's annual salary.

Connecting lines, solid lines that connect attributes to show the relationships of entities in the
diagram.
Cardinality specifies how many instances of an entity relate to one instance of another entity.
Ordinality is also closely linked to cardinality. While cardinality specifies the occurrences of a
relationship, ordinality describes the relationship as either mandatory or optional. In other words,
cardinality specifies the maximum number of relationships and ordinality specifies the absolute
minimum number of relationships.

There are many notation styles that express cardinality.

Tips for Effective ER Diagrams

Make sure that each entity only appears once per diagram.

Name every entity, relationship, and attribute on your diagram.

Examine relationships between entities closely. Are they necessary? Are there any relationships
missing? Eliminate any redundant relationships. Don't connect relationships to each other.

Use colors to highlight important portions of your diagram.

Entity Relationship Diagram Example

 Lab-4

Experiment Name: Data Flow Diagram

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse,
colored monitor.

Software Requirements: SmartDraw/MS Word, Windows XP.

Outcome: Can produce the requirements in Data Flow diagram.

Objective: Prepare a Requirement document in by using Data Flow Diagram.

Description: Data flow diagram is graphical representation of flow of data in an information system.
It is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not
mention anything about how data flows through the system.

There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in
program modules. DFDs depict flow of data in the system at various levels. DFD does not contain any
control or branch elements.

Components:

External Entity an outside system that sends or receives data, communicating with the system being
diagrammed. They are the sources and destinations of information entering or leaving the system. They
might be an outside organization or person, a computer system or a business system. They are also
known as terminators, sources and sinks or actors. They are typically drawn on the edges of the diagram.

Process any process that changes the data, producing an output. It might perform computations, or sort
data based on logic, or direct the data flow based on business rules. A short label is used to describe the

Data store files or repositories that hold information for later use, such as a database table or a
membership form. Each data store

Data flow the route that data takes between the external entities, processes and data stores. It portrays
the interface between the other components and is shown with arrows, typically labeled with a short
We start by identifying as many actors as possible. You should ask how the actors interact with the
system to identify an initial set of use cases. Then, on the diagram, you connect the actors with the use
cases with which they are involved. If actor supplies information, initiates the use case, or receives any
information as a result of the use case, then there should be an association between them.

Conclusion: The Use case diagram was made successfully by following the steps described above.

Output

Use Case Diagram Credit Card Processing

 Lab-6

Practical Name: Activity Diagram

Experiment Name: Activity Diagram.

Outcome: Can produce the activity diagram for requirements modeling.

Objective: To Draw a sample activity diagram for real project or system.

Description:

Hardware Requirements:

Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.

Software Requirements:

Argo UML, Windows XP,

Theory:

Activity diagrams are typically used for business process modeling, for modeling the logic captured by
a single usecase or usage scenario, or for modeling the detailed logic of a business rule. Although UML
activity diagrams could potentially model the internal logic of a complex operation it would be far better

many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow
diagrams (DFDs) from structured development.

Initial node. The filled in circle is the starting point of the diagram. An initial
although it does make it significantly easier to read the diagram.
Activity final node. The filled circle with a border is the ending point. An activity diagram can
have zero or more activity final nodes.

Activity. The rounded rectangles represent activities that occur. An activity may be physical,
such as Inspect Forms, or electronic, such as Display Create Student Screen.

Flow/edge. The arrows on the diagram. Although there is a subtle difference between flows and
edges, never a practical purpose for the difference although.
Fork. A black bar with one flow going into it and several leaving it. This denotes the beginning
of parallel activity.

Join. A black bar with several flows entering it and one leaving it. All flows going into the join
must reach it before processing may continue. This denotes the end of parallel processing.

Condition. Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to
true in order to traverse the node.

Decision. A diamond with one flow entering and several leaving. The flows leaving include
conditions although some modelers will not indicate the conditions if it is obvious.

Merge. A diamond with several flows entering and one leaving. The implication is that one or
more incoming flows must reach this point until processing continues, based on any guards on
the outgoing flow.

Partition. If figure is organized into three partitions, it is also called swim lanes, indicating
who/what is performing the activities (either the Applicant, Registrar, or System).
 Sub-activity indicator. The rake in the bottom corner of an activity, such as in the Apply to
University activity, indicates that the activity is described by a more finely detailed activity
diagram.

Flow final. The circle with the X through it. This indicates that the process stops at this point.

GUIDELINES ASSOCIATED FOR DRAWING AN ACTIVITY DIAGRAM

General Guidelines
Decision Points
Decision Points
Guards
Parallel Activities
Swim lane Guidelines
.Action-Object Guidelines
General Guidelines

Figure 1:Modeling a business process with a UML Activity Diagram.

 Place The Start Point In The Top-Left Corner. A start point is modeled with a filled in circle,
using the same notation that UML State Chart diagrams use. Every UML Activity Diagram
should have a starting point, and placing it in the top-left corner reflects the way that people in
Western cultures begin reading. Figure1, which models the business process of enrolling in a
university, takes this approach.

Always Include an Ending Point. An ending point is modeled with a filled in circle with a border
around it, using the same notation that UML State Chart diagrams use. Figure1 is interesting
because it does not include an end point because it describes a continuous process sometimes
ly.

Flowcharting Operations Implies the Need to Simplify. A good rule of thumb is that if an
operation is so complex you need to develop a UML Activity diagram to understand it that you
should consider refactoring it.

Activities

An activity, also known as an activity state, on a UML Activity diagram typically represents the
invocation of an operation, a step in a business process, or an entire business process.

o it but
none out, typically indicating that you have either missed one or more transitions.

into it, something that should be true only of start points.

Decision Points
A decision point is modeled as a diamond on a UML Activity diagram.

Decision Points Should Reflect the Previous Activity. In figure1 we see that there is no label on
the decision point, unlike traditional flowcharts which would include text describing the actual
decision being made, we need to imply that the decision concerns whether the person was
enrolled in the university based on the activity that the decision point follows. The guards,
depicted using the format [description], on the transitions leaving the decision point also help
to describe the decision point.

Avoid Superfluous Decision Points. The Fill Out Enrollment Forms activity in FIGURE1
includes an implied decision point, a check to see that the forms are filled out properly, which
simplified the diagram by avoiding an additional diamond.

Guards

A guard is a condition that must be true in order to traverse a transition.

Each Transition Leaving a Decision Point Must Have a Guard

Guards Should Not Overlap. For example guards such as x <0, x = 0, and x > 0 are consistent
whereas guard such as x <= 0 and x >= 0 are not consistent because they overlap
what should happen when x is 0.

Guards on Decision Points Must Form a Complete Set. For example, guards such as x < 0 and

Exit Transition Guards and Activity Invariants Must Form a Complete Set. An activity invariant
is a condition that is always true when your system is processing an activity.
 Guards Are Optional. It is very common for a transition to not include a guard, even when an
activity includes several exit transitions.

5. Parallel Activities

It is possible to show that activities can occur in parallel, as you see in FIGURE 1 depicted using two
parallel bars. The first bar is called a fork, it has one transition entering it and two or more transitions
leaving it. The second bar is a join, with two or more transitions entering it and only one leaving it.

A Fork Should Have a Corresponding Join. In general, for every start (fork) there is an end
(join). In UML 2 it is not required to have a join, but it usually makes sense.

Forks Have One Entry Transition.

Joins Have One Exit Transition

Avoid Superfluous Forks. FIGURE 2 depicts a simplified description of the software process of
enterprise architectural modeling, a part of the Enterprise Unified Process (EUP). There is
significant opportunity for parallelism in this process, in fact all of these activities could happen
in parallel, but forks were not introduced because they would only have cluttered the diagram.

Swimlane Guidelines

A swimlane is a way to group activities performed by the same actor on an activity diagram or to group
activities in a single thread. FIGURE 2 includes three swimlanes, one for each actor.
Figure2. A UML activity diagram for the enterprise architectural modeling
(simplified).

Figure 3. Submitting expenses.

Order Swimlanes in a Logical Manner.

 Apply Swim Lanes To Linear Processes. A good rule of thumb is that swimlanes are best applied
to linear processes, unlike the one depicted in FIGURE 3.

Have Less Than Five Swimlanes.

Consider Swimareas For Complex Diagrams.
Swimareas Suggest The Need to Reorganize Into Smaller Activity Diagrams.

Consider Horizontal Swimlanes for Business Processes. In FIGURE 3 you see that the
swimlanes are drawn horizontally, going against common convention of drawing them
vertically.

7 Action-Object Guidelines

Activities act on objects, In the strict object-oriented sense of the term an action object is a system
object, a software construct. In the looser, and much more useful for business application modeling,
sense of the term an action object is any sort of item. For example in FIGURE 3 the ExpenseForm
action object is likely a paper form.

Place Shared Action Objects on Swimlane Separators

When An Object Appears Several Time Apply State Names
State Names Should Reflect the Lifecycle Stage of an Action Object
Show Only Critical Inputs and Outputs
Depict Action Objects As Smaller Than Activities

Conclusion: The activity diagram was made successfully by following the steps described above.
 Lab-7

Experiment Name: Class Diagram

Experiment Name: Class diagram

Outcome: Class diagram helps to understand the static structure of a system. It shows relationships
between classes, objects, attributes, and operations.

Objective: Identify the classes. Classify them as weak and strong classes and draw the class diagram.

Description:

A class diagram models the static structure of a system. It shows relationships between classes, objects,
attributes, and operations.

Basic Class Diagram Symbols and Notations

Classes

Classes represent an abstraction of entities with common characteristics. Associations represent

the relationships between classes.

Illustrate classes with rectangles divided into compartments. Place the name of the class in the first
partition (centered, bolded, and capitalized), list the attributes in the second partition (left-aligned, not
bolded, and lowercase), and write operations into the third.
Active Classes

Active classes initiate and control the flow of activity, while passive classes store data and serve other
classes. Illustrate active classes with a thicker border.

Visibility

Use visibility markers to signify who can access the information contained within a class. Private
visibility, denoted with a - sign, hides information from anything outside the class partition. Public
visibility, denoted with a + sign, allows all other classes to view the marked information. Protected
visibility, denoted with a # sign, allows child classes to access information they inherited from a parent
class.

Associations

Associations represent static relationships between classes. Place association names above, on, or below
the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the
end of an association. Roles represent the way the two classes see each other.
Multiplicity (Cardinality)

Place multiplicity notations near the ends of an association. These symbols indicate the number of
instances of one class linked to one instance of the other class. For example, one company will have
one or more employees, but each employee works for just one company.

Constraint

Place constraints inside curly braces {}.

Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A, the
whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow diamond to
represent a simple aggregation relationship, in which the "whole" class plays a more important role than
the "part" class, but the two classes are not dependent on each other. The diamond ends in both
composition and aggregation relationships point toward the "whole" class (i.e., the aggregation).

Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship
between two classes where one class is a specialized version of another. For example, Honda is a type
of car. So the class Honda would have a generalization relationship with the class car.
In real life coding examples, the difference between inheritance and aggregation can be confusing. If
you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions
of the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC
and PROTECTED functions of the superclass.

UML Class Diagram: Association, Aggregation and Composition

The UML Class diagram is used to visually describe the problem domain in terms of types of objects
(classes) related to each other in different ways.

There are 3 primary inter-object relationships: Association, Aggregation, and Composition. Using the
right relationship line is important for placing implicit restrictions on the visibility and propagation of
changes to the related classes, a matter which plays an important role in understanding and reducing
system complexity.

i) Association

The most abstract way to describe static relationship between classes is using the Association link,
which simply states that there is some kind of a link or a dependency between two classes or more.
Weak Association

ClassA may be linked to ClassB in order to show that one of its methods includes parameter of ClassB
instance, or returns instance of ClassB.

Strong Association

ClassA may also be linked to ClassB in order to show that it holds a reference to ClassB instance.

ii) Aggregation (Shared Association) (Weak Class)

-of relationship between ClassA (whole) and ClassB (part), we can be more
specific and use the aggregation link instead of the association link, highlighting that the same ClassB
instance can also be aggregated by other classes in the application (therefore aggregation is also known
as shared association). Class B is weak Class.
 -
between the two. Actually, quite the opposite! The aggregation link is usually used to stress the point
that ClassA instance is not the exclusive container of ClassB instance, as in fact the same ClassB
instance has another container/s.

Aggregation v.s. Association

The association link can replace the aggregation link in every situation, while aggregation cannot

sB instance.

Martin Fowler suggest that the aggregation link should not be used at all because it has no added value
and it disturb consistency, Quoting Jim Rumbaugh "Think of it as a modeling placebo".

iii) Composition (Not-Shared Association) (Strong Class)

We should be more specific and use the composition link in cases where in addition to the part-of
relationship between ClassA and ClassB -
meaning that when ClassA is deleted then ClassB is also deleted as a result. Class Person is strong class.

The composition link shows that a class (container, whole) has exclusive ownership over other class/s
(parts), meaning that the container objects and its parts constitute a parent-child/s relationship.

Unlike association and aggregation, when using the composition relationship, the composed class
cannot appear as a return type or parameter type of the composite class. Thus, changes to the composed
class cannot propagate to the rest of the system. Consequently, usage of composition limits complexity
growth as the system grows.

Clarification: It is possible for a class to be composed by more than one class. For example, ClassA
may be composed by ClassB and ClassC. However, unlike aggregation, instances of ClassB and ClassC
will never share the same ClassA instance. That would violate the propagation of changes principle.
ClassB instance will have its own instance of ClassA, and ClassC instance will have its own instance
of ClassA.

Conclusion: The Class diagram was made successfully by following the steps described above.

Output: Class diagram

 Lab-8

Practical Name:
Lab-9
To determine McCabe's cyclomatic complexity, we observe that

E = # of edges = 7
N = # of nodes = 7 (including the ENTRY and EXIT nodes)
So, the cyclomatic complexity becomes:

Lab-10
Lab-11
Lab-12