K.C.B.

TECHNICAL ACADEMY

A Major Training report submitted to

Rajiv Gandhi Prodyogiki Vishwavidyalaya, Bhopal

towards the partial fulfillment for the award of

“Bachelor of Engineering (Information Technology)”

Submitted to: Submitted by:

Mrs. Anjali Namdev Rahul Vyas
(0834IT061042)

Department of Information Technology

KCB Technical Academy

Indore

(www.kcbta.ac.in)

Industrial Training Report

Page 1
 Industrial Training Report
On

(Multilevel Marketing - LIFECARE MULTISERVICES PVT LTD )

At Company
(Epsilon IT Solutions)

Submitted by

Rahul Vyas
(Roll No-0834IT061042)

In partial fulfillment for the award of the degree

Of

Bachelor Of Engineering

In

Information Technology

K.C.B Technical Academy

Indore

(Affiliated to RGPV, Approved by AICTE)

Month & Year

(July-August 2009)

Industrial Training Report

Page 2
 CERTIFICATE

This is to certify that Rahul Vyas (0834IT061042) student of K.C.B. College of Engineering
And Technology 4rth year Information Technology Department has submitted required
training report.

This work is up to the mark of satisfaction. We wish her success in every aspect of life. She has
performed this seminar on her own. She has also put in sufficient time for completion. All the
required norms have been followed & the report is submitted in proper order.

Guided By:
Mr.Ritesh sir

KCB Technical Academy, Indore

Industrial Training Report

Page 3
 Industrial Training Approval Sheet

The Major Training Report submitted by Rahul Vyas (0834IT061042) is approved as partial
fulfillment for the award of the Bechelor of Engineering (Information Technology) degree by
Rajiv Gandhi Proudyogiki Vishwavidyalaya, Bhopal.

Internal Examiner External Examiner

Acknowledgements
Industrial Training Report

Page 4
The expertise, skill, generosity and hard work of many individuals and organizations contributed
significantly to the success of this training.

It’s a great pleasure and moment of immense satisfaction for us to express my

profound gratitude towards the Company Epsilon IT Solutions where we completed our training
program , Their insight of knowledge of this domain made us realize that Practical knowledge
always helps to develop efficient operational software, which is a blend of all core subjects of the
field. We are immensely indebted to them for their invaluable guidance and ever-ready support
in the successful completion of this industrial training program in time. Working under their
guidance has been a fruitful and unforgettable experience.

I Rahul Vyas is grateful to my HOD sir Mr. Rajiv Vishwakarma who gave us this
opportunity .I also express my deep sense of respect & gratitude to my faculty Mrs Anjali
Namdev for their guidance

Rahul Vyas
(0834IT061043)
Information Technology.

Table Of Content

Industrial Training Report

Page 5
 1. Introduction to Practical Training
1.1 General
1.2 Introduction
1.2.1 Objective Of Industrial Training

2. Background of the Company

2.1 Main activities/Business Operation

3.The Project/System Definition

3.1 Objective(s)
3.2 Project Scope.

4. Methodology
4.1 The SDLC Waterfall
4. 2Prototypes
4.3 Other SDLC Models
4.4 SDLC Stages
4.5 Scope Restriction

5. Technology Used

6. Attachments/Project Documentation

7. UML Tools

7.1 Use Case Diagram

7.2 Sequence Diagram

7.3 Class Diagram

7.4 State Transition Diagram

7.5 Activity Diagram

8. Problems and Issues in current situations / system

9. Suggestions & Recommendations for new Proposals/System

10. Experiences

Industrial Training Report

Page 6
1.INTRODUCTION TO INDUSTRIAL TRAINING:-
1.1 General
Industrial Training refers to work experience that is relevant to professional development
prior to graduation. One of the requirements for the award of Bachelor of Engineering is
that students must complete at least 4 weeks of Industrial Training. Industrial Training is
normally accumulated during the semester breaks at the end of the third or fourth year.

Industrial Training is an essential component in the development

of the practical and professional skills required of an Engineer and an aid to prospective
employment. Many employers regard this period as a chance to vet new employees for
future employment.

Whilst difficult, it is desirable to obtain experience in a range of activities, such as e.g. design
office, laboratory and on-sitesituations. It should also be noted that developing an awareness of
general workplacebehaviour and interpersonal skills are important objectives of the Industrial
Training experience.

