DIGITAL ASSIGNMENT-1

SOFTWARE ENGINEERING

CSE3001 – F2 SLOT

PROJECT TITLE: ONLINE SUPERMARKET MANAGEMENT

SYSTEM

Prepared By:

GUNASEKHAR PATCHIGOLLA

16BCE0110
ABSTRACT:

The ―Online Supermarket Management System‖ is based on the sales transaction of items in
a supermarket. The first activity is based on adding the items to the system along with the rate
which are present in the supermarket and the name of the items which the supermarket will
agree to sell. This authority is given only to admin. Any modifications to be done in the item
name or the in the rate can be done only by admin. He also has the right to delete any item.
As the customer buys the products and comes to the billing counter, the user is supposed to
enter the item name he purchased and the quantity of the item he wanted to purchase. This is
not a huge a task. He can select out of those displayed. Finally, a separate will be generated
for each customer. This will be saved in the database. Any periodic records can be viewed at
any time. Simultaneously the customer details will be stored. The amount will be paid by
deducting the total amount acquired in the sales activity. Admin provides a unique username
and password for each employee through which he can login.

INTRODUCTION:

The Project ―Online Supermarket Management System‖ deals with the automation of billing,
counting and recording the information of the customer. This software will help the
salesperson in managing and maintaining the various types of records pertaining to the
customer and products. It also gives information about the items in stock and out of stock. So
it will be easy to keep a track on items. Since it is difficult to manage all these manually, this
system helps in managing all these in an automated system. The proposed system
supermarket management system deals with the automation of billing of items, storing the
customer details and stock details of items. Firstly, the if the staff member is new he will
have to signup first. Once he is done signing in he has to login, only then he can have access
to the billing of items. Once the items are selected the customer details will have to be
entered. If the customer is a regular customer, he or she will get an additional discount. Also
discount will be applicable for customers based on their billing amount. This is the overall
view of the system.

CASE Tools:

Computer-Aided Software Engineering (CASE) technologies are tools that provide

automated assistance for software development. The goal of introducing CASE tools is the
reduction of the time and cost of software development and the enhancement of the quality of
the systems developed. The interest in CASE tools and environments is based on expectations
about increasing productivity, improving product quality, facilitating maintenance, and
making software engineers' task less odious and more enjoyable. A survey of the CASE tool
market showed that the annual worldwide market for CASE fools was $4.8 billion in 1990
and grew to $12.11 billion in 1995. Behind such a prosperous CASE market, however,
another result gained from the real investigation about the use of CASE tools revealed that
CASE tools seem to be sparsely used after being bought in many enterprises.

CASE is the use of computer-based support in the software development process; a CASE
tool is a computer-based product aimed at supporting one or more software engineering
activities within a software development process; a CASE environment is a collection of
CASE tools and other components together with an integration approach that supports most
or all of the interactions that occur among the environment components, and between the
users of the environment and the environment itself.

Popular features of CASE tools:

The term Computer-Aided Software Engineering encompasses many different products

with different functionalities. In the International Workshop on Computer-Aided
Software Engineering definition of CASE very broad terms are used: ―tools and methods
to support engineering approach to systems development at all stages of the process‖.
When the term CASE is used, it is important to clarify what is being discussed. Most
classifications of CASE tools start by considering whether the tool is upper CASE, lower
CASE, or integrated CASE. An upper CASE tool (front end CASE) provides support for
the early stages in the systems development life cycle such as requirements analysis and
design. A lower CASE tool (back end CASE) provides support for the later stages in the
life cycle such as code generation and testing. Integrated CASE tools support both the
early and later stages. Further classifications usually list which functionalities are
supported by the tool, such as data flow diagrams, entity relationships data models, etc.
provides a different type of model of CASE functionality which helps organize CASE
tools.

CASE Tools and its scope:

CASE technology is the automation of step by step methodologies for software and
system development. CASE tools are characterized by the stage or stages of software
development life cycle on which they focus. Since different tools covering different
stages share common information, it is required that they integrate through some central
repository system (data dictionary) to have a consistent view of such information. In
phases of software development life cycle integrated through a central data dictionary.
Case Tools are used in many ways in our organizations. Case tools can be broadly classed
into these broader areas:
 Requirement Analysis Tool
 Structure Analysis Tool
 Software Design Tool
 Code Generation Tool
 Test Case Generation Tool
 Document Production Tool
 Reverse Engineering Tool

While many organizations still use the SDLC methodology, it is often supplemented with
other methods. Many systems developers use the CASE tools in various stages of the
Software Development Life Cycle. They mainly use it while developing the following
methodologies:
 Life Cycle
 Object-oriented Approach
 Rapid Applications Development (RAD)
 Prototyping
 Joint Applications Development (JAD)
Visual Integration of CASE Tools:
Although a CASE shell is very useful for the creation and integration of CASE tools, we
believe it still is not simple and intuitive enough for CASE users. We suggest to provide
CASE users with more intuitive means to describe the integration of CASE tools. A
diagramming tool, similar to DFD diagramming tool, might be useful for this purpose. Pipe-
filter, event-trigger and message passing models are all useful means to realize the integration
of CASE tools.

SURVEY ON CASE TOOLS:

Computer-aided software engineering (CASE)

It is the domain of software tools used to design and implement applications. CASE tools are
similar to and were partly inspired by computer-aided design (CAD) tools used for designing
hardware products. CASE tools are used for developing high-quality, defect-free, and
maintainable software.

CASE tools support specific tasks in the software development life-cycle. They can be
divided into the following categories:

1) Business and Analysis modeling. Graphical modeling tools.

E.g: E/R modeling, object modeling, etc.

