Industrial Training

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

http://www.kcbta.ac.in/

Industrial Training ReportOn

(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 AcademyIndore

(Affiliated to RGPV, Approved by AICTE)

Month & Year(July-August 2009)


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


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


Page 4

Acknowledgements

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.


Page 5

Table Of Content

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 Definition3.1 Objective(s)3.2 Project Scope.

4. Methodology4.1 The SDLC Waterfall4. 2Prototypes4.3 Other SDLC Models4.4 SDLC Stages4.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


Page 6

1.INTRODUCTION TO INDUSTRIAL TRAINING:-

1.1 GeneralIndustrial Training refers to work experience that is relevant to professional developmentprior to graduation. One of the requirements for the award of Bachelor of Engineering isthat students must complete at least 4 weeks of Industrial Training. Industrial Training isnormally accumulated during the semester breaks at the end of the third or fourth year.

Industrial Training is an essential component in the developmentof the practical and professional skills required of an Engineer and an aid to prospectiveemployment. Many employers regard this period as a chance to vet new employees forfuture 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 Introduction1.2.1 Industrial Training Objectivesa) To expose students to engineering experience and knowledge.Which is required in industry, where these are not taught in thelecture rooms.

b) To apply the engineering knowledge taught in the lecture rooms inreal industrial situations.

c) To use the experience gained from the ‘Industrial Training’ indiscussions held in the lecture rooms.

d) To get a feel of the work environment.

e) To gain experience in writing reports in engineeringworks/projects.

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

g) To expose the students to future employers as well as to introduce


Page 7

the Industrial Training Program available within Curtin Universityof Technology.

h) With all the experience and knowledge acquired, it is hoped at thestudents 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.


Page 8

http://en.wikipedia.org/wiki/Marketing_strategy

http://en.wikipedia.org/wiki/Company

http://en.wikipedia.org/wiki/Network_marketing

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.


Page 9

http://en.wikipedia.org/wiki/Word_of_mouth

http://en.wikipedia.org/wiki/Direct_selling

http://en.wikipedia.org/wiki/Hierarchy

http://en.wiktionary.org/wiki/downline

http://en.wikipedia.org/wiki/Multi-level_marketing#Compensation_plans

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

4. Methodology4.1 SDLC MODEL

THE SDLC WATERFALLSmall to medium database software projects are generally broken down into sixstages:

The relationship of each stage to the others can be roughly described as awaterfall, where the outputs from a specific stage serve as the initial inputs for thefollowing stage.During each stage, additional information is gathered or developed, combinedwith the inputs, and used to produce the stage deliverables. It is important to notethat the additional information is restricted in scope; “new ideas” that would takethe project in directions not anticipated by the initial set of high-levelrequirements are not incorporated into the project. Rather, ideas for newcapabilities or features that are out-of-scope are preserved for later consideration.After the project is completed, the Primary Developer Representative (PDR) andPrimary End-User Representative (PER), in concert with other customer anddevelopment team personnel develop a list of recommendations for enhancementof 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'regenerally similar to a movie set: everything looks good from the front but there's


Page 10

nothing in the back.When a prototype is generated, the developer produces the minimum amount ofcode necessary to clarify the requirements or design elements underconsideration. No effort is made to comply with coding standards, provide robusterror management, or integrate with other database tables or modules. As a result,it is generally more expensive to retrofit a prototype with the necessary elementsto produce a production module then it is to develop the module from scratchusing the final system design document.For these reasons, prototypes are never intended for business use, and aregenerally crippled in one way or another to prevent them from being mistakenlyused as production modules by end-users.

4.3 OTHER SDLC MODELSThe 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 LIFECYCLEThe 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 anevaluation period, the cycle is initiated again, adding new functionality andreleasing the next prototype. This process continues, with the prototype becominglarger and larger with each iteration. Hence, the “spiral.”The theory is that the set of requirements is hierarchical in nature, with additionalfunctionality building on the first efforts. This is a sound practice for systemswhere the entire problem is well defined from the start, such as modeling andsimulating software. Business-oriented database projects do not enjoy thisadvantage. Most of the functions in a database solution are essentiallyindependent of one another, although they may make use of common data. As aresult, the prototype suffers from the same flaws as the prototyping lifecycledescribed below. For this reason, the software development team has decidedagainst the use of the spiral lifecycle for database projects.

RAPID APPLICATION DEVELOPMENT (RAD) / PROTOTYPING LIFECYCLERAD 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 livesystem, as opposed to working strictly with documentation. RAD-baseddevelopment cycles have resulted in a lower level of rejection when theapplication is placed into production, but this success most often comes at theexpense of a dramatic overruns in project costs and schedule.The RAD approach was made possible with significant advances in softwaredevelopment environments to allow rapid generation and change of screens and


Page 11

other user interface features. The end user is allowed to work with the screensonline, as if in a production environment. This leaves little to the imagination, anda 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 intothe development effort. Since it seems so easy for the developer to produce thebasic screen, it must be just as easy to add a widget or two. In most RAD lifecyclefailures, the end users and developers were caught in an unending cycle ofenhancements, with the users asking for more and more and the developers tryingto satisfy them. The participants lost sight of the goal of producing a basic, usefulsystem 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 theoutputs from the previous stage, adding additional effort, and producing resultsthat 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 theoriginal intentions of the customer.

development efforts go awry when the development team andcustomer personnel get caught up in the possibilities of automation. Instead offocusing on high priority features, the team can become mired in a sea of “nice tohave” features that are not essential to solve the problem, but in themselves arehighly attractive. This is the root cause of a large percentage of failed and/orabandoned development efforts, and is the primary reason the development teamutilizes the Waterfall SDLC.