1.2 Introduction
1.2.1 Industrial Training Objectives
a) To expose students to engineering experience and knowledge.
Which is required in industry, where these are not taught in the
lecture rooms.

b) To apply the engineering knowledge taught in the lecture rooms in

real industrial situations.

c) To use the experience gained from the ‘Industrial Training’ in

discussions held in the lecture rooms.

d) To get a feel of the work environment.

e) To gain experience in writing reports in engineering

works/projects.

f) To expose students to the engineers responsibilities and ethics.

Industrial Training Report

Page 7
g) To expose the students to future employers as well as to introduce
the Industrial Training Program available within Curtin University
of Technology.

h) With all the experience and knowledge acquired, it is hoped at the

students will be able to choose appropriate work upon graduation.

2. Background of the Company

2.1 MAIN ACTIVITIES/BUISNESS OPERATION OF THE
ORGANIZATION:-

Epsilon is an Offshore Software Development specialist that combines the definite bottom-line
benefits of Offshore Outsourcing with its recognized expertise in strategic global models thathelp
it in providing reliable Outsourcing Software Development Solutions.

The services offered cover Custom Software Development, Application Development, Web
Application Development, Agile Software Development, Software Outsourcing, Ecommerce
web site design, Web Marketing, Website Design and Software Maintenance. Their goal is to
deliver premium quality software development services and products while giving unmatched
value to enterprises worldwide at an affordable cost.

Focuses on helping other company to reduce its IT costs without reducing the quality of IT
products. Epsilon believe in getting it done quickly and correctly the first time. Their strength in
internet applications development helps them in delivering highly customized solutions for their
clients. They are specialize in creating highly usable, scalable, robust technology in any
industry.

In addition to creating successful technology, Epsilon place great value in customer service and
client engagement. By working with a client and encouraging their interaction, their developers
gain insight and ideas to create a final product that is consistently better than the client
envisioned. Enjoying ongoing relationships with clients and also have extensive experience in
maintenance and enhancement of existing client products.

3.THE PROJECT SYSTEM DEFINITION :-

PROJECT NAME :- MULTILEVEL MARKETING MANAGEMENT

{ LIFECARE MULTISERVICES PVT LTD }

