School of Information Technology & Engineering
MTech Software Engineering
Software Architecture and design (SWE2004)
DIGITAL ASSIGNMENT
Title
TITLE: INVENTORY MANAGEMENT SYSTEM
Submitted by
JAIGANESH (19MIS0070)
SIDHESHWAR (19MIS0109)
SUNIL (19MIS0123)
Faculty : R.Kiruba Thangam
Slot:G2
INVENTORY MANAGEMENT SYSTEM
PROBLEM DISCRIPTION:
Inventory Management is one of the basic problems for a company. It may
cause a lot of paperwork, if there is no automated system available. Implementing such a
system is possible but there are a lot of preliminary works such as determination of the
requirements, system structure decision – software requirements, barcode system
selection and determination of the software tools, Inventory System is to provide a
Central Asset Repository of information used to define assets and relate the asset to its
owner, location, and relative importance.
The Inventory System should be integrated within the everyday
functions performed by personnel associated with entering and maintaining asset
information. The system will reduce the effort devoted to asset management, while
supplying many personnel with the information they need to perform their functional
responsibilities.
A small consignment shop needs a system to manage the inventory of
their store. They have an extremely limited budget, and do not want to purchase an
expensive software suite in such a risky economic environment. In a single software
package, they will need the ability to handle in-store transactions, mange inventory, create
reports, and create an online presence.
Inventory Management with analytics is an online software application which fulfills the
requirement of a typical Stock It provides the interface to users in a graphical way to manage
the daily transactions as well as historical data. Also provides the management reports like
monthly inwards, monthly deliveries and monthly returns. This application maintains the
centralized database so that any changes done at a location reflects immediately.
ARCHITECTURE STYLE:
PIPE AND FILTERS MODEL
CLIENT-SERVER MODEL
REPOSITARY MODEL
LAYERED ARCHITECTURE MODEL
BLACKBOARD MODEL
SUITABLE ARCHITECTURE STYLE
• I CHOOSE PIPE AND FILTERS MODEL AS A
SUITABLE ARCHITECTURE STYLE FROM THE
ABOVE MENTIONED ARCHITECTURE STYLE
REASON:
PIPE AND FILTERS MODEL:
• The pipe and filter is an architectural style that allows for a
• stream/asynchronous processing.
• This style is for large processes that can be broken down into
multiple steps,
• Each filter will be responsible for one of each steps
CONNECTORS AND COMPONENTS:
• Login
• Checks the availability
• View the transaction
• Add transaction
• Payment module
TOPOLOGY:
• Payment module contains stack of layers
• Choose the payment mode
• Pay the cash
SEMANTICS:
• Transaction details
• Customer details
ADVANTAGES:
• Simplicity–
• Allows the designer to understand overall input or output behavior
of the
system in terms of individual filters
• Concurrent execution–Each filter can be implemented as a separate
• task and be executed in parallel with other filters.
DISADVANTAGES:
• Interactive transformations are difficult–filters being independent
• Entities designer has to think of each filter as providing a complete
• transformation of input data to output data.
• No filter corporation.
PIPE LINE ARCHITECTURE :
DIAGRAMATIC REPRESENTATION
JUSTIFICATION :
Among the important invariants of the style is the condition that
filters must be independent entities; in particular, they should
not share state with other filters. Another important invariant is
that filters do not know the identity of their up streams and
down-stream filters. Their specification might restrict what
appears on the output pipes, but they may not identify the
components at the ends of those pipes. Furthermore, the
correctness of the output of a pipe and filter network should not
depend on the order in which the filters perform their
incremental processing although fair scheduling can be
assumed.
Common specialization of this include pipelines, which resists
the topologies to linear sequences of filters; bounded pipes,
which resists the amount of data that can reside on a pipe; and
typed pipes; which require that the data passes between two
filters have a well-defined type.
A degenerate case of a pipeline architecture occurs
when each filter process all of its input data as a single entity. In
this case the architecture becomes a batch sequential system.
In these systems pipes no longer serve the function of providing
a stream of data and therefore are largely vestigial. Hence such
systems are best treated as instances of a separate
architectural style.
The best-known example of pipe and filters architectures are
programs written in the UNIX shell. UNIX supports this style by
providing a notation for connecting components and by providing run
time mechanism for implementing pipes. As another well -known
example, traditionally compilers have been viewed as pipeline systems