PLANNING STAGEThe 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


Page 12

associated with the project, and describe appropriate management and technicalapproaches.

The most critical section of the project plan is a listing of high-level productrequirements, also referred to as goals. All of the software product requirementsto be developed during the requirements definition stage flow from one or moreof these goals. The minimum information for each goal consists of a title andtextual description, although additional information and references to externaldocuments 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 detailedlisting of scheduled activities for the upcoming Requirements stage, and highlevel estimates of effort for the out stages.

REQUIREMENTS DEFINITION STAGEThe requirements gathering process takes as its input the goals identified in thehigh-level requirements section of the project plan. Each goal will be refined intoa set of one or more requirements.These requirements define the major functions of the intended application, defineoperational data areas and reference data areas, and define the initial data entities.Major functions include critical processes to be managed, as well as missioncritical inputs, outputs and reports. A user class hierarchy is developed andassociated with these major functions, data areas, and data entities.Each of these definitions is termed a Requirement. Requirements are identified byunique requirement identifiers and, at minimum, contain a requirement title andtextual description.

DESIGN STAGEThe design stage takes as its initial input the requirements identified in theapproved requirements document. For each requirement, a set of one or moredesign elements will be produced as a result of interviews, workshops, and/orprototype efforts.Design elements describe the desired software features in detail, and generallyinclude functional hierarchy diagrams, screen layout diagrams, tables of businessrules, business process diagrams, pseudocode, and a complete entity-relationshipdiagram with a full data dictionary. These design elements are intended todescribe the software in sufficient detail that skilled programmers may developthe software with minimal additional input.

DEVELOPMENT STAGEThe development stage takes as its primary input the design elements described inthe approved design document. For each design element, a set of one or more


Page 13

software artifacts will be produced. Software artifacts include but are not limitedto menus, dialogs, data management forms, data reporting formats, andspecialized procedures and functions. Appropriate test cases will be developedfor each set of functionally related software artifacts, and an online help systemwill be developed to guide users in their interactions with the software.

INTEGRATION & TEST STAGEDuring the integration and test stage, the software artifacts, online help, and testdata are migrated from the development environment to a separate testenvironment. At this point, all test cases are run to verify the correctness andcompleteness of the software. Successful execution of the test suite confirms arobust and complete migration capability.During this stage, reference data is finalized for production use and productionusers 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 intothe Production Initiation Plan.

INTEGRATION & TEST STAGEDuring the integration and test stage, the software artifacts, online help, and testdata are migrated from the development environment to a separate testenvironment. At this point, all test cases are run to verify the correctness andcompleteness of the software. Successful execution of the test suite confirms arobust and complete migration capability.During this stage, reference data is finalized for production use and productionusers 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 intothe Production Initiation Plan.

4.5 Scope RestrictionThe project scope is established by the contents of high-level requirements, alsoknown as goals, incorporated into the project plan. These goals are subsequentlyrefined into requirements, then design elements, then software artifacts.This hierarchy of goals, requirements, elements, and artifacts is documented in aRequirements Traceability Matrix (RTM). The RTM serves as a control elementto restrict the project to the originally defined scope.Project participants are restricted to addressing those requirements, elements, andartifacts that are directly traceable to product goals. This prevents the substantialoccurrence of scope creep, which is the leading cause of software project failure.


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


Page 15

5 ATTACHMENTS/PROJECT DOCUMENTATION :-

Total Entities:-

1 Rank_Master2 Rank_Detail3 Ins_Type4 Card_Type5 Table_Master6 Table_Detail7 Table_Fee8 Table_Ins9 Occupation10 Qualification11 Relation12 Officer_Master13 Officer_Senior14 Officer_Rank15 Card_Master16 Card_Detail


Page 16

17 Voucher_Commission18 Voucher_Bonus19 Rank_Bonus20 City_Table

RELATIONSHIP MATRIX:-

OFFICER SERVICE CARD CUSTOMER RANK

OFFICER ISSUES INTERACTS HAS

SERVICE CARD

CUSTOMER HAS

RANK IS OF


Page 17

7. UML Tools:-

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 bankingapplication, a customer entity represents an actor in the application. Similarly, the person whoprovides 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


Page 18

To identify an actor, search in the problem statement for business terms that portray roles in thesystem. 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 businessfunctionality in a system. The key term here is "distinct business functionality." To choose abusiness process as a likely candidate for modeling as a use case, you need to ensure that thebusiness 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 systemcannot have infinite functionality. So, it follows that use cases also need to have definitive limitsdefined. A system boundary of a use case diagram defines the limits of the system. The systemboundary is shown as a rectangle spanning all the use cases in the system.


Page 19

Figure shows the system boundary of the clinic application. The use cases of this system areenclosed 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.


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:


Page 21

Class: 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 accessmodifiers. You can apply access modifiers such as public access, protected access, and privateaccess applied to methods and attributes of a class—even to a class as well, if required. Theseaccess 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.


Page 22

Package:

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:


Page 23

Multiplicity:-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-containedrelationship.

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 classdiagram. Literally, the child classes "inherit" the common functionality defined in the parent class.


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:


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.


Page 26

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


Page 27

DIAGRAMS:-

CONTEXT DIAGRAM:-Zero Level Diagram:-


Page 28

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.

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:-TeamworkPuntualityCompany EnvironmentPractical Work ExperienceWorking Under Pressure


Page 29


Page 30


Page 31

Industrial Training

Documents

industrial training

weeks of industrial

practical training

required training report

generalindustrial training

major training report

real industrial situations

engineering knowledge