Multi-level marketing (MLM), (also called network marketingis a term that describes a
marketing structure used by some companies as part of their overall marketing strategy.

Industrial Training Report

Page 8
The structure is designed to create a marketing and sales force by compensating promoters of
company products not only for sales they personally generate, but also for the sales of other
promoters they introduce to the company, creating a downline of distributors and a hierarchy of
multiple levels of compensation in the form of a pyramid.The products and company are usually
marketed directly to consumers and potential business partners by means of relationship referrals
and word of mouth marketing.

3.1 OBJECTIVE :-

The objective is to design and develop a Multilevel Marketing System Software for Lifecare
Multiservices Pvt Ltd. which issues Service Cards to get maximum benfit of insurance with The
Oriental Insurance Company Ltd. MLM is essentially any business where payouts occur at two
or more levels. For instance, if we make a sale, both we and the person who recruited us will get
a portion of the proceeds.

3.2 PROJECT SCOPE:-

THE GOOD SIDE

Here are some of the benefits of finding a reputable MLM company:
- They have an established and very marketable product line or service, and strive to improve or
add to the existing line-up.
- No experience will be required.
A good MLM company will provide one-on-one training, as well as motivational seminars and a
full compliment of training materials. After all, in Multilevel marketing, when one succeeds all
succeed.
- A reputable MLM company will be "Family" rated, meaning that crude conduct is not tolerated.
- They will provide an excellent bonus plan with many incentives for those who excel.
- There will be a successful business and marketing plan in place that can be successfully
duplicated by others, assuming they apply themselves to the plan and are motivated to succeed.
- There exists the possibility of full-time or part-time commitment.
In context of Lifecare Multiservices Pvt Ltd have different rank of officers distinguished among
the basis of experience and no of service card distributors.Like SO,FO,DMO till 14th rank.

THE DOWNSIDE
While the MLM model can be a great tool to achieve what we want in life, it would be remiss
not to mention the downside.
- It is easy to get 'taken' by a disreputable MLM company. Do your research.
- If you plan on developing a network - a "downline" - it will cost you more money than you
realize and take you longer than you think - although this is slight compared to the cost and time
required to start up a traditional business.
You will spend a lot on resource and training materials that you will end up giving away to
prospects and to your downline distributors.
- Some companies insist on a minimum monthly order to maintain your distributorship.

Industrial Training Report

Page 9
- Some companies only pay you for recruiting other distributors and not on their total sales
volume.

4. Methodology
4.1 SDLC MODEL

THE SDLC WATERFALL

Small to medium database software projects are generally broken down into six
stages:

The relationship of each stage to the others can be roughly described as a

waterfall, where the outputs from a specific stage serve as the initial inputs for the
following stage.
During each stage, additional information is gathered or developed, combined
with the inputs, and used to produce the stage deliverables. It is important to note
that the additional information is restricted in scope; “new ideas” that would takethe project in
directions not anticipated by the initial set of high-level
requirements are not incorporated into the project. Rather, ideas for new
capabilities or features that are out-of-scope are preserved for later consideration.
After the project is completed, the Primary Developer Representative (PDR) and
Primary End-User Representative (PER), in concert with other customer and
development team personnel develop a list of recommendations for enhancement
of the current software.
4.2 Prototypes:-
The software development team, to clarify requirements and/or design elements,
may generate mockups and prototypes of screens, reports, and processes.
Although some of the prototypes may appear to be very substantial, they're
generally similar to a movie set: everything looks good from the front but there's

Industrial Training Report

Page 10
nothing in the back.
When a prototype is generated, the developer produces the minimum amount of
code necessary to clarify the requirements or design elements under
consideration. No effort is made to comply with coding standards, provide robust
error management, or integrate with other database tables or modules. As a result,
it is generally more expensive to retrofit a prototype with the necessary elements
to produce a production module then it is to develop the module from scratch
using the final system design document.
For these reasons, prototypes are never intended for business use, and are
generally crippled in one way or another to prevent them from being mistakenly
used as production modules by end-users.

4.3 OTHER SDLC MODELS

The waterfall model is one of the three most commonly cited lifecycle models.
Others include the Spiral model and the Rapid Application Development (RAD)
model, often referred to as the Prototyping model.

SPIRAL LIFECYCLE
The spiral model starts with an initial pass through a standard waterfall lifecycle,
using a subset of the total requirements to develop a robust prototype. After an
evaluation period, the cycle is initiated again, adding new functionality and
releasing the next prototype. This process continues, with the prototype becoming
larger and larger with each iteration. Hence, the “spiral.”
The theory is that the set of requirements is hierarchical in nature, with additional
functionality building on the first efforts. This is a sound practice for systems
where the entire problem is well defined from the start, such as modeling and
simulating software. Business-oriented database projects do not enjoy this
advantage. Most of the functions in a database solution are essentially
independent of one another, although they may make use of common data. As a
result, the prototype suffers from the same flaws as the prototyping lifecycle
described below. For this reason, the software development team has decided
against the use of the spiral lifecycle for database projects.

RAPID APPLICATION DEVELOPMENT (RAD) / PROTOTYPING

LIFECYCLE
RAD is, in essence, the “try before you buy” approach to software development.
The theory is that end users can produce better feedback when examining a live
system, as opposed to working strictly with documentation. RAD-based
development cycles have resulted in a lower level of rejection when the
application is placed into production, but this success most often comes at the
expense of a dramatic overruns in project costs and schedule.
The RAD approach was made possible with significant advances in software
development environments to allow rapid generation and change of screens and
other user interface features. The end user is allowed to work with the screens
Industrial Training Report

Page 11
online, as if in a production environment. This leaves little to the imagination, and
a significant number of errors are caught using this process.
The down side to RAD is the propensity of the end user to force scope creep into
the development effort. Since it seems so easy for the developer to produce the
basic screen, it must be just as easy to add a widget or two. In most RAD lifecycle
failures, the end users and developers were caught in an unending cycle of
enhancements, with the users asking for more and more and the developers trying
to satisfy them. The participants lost sight of the goal of producing a basic, useful
system in favor of the siren song of glittering perfection.

4.4 SDLC Stages:-

The six stages of the SDLC are designed to build on one another, taking the
outputs from the previous stage, adding additional effort, and producing results
that leverage the previous effort and are directly traceable to the previous stages.
This top-down approach is intended to result in a quality product that satisfies the
original intentions of the customer.

development efforts go awry when the development team and

customer personnel get caught up in the possibilities of automation. Instead of
focusing on high priority features, the team can become mired in a sea of “nice to
have” features that are not essential to solve the problem, but in themselves are
highly attractive. This is the root cause of a large percentage of failed and/or
abandoned development efforts, and is the primary reason the development team
utilizes the Waterfall SDLC.

PLANNING STAGE
The planning stage establishes a bird's eye view of the intended software product,
and uses this to establish the basic project structure, evaluate feasibility and risks
associated with the project, and describe appropriate management and technical

Industrial Training Report

Page 12
approaches.

The most critical section of the project plan is a listing of high-level product
requirements, also referred to as goals. All of the software product requirements
to be developed during the requirements definition stage flow from one or more
of these goals. The minimum information for each goal consists of a title and
textual description, although additional information and references to external
documents may be included.
The outputs of the project planning stage are the configuration management plan,
the quality assurance plan, and the project plan and schedule, with a detailed
listing of scheduled activities for the upcoming Requirements stage, and highlevel estimates of
effort for the out stages.

REQUIREMENTS DEFINITION STAGE

The requirements gathering process takes as its input the goals identified in the
high-level requirements section of the project plan. Each goal will be refined into
a set of one or more requirements.
These requirements define the major functions of the intended application, define
operational data areas and reference data areas, and define the initial data entities.
Major functions include critical processes to be managed, as well as mission
critical inputs, outputs and reports. A user class hierarchy is developed and
associated with these major functions, data areas, and data entities.
Each of these definitions is termed a Requirement. Requirements are identified by
unique requirement identifiers and, at minimum, contain a requirement title and
textual description.

DESIGN STAGE
The design stage takes as its initial input the requirements identified in the
approved requirements document. For each requirement, a set of one or more
design elements will be produced as a result of interviews, workshops, and/or
prototype efforts.
Design elements describe the desired software features in detail, and generally
include functional hierarchy diagrams, screen layout diagrams, tables of business
rules, business process diagrams, pseudocode, and a complete entity-relationship
diagram with a full data dictionary. These design elements are intended to
describe the software in sufficient detail that skilled programmers may develop
the software with minimal additional input.

DEVELOPMENT STAGE
The development stage takes as its primary input the design elements described in
the approved design document. For each design element, a set of one or more
software artifacts will be produced. Software artifacts include but are not limited
to menus, dialogs, data management forms, data reporting formats, and

Industrial Training Report

Page 13
specialized procedures and functions. Appropriate test cases will be developed
for each set of functionally related software artifacts, and an online help system
will be developed to guide users in their interactions with the software.

INTEGRATION & TEST STAGE

During the integration and test stage, the software artifacts, online help, and test
data are migrated from the development environment to a separate test
environment. At this point, all test cases are run to verify the correctness and
completeness of the software. Successful execution of the test suite confirms a
robust and complete migration capability.
During this stage, reference data is finalized for production use and production
users are identified and linked to their appropriate roles. The final reference data
(or links to reference data source files) and production user list are compiled into
the Production Initiation Plan.

INTEGRATION & TEST STAGE

During the integration and test stage, the software artifacts, online help, and test
data are migrated from the development environment to a separate test
environment. At this point, all test cases are run to verify the correctness and
completeness of the software. Successful execution of the test suite confirms a
robust and complete migration capability.
During this stage, reference data is finalized for production use and production
users are identified and linked to their appropriate roles. The final reference data
(or links to reference data source files) and production user list are compiled into
the Production Initiation Plan.

4.5 Scope Restriction

The project scope is established by the contents of high-level requirements, also
known as goals, incorporated into the project plan. These goals are subsequently
refined into requirements, then design elements, then software artifacts.
This hierarchy of goals, requirements, elements, and artifacts is documented in a
Requirements Traceability Matrix (RTM). The RTM serves as a control element
to restrict the project to the originally defined scope.
Project participants are restricted to addressing those requirements, elements, and
artifacts that are directly traceable to product goals. This prevents the substantial
occurrence of scope creep, which is the leading cause of software project failure.

Industrial Training Report

Page 14
5. TECHNOLOGY USED:-

.NET Technology & Web Project Development Tools

.NET Technology :-

.NET :- .Net is the platform to create the applications and software.

Main properties of .Net are:-

• Web services

• XML(extensible markup language)

• Remoting

• Cross language interoperatibility

• ADO.Net

• Unicode

Advantages of .Net are:-

• Platform independence

• Performance improvement

• Language Interoperatibility

• Garbage collection

• Security

Industrial Training Report

Page 15
5 ATTACHMENTS/PROJECT DOCUMENTATION :-

Total Entities:-

1 Rank_Master
2 Rank_Detail
3 Ins_Type
4 Card_Type
5 Table_Master
6 Table_Detail
7 Table_Fee
8 Table_Ins
9 Occupation
10 Qualification
11 Relation
12 Officer_Master
13 Officer_Senior
14 Officer_Rank
15 Card_Master
16 Card_Detail

Industrial Training Report

Page 16
17 Voucher_Commission
18 Voucher_Bonus
19 Rank_Bonus
20 City_Table

RELATIONSHIP MATRIX:-

OFFICER SERVICE CARD CUSTOMER RANK

OFFICER ISSUES INTERACTS HAS

SERVICE CARD

CUSTOMER HAS

RANK IS OF

7. UML Tools:-

Industrial Training Report

Page 17
We gained an overview of what the Unified Modeling Language stands for and what are the nine
diagrams that make up UML. Because UML is essentially a set of diagrams, you can simply
draw them by hand on a piece of paper. But, drawing UML diagrams on a piece of paper is
certainly not a best practice to design systems. Software applications simplify the task of
drawing diagrams of software designs. In addition, because the design is in an electronic format,
archiving the design for future use, collaborating on the design becomes much easier. Also,
routine tasks can be automated by using a UML tool. Hence, using a UML tool is by far the most
preferred way for designing software applications.

7.1 USE CASE DIAGRAM:-

The Use case diagram is used to identify the primary elements and processes that form the
system. The primary elements are termed as "actors" and the processes are called "use cases."
The Use case diagram shows which actors interact with each use case.
A use case diagram captures the functional aspects of a system. More specifically, it
captures the business processes carried out in the system. As you discuss the functionality and
processes of the system, you discover significant characteristics of the system that you model in
the use case diagram. Due to the simplicity of use case diagrams, and more importantly, because
they are shorn of all technical jargon, use case diagrams are a great storyboard tool for user
meetings. Use case diagrams have another important use. Use case diagrams define the
requirements of the system being modeled and hence are used to write test scripts for the
modeled system.

Elements of a Use Case Diagram:-

A use case diagram is quite simple in nature and depicts two types of elements: one representing
the business roles and the other representing the business processes. Let us take a closer look at
use at what elements constitute a use case diagram.

Actors:

An actor portrays any entity (or entities) that performs certain roles in a given system. The
different roles the actor represents are the actual business roles of users in a given system. An
actor in a use case diagram interacts with a use case. For example, for modeling a banking
application, a customer entity represents an actor in the application. Similarly, the person who
provides service at the counter is also an actor. But it is up to you to consider what actors make
an impact on the functionality that you want to model. If an entity does not affect a certain piece
of functionality that you are modeling, it makes no sense to represent it as an actor. An actor is
shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown
in Figure

Industrial Training Report

Page 18
To identify an actor, search in the problem statement for business terms that portray roles in the
system. For example, in the statement "patients visit the doctor in the clinic for medical tests,"
"doctor" and "patients" are the business roles and can be easily identified as actors in the system.

Use case:

A use case in a use case diagram is a visual representation of a distinct business

functionality in a system. The key term here is "distinct business functionality." To choose a
business process as a likely candidate for modeling as a use case, you need to ensure that the
business process is discrete in nature. As the first step in identifying use cases, you should list the
discrete business functions in your problem statement. Each of these business functions can be
classified as a potential use case. Remember that identifying use cases is a discovery rather than
a creation. As business functionality becomes clearer, the underlying use cases become more
easily evident. A use case is shown as an ellipse in a use case diagram.

Figure shows two uses cases: "Make appointment" and "Perform medical tests" in the use case
diagram of a clinic system. As another example, consider that a business process such as
"manage patient records" can in turn have sub-processes like "manage patient's personal
information" and "manage patient's medical information." Discovering such implicit use cases is
possible only with a thorough understanding of all the business processes of the system through
discussions with potential users of the system and relevant domain knowledge.

System boundary:

A system boundary defines the scope of what a system will be. A system
cannot have infinite functionality. So, it follows that use cases also need to have definitive limits
defined. A system boundary of a use case diagram defines the limits of the system. The system
boundary is shown as a rectangle spanning all the use cases in the system.

Industrial Training Report

Page 19
Figure shows the system boundary of the clinic application. The use cases of this system are
enclosed in a rectangle. Note that the actors in the system are outside the system boundary.
The system boundary is potentially the entire system as defined in the problem
statement. But this is not always the case. For large and complex systems, each of the modules
may be the system boundary. For example, for an ERP system for an organization, each of the
modules such as personnel, payroll, accounting, and so forth, can form the system boundary for
use cases specific to each of these business functions. The entire system can span all of these
modules depicting the overall system boundary.

7.2 SEQUENCE DIAGRAM:-

A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of
methods in each object, and the order in which the invocation occurs is captured in a Sequence
diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic
behavior of a system.
A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows
the life of the object that it represents, while on the vertical axis, it shows the sequence of the
creation or invocation of these objects.
Because it uses class name and object name references, the Sequence diagram is very
useful in elaborating and detailing the dynamic design and the sequence and origin of invocation
of objects. Hence, the Sequence diagram is one of the most widely used dynamic diagrams in
UML.
A sequence diagram is made up of objects and messages. Objects are represented
exactly how they have been represented in all UML diagrams—as rectangles with the underlined
class name within the rectangle.

Industrial Training Report

Page 20
Elements of a Sequence diagram:-
A Sequence diagram consists of the following behavioral elements:

7.3 CLASS DIAGRAM:-

A class diagram is similar to a family tree. A class diagram consists of a group of classes and
interfaces reflecting important entities of the business domain of the system being modeled, and
the relationships between these classes and interfaces. The classes and interfaces in the diagram
represent the members of a family tree and the relationships between the classes are analogous to
relationships between members in a family tree. Interestingly, classes in a class diagram are
interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or
matriarch of the family, as the case may be) and related child classes under the parent classes.
A class diagram is a pictorial representation of the detailed system design. Design
experts who understand the rules of modeling and designing systems design the system's class
diagrams. A thing to remember is that a class diagram is a static view of a system. The structure
of a system is represented using class diagrams. Class diagrams are referenced time and again by
the developers while implementing the system.

