CHAPTER-FOUR

DESIGN

4.1 OVERVIEW
This chapter explains the data flow, class, object, use case, activity diagram for the easy
understanding of this project. It helps in explaining the project with ease to the user or project
manager. These diagram gives an prototype on which the whole project was built. Specifying the
structure of how a software system will be written and function, without actually writing the
complete implementation. As the strategic value of software increases for many companies,
the industry looks for techniques to automate the production of software and to improve
quality and reduce cost and time-to-market.

These techniques include component technology, visual programming, patterns and

frameworks. Businesses also seek techniques to manage the complexity of systems as
they increase in scope and scale.

In particular, they recognize the need to solve recurring architectural problems, such as
physical distribution, concurrency, replication, security, load balancing and fault
tolerance.

Additionally, the development for the World Wide Web, while making some things
simpler, has exacerbated these architectural problems. The Unified Modeling Language
(UML) was designed to respond to these needs.

4.2 CLASS DIAGRAM

In software engineering, a class diagram in the Unified Modeling Language  is a type of static

structure diagram that describes the structure of a system by showing the system's classes, their
attributes, operations, and the relationships among objects. The class diagram is the main
building block of object-oriented modelling. It is used for general conceptual modelling of the
systematic of the application, and for detailed modelling translating the models
into programming code. Class diagrams can also be used for modeling. The classes in a class
diagram represent both the main elements, interactions in the application, and the classes to be
programmed.
4.3 OBJECT DIAGRAM

A developer will find object diagrams useful in many instances. These include:

 Examining a specific iteration of a general system.

 Getting a high-level overview of the system you will develop.

 Testing a class diagram you’ve created for the overall structure of the system, using
object diagrams for specific use cases.
4.4 ENTITY RELATIONSHIP DIAGRAM
An entity relationship diagram shows the relationships of entity sets stored in a database. An
entity in this context is a component of data. In other words, ER diagrams illustrate the logical
structure of databases.
At first glance an entity relationship diagram looks very much like a flowchart. It is the
specialized symbols, and the meanings of those symbols, that make it unique.
4.5 USE CASE DIAGRAM
Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions
(use cases) that some system or systems (subject) should or can perform in collaboration with
one or more external users of the system (actors). Each use case should provide some observable
and valuable result to the actors or other stakeholders of the system.
Note, that UML 2.0 to 2.4 specifications also described use case diagram as a specialization of
a class diagram, and class diagram is a structure diagram.
Use case diagrams are in fact twofold - they are both behavior diagrams, because they describe
behavior of the system, and they are also structure diagrams  as a special case of class diagrams
where classifiers are restricted to be either actors or use cases related to each other
with associations.
4.6 FLOW CHART
A flowchart is a diagram that depicts a process, system or computer algorithm. They are widely
used in multiple fields to document, study, plan, improve and communicate often complex
processes in clear, easy-to-understand diagrams. Flowcharts, sometimes spelled as flow charts,
use rectangles, ovals, diamonds and potentially numerous other shapes to define the type of step,
along with connecting arrows to define flow and sequence. They can range from simple, hand-
drawn charts to comprehensive computer-drawn diagrams depicting multiple steps and routes. If
we consider all the various forms of flowcharts, they are one of the most common diagrams on
the planet, used by both technical and non-technical people in numerous fields. Flowcharts are
sometimes called by more specialized names such as Process Flowchart, Process Map,
Functional Flowchart, Business Process Mapping, Business Process Modeling and Notation
(BPMN),  or Process Flow Diagram (PFD). They are related to other popular diagrams, such as
Data Flow Diagrams (DFDs) and Unified Modeling Language (UML) Activity Diagrams.
4.7 ACTIVITY DIAGRAM
Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. In the Unified modelling Language,
activity diagrams are intended to model both computational and organizational
processes. Activity diagrams show the overall flow of control.
4.8 DATA FLOW DIAGRAM
A data flow diagram (DFD) is a graphical representation of the "flow" of data through
an information system, modelling its process aspects. A DFD is often used as a preliminary step
to create an overview of the system without going into great detail, which can later be elaborated.
DFDs can also be used for the visualization of data processing (structured design).
A DFD shows what kind of information will be input to and output from the system, how the
data will advance through the system, and where the data will be stored. It does not show
information about process timing or whether processes will operate in sequence or in parallel,
unlike a traditional structured flowchart which focuses on control flow, or a UML activity
workflow diagram, which presents both control and data flows as a unified model.
4.9 SEQUENCE DIAGRAM
4.6.1 Product Management Sequence diagram

Sequence diagrams have been used right from the beginning in object-oriented modelling. The
basic idea is to show the sequence of the activities done by the user. A sequence diagram shows
object interactions arranged in time sequence. It depicts the objects and classes involved in the
scenario and the sequence of messages exchanged between the objects needed to carry out the
functionality of the scenario. Sequence diagrams are typically associated with use case realizations
in the Logical View of the system under development. Sequence diagrams are sometimes
called event diagrams or event scenarios

.
.
4.10 STATE TRANSITION DIAGRAM
State transition diagrams have been used right from the beginning in object-oriented modeling.
The basic idea is to define a machine that has a number of states (hence the term finite state
machine). The machine receives events from the outside world, and each event can cause the
machine to transition from one state to another. For an example, take a look at figure 1. Here the
machine is a bottle in a bottling plant. It begins in the empty state. In that state it can receive
squirt events. If the squirt event causes the bottle to become full, then it transitions to the full
state, otherwise it stays in the empty state (indicated by the transition back to its own state).
When in the full state the cap event will cause it to transition to the sealed state. The diagram
indicates that a full bottle does not receive squirt events, and that an empty bottle does not
receive cap events. Thus you can get a good sense of what events should occur, and what effect
they can have on the object.
4.11 DEPLOYMENT DIAGRAM

Deployment diagrams have several valuable applications. You can use them to:

 Show which software elements are deployed by which hardware elements.

 Illustrate the runtime processing for hardware.

 Provide a view of the hardware system’s topology.

4.11 COLLABORATION DIAGRAM
 collaboration diagram is a type of visual presentation that shows how various software objects
interact with each other within an overall IT architecture and how users can benefit from this
collaboration. A collaboration diagram often comes in the form of a visual chart that resembles a
flow chart. It can show, at a glance, how a single piece of software complements other parts of a
greater system.

4.11.1 EMPLOYER :-
4.11.2 ADMIN :-
4.11.3 CUSTOMER :-