2) Development, Design and construction phases of the life-cycle. Debugging environments.

E.g: GNU Debugger.

3) Verification and validation. Analyze code and specifications for correctness and
performance.

4) Configuration management. Control the check-in and check-out of repository objects and
files.

5) Metrics and measurement. Analyze code for complexity, modularity (e.g., no "go to's"),
performance, etc.

6) Project management.

Another common way to distinguish CASE tools is the distinction between Upper CASE and
Lower CASE.

Upper CASE Tools support business and analysis modeling. They support traditional
diagrammatic languages such as ER diagrams, Data flow diagram, Structure charts, Decision
Trees, Decision tables, etc.

Lower CASE Tools support development activities, such as physical design, debugging,
construction, testing, component integration, maintenance, and reverse engineering. All other
activities span the entire life-cycle and apply equally to upper and lower CASE.
Types of CASE tools:

• Diagramming Tools: Help in diagrammatic and graphical representations of the data and
system processes.

• Computer Display and Report Generators: Help in understanding the data requirements
and the relationships involved.

• Analysis Tools: Focus on inconsistent, incorrect specifications involved in the diagram and
data flow.

• Central Repository: Provides the single point of storage for data diagrams, reports and
documents related to project management.

• Documentation Generators: Help in generating user and technical documentation as per

standards.

• Code Generators: Aid in the auto generation of code, including definitions, with the help
of the designs, documents and diagrams.

Reasons for using CASE tools:

• Savings in resources required for software development—with less.

• Quick development phase.

• Reduction of generation of errors.

• Easier recognition of bugs during development.

• Savings in maintenance resources required.

• To increase productivity.

• To help produce enhanced quality software at lower cost.

Applying the CASE Tool for the project:

CASE TOOLS USED FOR PROJECT:

 RATIONAL ROSE
 PENCIL
SEQUENTIAL DIAGRAM USING RATIONAL ROSE:
COLLABORATION DIAGRAM USING RATIONAL ROSE:
CLASS DIAGRAM USING RATIONAL ROSE:
USE CASE DIAGRAM USING RATIONAL ROSE:
USER INTERFACE DESIGN USING PENCIL:

Figure: Admin Module Sign Up Interface

Figure: Customer Module User Interface

COCOMO Model:

Software Cost Estimation models can be possible by several estimation models such as Line
of Code, Function Point and Constructive Cost Model (COCOMO). The original COCOMO
model is one of the most widely practical and popular among the software development
community because of some flexibility usages.

Using COCOMO model for performing cost estimation for the product:

A top-down model can depend on many different factors, instead of depending only on one
variable, giving rise to multivariable models. One approach for building multivariable models
is to start with an initial estimate determined by using the static single-variable model
equations, which depend on size, and then adjusting the estimates based on other variables.
This approach implies that size is the primary factor for cost; other factors have a lesser
effect. Here we will discuss one such model called the COnstructiveCOstMOdel (COCOMO)
developed by Boem. This model also estimates the total effort in terms of person-months.
The basic steps in this model are:

Obtain an initial estimate of the development effort from the estimate of thousands of
delivered lines of source code (KLOC).

Online Super Market Management System uses around 367 lines of code. The lines of code
are divided into various modules according to their functionality.

 Header files – 8 LOC

 Class used in project – 44 LOC
 Global declaration of stream object – 5 LOC
 Function to write in file – 10 LOC
 Function to read all record – 19 LOC
 Function to read specific file – 24 LOC
 Function to modify record – 35 LOC
 Function to delete record – 32 LOC
 Function to display all product – 32 LOC
 Place order & generating bill – 48 LOC
 Introduction function – 22 LOC
 Administrator MENU – 39 LOC
 Main function of program – 37 LOC.

The initial estimate (also called nominal estimate) is determined by an equation of the form
used in the static single-variable models, using KLOC as the measure of size.
To determine the initial effort in person-months the equation used is of the type Ei = a ^
(KLOC)^. The value of the constants a and b depend on the project type. In COCOMO,
projects are categorized into three types-—organic, semidetached, and embedded. These
categories roughly characterize the complexity of the project with organic projects being
those that are relatively straightforward and developed by a small team, and embedded are
those that are ambitious and novel, with stringent constraints from the environment and high
requirements for such aspects as interfacing and reliability.

The constants a and b for different systems is:

 Organic 3.2 1.05

 Semidetached 3.0 1.12
 Embedded 2.8 1.20

We are considering our project as an Organic Model.

Hence, a= 3.2 and b=1.05 Initial Effort = a*(LOC)^b = 9.52 PM.

The value of the constants for a cost model depends on the process and has to be determined
from past data. COCOMO has instead provided "global" constant values. These values
should be considered as values to start with until data for some projects is available. With
project data, the value of the constants can be determined through regression analysis. There
are 15 different attributes, called cost driver attributes^ that determine the multiplying factors.
These factors depend on product, computer, personnel, and technology attributes (called
project attributes). Examples of the attributes are required software rehabilitee (RELY),
product complexity (CPLX), analyst capability (ACAP), application experience (AEXP), use
of modern tools (TOOL), and required development schedule (SCHD), each cost driver has a
rating scale, and for each rating, a multiplying factor is provided.

In COCOMO, effort for a phase is a defined percentage of the overall effort. The percentage
of total effort spent in a phase varies with the type and size of the project. The percentages for
an organic software project are given in Table. Using this table, the estimate of the effort
required for each phase can be determined from the total effort estimate.

TOTAL EFFORT ESTIMATE = 1.115*9.51 = 10.603

(ASSUMING average estimate = 1.115).

In these way we have done the Survey and Apply of CASE Tools for our project.