Elements of a Class Diagram:-

A class diagram is composed primarily of the following elements that represent the
system's business entities:

Class:

Industrial Training Report

Page 21
A class represents an entity of a given system that provides an encapsulated implementation of
certain functionality of a given entity. These are exposed by the class to other classes as methods.
Apart from business functionality, a class also has properties that reflect unique features of a
class. The properties of a class are called attributes. Simply put, individual members of a family
of our family tree example are analogous to classes in a class diagram.
As an example, let us take a class named Student. A Student class represents student
entities in a system. The Student class encapsulates student information such as student id #,
student name, and so forth. Student id, student name, and so on are the attributes of the Student
class. The Student class also exposes functionality to other classes by using methods such as
getStudentName(), getStudentId(), and the like. Let us take a look at how a class is represented
in a class diagram.
A class is represented by a rectangle. The following diagram shows a typical class in a
class diagram:

If you are familiar with object-oriented concepts, you will be aware of the concept of access
modifiers. You can apply access modifiers such as public access, protected access, and private
access applied to methods and attributes of a class—even to a class as well, if required. These
access modifiers determine the scope of visibility of the class and its methods and attributes.

Interface:

An interface is a variation of a class. As we saw from the previous point, a class provides an
encapsulated implementation of certain business functionality of a system. An interface on the other hand
provides only a definition of business functionality of a system. A separate class implements the actual
business functionality.
An interface shares the same features as a class; in other words, it contains attributes
and methods. The only difference is that that the methods are only declared in the interface and
will be implemented by the class implementing the interface.

Package:

Industrial Training Report

Page 22
 A package provides the ability to group together classes and/or interfaces that are either similar
in nature or related. Grouping these design elements in a package element provides for better
readability of class diagrams, especially complex class diagrams.

From Figure you can see a package is represented as a tabbed folder. A package can also have
relationships with other packages similar to relationships between classes and interfaces.

Relationships Between Classes:-

In a class diagram, obviously you can't have classes just floating around; you need to see the
relationship between them. The following table shows the kinds of relationships between classes,
their notation, and what they mean.

Association:-
When two classes are connected to each other in any way, an association relation is established
For example: A "student studies in a college" association can be shown as:

Multiplicity:-

Industrial Training Report

Page 23
An example of this kind of association is many students belonging to the same college. Hence,
the relation shows a star sign near the student class (one to many, many to many, and so forth
kind of relations).

Directed Association:-
Association between classes is bidirectional by default. You can define the flow of the
association by using a directed association. The arrowhead identifies the container-contained
relationship.

Aggregation:-
When a class is formed as a collection of other classes, it is called an aggregation relationship
between these classes. It is also called a "has a" relationship.

Inheritance/Generalization:-

Also called an "is a" relationship, because the child class is a type of the parent class.
generalization is the basic type of relationship used to define reusable elements in the class
diagram. Literally, the child classes "inherit" the common functionality defined in the parent
class.

Industrial Training Report

Page 24
7.4STATE DIAGRAM:-

State diagrams (also called State Chart diagrams) are used to help the developer better
understand any complex/unusual functionalities or business flows of specialized areas of the
system. In short, State diagrams depict the dynamic behavior of the entire system, or a sub-
system, or even a single object in a system. This is done with the help of Behavioral elements.
These diagrams give an architectural and high-level view of a system. In a typical
software life cycle, the business or functional domain experts define Use Case diagrams. The
Class diagrams and Object diagrams are made by senior-level developers, with the help of
system architects. Once this has been accomplished, and the system design and architecture is in
place, these artifacts are passed on to the developer, who actually codes the system. All the
above diagrams are static diagrams, which means that they help in visualizing what the elements
of the complete system would be, but do not say anything about the flows any object of the
system can have when an event occurs. Structural elements are used to depict static diagrams.

Elements of a State diagram:-

A State diagram consists of the following behavioral elements:

Industrial Training Report

Page 25
7.5 ACTIVITY DIAGRAM:-

The easiest way to visualize an Activity diagram is to think of a flowchart of a code. The
flowchart is used to depict the business logic flow and the events that cause decisions and actions
in the code to take place. Activity diagrams represent the business and operational workflows of
a system. An Activity diagram is a dynamic diagram that shows the activity and the event that
causes the object to be in the particular state. So, what is the importance of an Activity diagram,
as opposed to a State diagram? A State diagram shows the different states an object is in during
the lifecycle of its existence in the system, and the transitions in the states of the objects. These
transitions depict the activities causing these transitions, shown by arrows. An Activity diagram
talks more about these transitions and activities causing the changes in the object states.

Industrial Training Report

Page 26
Elements of an Activity diagram:-
An Activity diagram consists of the following behavioral elements:

Industrial Training Report

Page 27
Industrial Training Report

Page 28
DIAGRAMS:-

Industrial Training Report

Page 29
CONTEXT DIAGRAM:-
Zero Level Diagram:-

8. PROBLEMS AND ISSUES IN CURRENT SITUATIONS / SYSTEM :-

Many companies that market their products through distributors sell quality items at competitive
prices. But some offer goods that are overpriced, have questionable merits or are downright
unsafe to use. Management of this price rates should be provided in software

Proper authorization should be given to different rank users for better security.

For each user authentication should be provided.

Existing old system was difficult to understand and learn by user.

9. SUGGESTIONS AND RECOMMENDATIONS FOR NEW PROPOSAL /

SYSTEM :-
Future enhancement and updation scope should be kept at the time of coding.

Application for membership shall be made in the prescribed application form only.

Industrial Training Report

Page 30
Issue of receipts should be done by only authenticated user.

Security measures should be increased in Multilevel Marketing Software.

At each new level a security check should be provided.

10.EXPERIENCES:-
Teamwork
Puntuality
Company Environment
Practical Work Experience
Working Under Pressure

Industrial Training Report

Page 31
Industrial Training Report

Page 32