A Web Usage Mining Framework for Evolving User Profiles.

A Web Usage Mining Framework For

Mining Evolving User Profiles In

Dynamic Web Sites

CONTENTS

Abstract

Organization Profile

Introduction

Object Oriented Analysis and Design (OOAD)

Requirement Analysis Document

1. Introduction

a. Purpose of the system

b. Scope of the system

c. Objectives and Success Criteria of the Project

d. Definitions, acronyms and abbreviations

2. Current System

3. Proposed System

a. Overview

b. Functional Requirements

c. Non Functional Requirements

i. Usability

ii. Reliability

iii. Performance

iv. Supportability

v. Implementation

vi. Interface

vii. Packaging

viii. Legal

d. System Models

i. Scenarios

ii. Use Case Model

iii. Object Model

iv. Dynamic Model

v. User interface – Navigational Paths and Screen Mockups

4. Glossary

System Design Document

1. Introduction

a. Purpose of the System

b. Design Goals

c. Definitions, acronyms and abbreviations

d. References

e. Overview

2. Current Software Architecture

3. Proposed Software Architecture

a. Overview

b. Subsystem Decomposition

c. Hardware / Software mapping

d. Persistent Data management

e. Access Control and Security

f. Global Software Control

g. Boundary Conditions

4. Subsystem Services

5. Glossary

Implementation Screens

Testing

Conclusion

Bibliography

ABSTRACT

ABSTRCT

In this paper, we present a complete framework and findings in mining Web

usage patterns from Web log files of a real Web site that has all the challenging aspects

of real-life Web usage mining, including evolving user profiles and external data

describing an ontology of the Web content. Even though the Web site under study is part

of a nonprofit organization that does not “sell” any products, it was crucial to understand

“who” the users were, “what” they looked at, and “how their interests changed with

time,” all of which are important questions in Customer Relationship Management

(CRM). Hence, we present an approach for discovering and tracking evolving user

profiles. We also describe how the discovered user profiles can be enriched with explicit

information need that is inferred from search queries extracted from Web log data.

Profiles are also enriched with other domain-specific information facets that give a

panoramic view of the discovered mass usage modes. An objective validation strategy is

also used to assess the quality of the mined profiles, in particular their adaptability in the

face of evolving user behavior

INTRODUCTION

INTRODUCTION

CUSTOMER Relationship Management (CRM) can use data from within and

outside an organization to allow an understanding of its customers on an individual basis

or on a group basis such as by forming customer profiles. An improved understanding of

the customer’s habits, needs, and interests can allow the business to profit by, for

instance, “cross selling” or selling items related to the ones that the customer wants to

purchase. Hence, reliable knowledge about the customers’ preferences and needs forms

the basis for effective CRM. As businesses move online, the competition between

businesses to keep the loyalty of their old customers and to lure new customers is even

more important, since a competitor’s Web site may be only one click away. The fast pace

and large amounts of data available in these online settings have recently made it

imperative to use automated data mining or knowledge discovery techniques to discover

Web user profiles. These different modes of usage or the so-called mass user profiles can

be discovered using Web usage mining techniques that can automatically extract frequent

access patterns from the history of previous user clickstreams stored in Web log files.

These profiles can later be harnessed toward personalizing the Web site to the user or to

support targeted marketing. Although there have been considerable advances in Web

usage mining, there have been no detailed studies presenting a fully integrated approach

to mine a real Web site with the challenging characteristics of today’s Web sites, such as

evolving profiles, dynamic content, and the availability of taxonomy or databases in

addition to Web logs. In this paper, we present a complete framework and a summary of

our experience in mining Web usage patterns with real-world challenges such as evolving

access patterns, dynamic pages, and external data describing an ontology of the Web

content and how it relates to the business actors (in the case of the studied Web site, the

companies, contractors, consultants, etc., in corrosion). The Web site in this study is a

portal that provides access to news, events, resources, company information (such as

companies or contractors supplying related products and services), and a library of

technical and regulatory documentation related to corrosion and surface treatment. The

portal also offers a virtual meeting place between companies or organizations seeking

information about other companies or organizations. Without loss of generality, in the

rest of this paper, we will refer to all the Web site participants (organizations, contractors,

consultants, agencies, corporations, centers, agencies, etc.) simply as companies. The

Web site in our study is managed by a nonprofit organization that does not sell anything

but only provides free information that is ideally complete, accurate, and up to date.

Hence, it was crucial to understand the different modes of usage and to know what kind

of information the visitors seek and read on the Web site and how this information

evolves with time. For this reason, we perform clustering of the user sessions extracted

from the Web logs to partition the users into several homogeneous groups with similar

activities and then extract user profiles from each cluster as a set of relevant URLs. This

procedure is repeated in subsequent new periods of Web logging (such as biweekly), then

the previously discovered user profiles are tracked, and their evolution pattern is

categorized. When clustering the user sessions, we exploit the Web site hierarchy to give

partial weights in the session similarity between URLs that are distinct and yet located

closer together on this hierarchy. The Web site hierarchy is inferred both from the URL

address and from a Web site database that organizes most of the dynamic URLs along an

“is-a” ontology of items. We also enrich the cluster profiles with various facets, including

search queries submitted just before landing on the Web site, and inquiring and inquired

companies, in case users from (inquiring) companies inquire about any of the (inquired)

companies listed on the Web site, which provide related services. The rest of this paper is

organized as follows: In Section 2, we present an overview of Web usage mining, in

particular advances involving semantics and profile evolution. In Section 3, we describe

our approach to profile discovery using Web usage mining. In Section 4, we discuss our

approach for handling dynamic content and exploiting external data that describes an

ontology of the Web content derived from the server database. In Section 5, we discuss

our approach for tracking evolving user profiles. In Section 6, we present a systematic

and objective validation strategy for the discovered user profiles. In Section 7, we present

our results in mining evolving user profiles. Finally, in Section 8, we present our

conclusions.

OBJECT ORIENTED ANALYSIS AND

DESIGN

OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD)

Object-oriented analysis and design (OAD) is often part of the development of large scale

systems and programs often using the Unified Modeling Language (UML). OAD applies

object-modeling techniques to analyze the requirements for a context — for example, a

system, a set of system modules, an organization, or a business unit — and to design a

solution. Most modern object-oriented analysis and design methodologies are use case

driven across requirements, design, implementation, testing, and deployment. Use cases

were invented with object oriented programming, but they're also very well suited for

systems that will be implemented in the procedural paradigm. The Unified Modeling

Language (UML) has become the standard modeling language used in object-oriented

analysis and design to graphically illustrate system concepts. Part of the reason for OAD

is its use in developing programs that will have an extended lifetime.

Object Oriented Systems

An object-oriented system is composed of objects. The behavior of the system is

achieved through collaboration between these objects, and the state of the system is the

combined state of all the objects in it. Collaboration between objects involves them

sending messages to each other. The exact semantics of message sending between objects

varies depending on what kind of system is being modeled. In some systems, "sending a

message" is the same as "invoking a method". In other systems, "sending a message"

might involve sending data via a socket.

Object Oriented Analysis

Object-Oriented Analysis (OOA) aims to model the problem domain, the problem we

want to solve by developing an object-oriented (OO) system. The source of the analysis

is a written requirement statements, and/or written use cases, UML diagrams can be used

to illustrate the statements. An analysis model will not take into account implementation

constraints, such as concurrency, distribution, persistence, or inheritance, nor how the

system will be built. The model of a system can be divided into multiple domains each of

which are separately analysed, and represent separate business, technological, or

conceptual areas of interest. The result of object-oriented analysis is a description of what

is to be built, using concepts and relationships between concepts, often expressed as a

conceptual model. Any other documentation that is needed to describe what is to be built,

is also included in the result of the analysis. That can include a detailed user interface

mock-up document. The implementation constraints are decided during the object-

oriented design (OOD) process.

Object Oriented Design

Object-Oriented Design (OOD) is an activity where the designers are looking for logical

solutions to solve a problem, using objects. Object-oriented design takes the conceptual

model that is the result of object-oriented analysis, and adds implementation constraints

imposed by the environment, the programming language and the chosen tools, as well as

architectural assumptions chosen as basis of design. The concepts in the conceptual

model are mapped to concrete classes, to abstract interfaces in APIs and to roles that the

objects take in various situations. The interfaces and their implementations for stable

concepts can be made available as reusable services. Concepts identified as unstable in

object-oriented analysis will form basis for policy classes that make decisions, implement

environment-specific or situation specific logic or algorithms. The result of the object-

oriented design is a detail description how the system can be built, using objects. Object-

oriented software engineering (OOSE) is an object modeling language and methodology

OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first

object-oriented design methodology to employ use cases to drive software design. It also

uses other design products similar to those used by OMT. The tool Objectory was created

by the team at Objectory AB to implement the OOSE methodology. After success in the

marketplace, other tool vendors also supported OOSE. After Rational bought Objectory

AB, the OOSE notation, methodology, and tools became superseded.

As one of the primary sources of the Unified Modeling Language (UML),

concepts and notation from OOSE have been incorporated into UML.

• The methodology part of OOSE has since evolved into the Rational Unified

Process (RUP).

• The OOSE tools have been replaced by tools supporting UML and RUP.

OOSE has been largely replaced by the UML notation and by the RUP methodology.

- Reference www.wikipedia.org

http://www.wikipedia.org/

SOFTWARE PROFILE

About Java

Initially the language was called as “oak” but it was renamed as “Java” in 1995. The

primary motivation of this language was the need for a platform-independent (i.e.,

architecture neutral) language that could be used to create software to be embedded in

various consumer electronic devices.

Java is a programmer’s language.

Java is cohesive and consistent.

Except for those constraints imposed by the Internet environment, Java gives

the programmer, full control.

Finally, Java is to Internet programming where C was to system

programming.

Importance of Java to the Internet

Java has had a profound effect on the Internet. This is because; Java expands the

Universe of objects that can move about freely in Cyberspace. In a network, two

categories of objects are transmitted between the Server and the Personal computer. They

are: Passive information and Dynamic active programs. The Dynamic, Self-executing

programs cause serious problems in the areas of Security and probability. But, Java

addresses those concerns and by doing so, has opened the door to an exciting new form

of program called the Applet.

Java can be used to create two types of programs

Applications and Applets : An application is a program that runs on our Computer

under the operating system of that computer. It is more or less like one creating using C

or C++. Java’s ability to create Applets makes it important. An Applet is an application

designed to be transmitted over the Internet and executed by a Java –compatible web

browser. An applet is actually a tiny Java program, dynamically downloaded across the

network, just like an image. But the difference is, it is an intelligent program, not just a

media file. It can react to the user input and dynamically change.

Features Of Java Security

Every time you that you download a “normal” program, you are risking a viral infection.

Prior to Java, most users did not download executable programs frequently, and those

who did scanned them for viruses prior to execution. Most users still worried about the

possibility of infecting their systems with a virus. In addition, another type of malicious

program exists that must be guarded against. This type of program can gather private

information, such as credit card numbers, bank account balances, and passwords. Java

answers both these concerns by providing a “firewall” between a network application

and your computer.

When you use a Java-compatible Web browser, you can safely download Java applets

without fear of virus infection or malicious intent.

Portability

For programs to be dynamically downloaded to all the various types of platforms

connected to the Internet, some means of generating portable executable code is

needed .As you will see, the same mechanism that helps ensure security also helps create

portability. Indeed, Java’s solution to these two problems is both elegant and efficient.

The Byte code

The key that allows the Java to solve the security and portability problems is that the

output of Java compiler is Byte code. Byte code is a highly optimized set of instructions

designed to be executed by the Java run-time system, which is called the Java Virtual

Machine (JVM). That is, in its standard form, the JVM is an interpreter for byte code.

Translating a Java program into byte code helps makes it much easier to run a program in

a wide variety of environments. The reason is, once the run-time package exists for a

given system, any Java program can run on it.

Although Java was designed for interpretation, there is technically nothing about Java

that prevents on-the-fly compilation of byte code into native code. Sun has just completed

its Just In Time (JIT) compiler for byte code. When the JIT compiler is a part of JVM, it

compiles byte code into executable code in real time, on a piece-by-piece, demand basis.

It is not possible to compile an entire Java program into executable code all at once,

because Java performs various run-time checks that can be done only at run time. The JIT

compiles code, as it is needed, during execution.

Java Virtual Machine (JVM)

Beyond the language, there is the Java virtual machine. The Java virtual machine is an

important element of the Java technology. The virtual machine can be embedded within a

web browser or an operating system. Once a piece of Java code is loaded onto a machine,

it is verified. As part of the loading process, a class loader is invoked and does byte code

verification makes sure that the code that’s has been generated by the compiler will not

corrupt the machine that it’s loaded on. Byte code verification takes place at the end of

the compilation process to make sure that is all accurate and correct. So byte code

verification is integral to the compiling and executing of Java code.

Overall Description

Picture showing the development process of JAVA Program

Java programming uses to produce byte codes and executes them. The first box indicates

that the Java source code is located in a. Java file that is processed with a Java compiler

called javac. The Java compiler produces a file called a. class file, which contains the

byte code. The. Class file is then loaded across the network or loaded locally on your

Java Source

Java byte code

JavaVMJava .Class

machine into the execution environment is the Java virtual machine, which interprets and

executes the byte code.

Java Architecture

Java architecture provides a portable, robust, high performing environment for

development. Java provides portability by compiling the byte codes for the Java Virtual

Machine, which is then interpreted on each platform by the run-time environment. Java is

a dynamic system, able to load code when needed from a machine in the same room or

across the planet.

Compilation of code

When you compile the code, the Java compiler creates machine code (called byte code)

for a hypothetical machine called Java Virtual Machine (JVM). The JVM is supposed to

execute the byte code. The JVM is created for overcoming the issue of portability. The

code is written and compiled for one machine and interpreted on all machines. This

machine is called Java Virtual Machine.

Compiling and interpreting Java Source Code

During run-time the Java interpreter tricks the byte code file into thinking that it is

running on a Java Virtual Machine. In reality this could be a Intel Pentium Windows 95

or SunSARC station running Solaris or Apple Macintosh running system and all could

receive code from any computer through Internet and run the Applets.

Simple

Java was designed to be easy for the Professional programmer to learn and to use

effectively. If you are an experienced C++ programmer, learning Java will be even easier.

Because Java inherits the C/C++ syntax and many of the object oriented features of C++.

Most of the confusing concepts from C++ are either left out of Java or implemented in a

cleaner, more approachable manner. In Java there are a small number of clearly defined

ways to accomplish a given task.

Source Code………..………..

………..

…………

PC Compiler

MacintoshCompiler

SPARC

Compiler

Java

Byte code

(PlatformIndependent)

JavaInterpreter(PC)

JavaInterpreter(Macintosh)

JavaInterpreter(Spare)

Object-Oriented

Java was not designed to be source-code compatible with any other language. This

allowed the Java team the freedom to design with a blank slate. One outcome of this was

a clean usable, pragmatic approach to objects. The object model in Java is simple and

easy to extend, while simple types, such as integers, are kept as high-performance non-

objects.

Robust

The multi-platform environment of the Web places extraordinary demands on a program,

because the program must execute reliably in a variety of systems. The ability to create

robust programs was given a high priority in the design of Java. Java is strictly typed

language; it checks your code at compile time and run time.

Java virtually eliminates the problems of memory management and deallocation, which is

completely automatic. In a well-written Java program, all run time errors can –and should

–be managed by your program.

- Reference java.sun.com

REQUIREMENT ANALYSIS

DOCUMENT

INTRODUCTION

1.1 PURPOSE OF THE SYSTEM

To develop a framework for web usage patterns from web log files of real web site

that has challenge aspects of real life web usage mining.

1.2 OBJECTIVES AND SUCCESS CRITERIA OF THE PROJECT

To develop a sample web site which is dependent on the evolving user

profiles?

To handle the profile evolution.

To integrate semantics in web usage mining.

To discover profiles based on web usage mining.

To implement H-UNC preprocessing algorithm on web log file to extract user

profiles.

To calculate similarity measures.

Tracking evolving user profiles.

2. CURRENT SYSTEM

The current system that can track user profiles is based on the general queries,

Each is based on normal SQL Queries. Answering the complex queries for a DBMS

system is very complex. These queries will consume too much system resources. The

system will be slower if the queries are answered in this manner.

3. PROPOSED SYSTEM

By implementing the data mining techniques like preprocessing, post processing,

clustering and Genetic algorithm in the proposed system to solve this type of complex

problems will result in less usage of computer power and more utility from the resources.

Requirements Model

custom Requirements Mo...EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version































The Requirements model is a structured catalogue of end-user requirements. These are represented as either Requirement or Feature elements.

The model is divided into two sub-catalogues:

1. The Functional requirements package contains requirements and features that represent functional behavior and features that the system under development must support.

2. The Non-functional requirements package contains constraints and performance levels the system must meet. For example response times, transactions per second, security strength.

Read about Requirements

Functional Requirements

+ Business Rules

+ Features

Non-Functional Requirements

+ Performance

+ Persistence

Tracing element dependencies

Using the Relationship Matrix

The Functional Requirements package details behavioral requirements that specify how a proposed system will process and handle information. It details the features and rules that must be present to fully implement the functionality desired.

The Non-Functional Requirements package specifiesthe various operational parameters that define the environment in which the system will exist. These are criteria which define performance levels, scalability, security requirements, backup, disaster recovery and other operational requirements.

Figure: Requirements Model

<anonymous>

Status: ProposedPhase: 1.0 Version: 1.0

Functional Requirements

custom Functional Requirements

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version





























Functional Requirements describe the features, behavior, business rules and general functionality that the proposed system must support.

Features

+ F01

Business Rules

+ R01

+ R02

+ R03

+ R04

Figure: Functional Requirements

Note


Business Rules

custom Business Logic






























The Business Rules package is a catalogue of explicit business rules which are required to be implemented within the current project. Business Rules are typically executed during program execution and control the processing of information and transactions.

R01

R02

R03

R04

Figure: Business Logic

R01

«Function Status: Proposed Priority: Medium Difficulty: Medium

Phase: 1.0 Version: 1.0

R02

«Functional»

Status: Proposed Priority: Medium Difficulty: MediumPhase: 1.0 Version: 1.0

R03

«Functional»


R04

«Functional»


Features

custom Features

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version


























Features typically describe discrete pieces of functional behavior that yield a specific result.

F01

Figure: Features

F01

«Functional»


Non-Functional Requirements

custom Non-Functional RequirementsEA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version




































Performance

Persistence

These packages contain non-functional requirements specified for the new system. These typically describe performance criteria, reliabil ity, security and other operational parameters.

The Persistence package details operational and performance criteria relating to the storage of information, including where relevant, redundancy, back-up, database system, fi les and other persistent storage mechanisms.

Performance requirements define parameters such as transactions per second, network latency, form load timesand other measurable aspects of the system that govern overall speed and responsiveness.

Figure: Non-Functional Requirements

<anonymous>


Performance

custom Performance

EA 7.1 Unregistered Trial Version

























PR01

Figure: Performance

PR01

«Functional»


Persistence

custom Persistence


























Persist01

Figure: Persistence

Persist01

«Functional»


3.4 SYSTEM MODELS

1Introduction

This document can be modified to reflect the company logo as well as the general corporate layout. To create an editable copy of this template: - Press F8. - Press the option: [Manage Templates] . - From this select: [New]In the Dialog box:- In the field: Template Name – type in a name.- From the Copy Template drop-down – select:{use case template}.Below are some simple introductory remarks on the purpose of the document.

1.1 Purpose of Document

The Purpose of this Document is to define the Use Case for …

This is to be a standard paragraph to layout that the Business Logic and the elements within the package which are laying out the Use Cases for the package under

development. This text is definable as a template by the user and stored locally. The system variables are filled in by EA via the RTF Document Generator.

1.2 Glossary

.Group Term DefinitionBusiness Accounting Periods A defined period of time whereby

performance reports may be extracted. (normally 4 week periods).

Technical Association A relationship between two or more entities. Implies a connection of some type - for example one entity uses the services of another, or one entity is connected to anotherover a network link.

Technical Class A logical entity encapsulating data and behavior. A class is a template for an object -the class is the design, the object the runtime instance.

Technical Component Model The component model provides a detailed view of the various hardware and software components that make up the proposed system. It shows both where these components reside and how they inter-relate with other components. Component requirements detail what responsibilities a component has to supply functionality or behavior within the system.

Business Customer A person or a company that requests An entity to transport goods on their behalf.

Technical Deployment Architecture A view of the proposed hardware that will make up the new system, together with the physical components that will execute on that hardware. Includes specifications for machine, operating system, network links, backup units &etc.

Technical Deployment Model A model of the system as it will be physically deployed

Technical Extends Relationship A relationship between two use cases in which one use case 'extends' the behavior of another. Typically this represents optional behavior in a use case scenario - for example a user may optionally request a list or report at some point in a performing a business use case.

Technical Includes Relationship A relationship between two use cases in which one use case 'includes' the behavior. This is indicated where there a specific business use cases which are used from manyother places - for example updating a train record may be part of many larger business processes.

Technical Use Case A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example creating a train, modifying a train and creating orders are all Use Cases.Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behavior.Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.

2Application Overview

Some text on the application Overview…

2.1 Define the Scope

Definition of the Scope of the application …

2.2 Context

This is to give a brief definition of the context in which of the application will be implemented. Specifying the relationship this system will have to existing systems within the environment.

2.3 Technical Environment

This is to give a brief definition of any applications relevant to the system being implemented. There needs to be a definition of the relationship between these as well as any aspects that this system is reliant upon.

Use Cases

3 Use Case Model

uc Use Case Mo...EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version



































The Use Case model is a catalogue of system functionality described using UML Use Cases. Each UseCase represents a single, repeatable interaction that a user or "actor" experiences when using the system.

A Use Case typically includes one or more "scenarios" which describe the interactions that go on between the Actor and the System, and documents the results and exceptions that occur from the user's perspective.

Use Cases may include other Use Cases as part of a larger pattern of interaction and may also be extended by other use cases to handle exceptional conditions

Actors

+ Admin

+ Customer

+ Clicks on login button

+ Clicks on serch buttion

+ Enters search key

+ Enters Username and password

+ Logs Into System

+ Searches products

+ Views the Evolving User Profiles

Primary Use Cases

+ Logs Into system

+ Purchases products

+ Registers to the system

+ Searches for Products

+ Views Evolving User profiles

Read about Actors

Read about Use Case Modeling

View Further Examples

Actors are the users of the system being modeled. Each Actor will have a well-defined role, and in the context of that role have useful interactions with the system.

A person may perform the role of more than one Actor, although they will only assume one role during one use case interaction.

An Actor role may be performed by a non-human system, such as another computer program.

This package contains use cases which define how an Actor will interact with the proposed system.

Each interaction may be specified using scenarios, sequence diagrams, communication diagrams and other dynamic diagrams or textual descriptions which together how the system when viewed as a "black-box" interacts with a user.

Figure 1: Use Case Model

3.1 <anonymous>

A person may perform the role of more than one Actor, although they will only assume one role during one use case interaction.

An Actor role may be performed by a non-human system, such as another computer program.

3.2 Actors

uc ActorsEA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version



































Customer

Logs Into System

Enters Username and password

Clicks on login button

Searches products

Enters search keyClicks on serch

buttion

Admin

Views the Ev olv ing User Profiles

«include»

«include»

«extend»

«include»«include»

Figure 2: Actors

3.2.1 Admin

3.2.2 Customer

3.2.3 Enters Username and password

3.2.4 Enters search key

3.2.5 Logs Into System

3.2.6 Searches products

3.2.7 Views the Evolving User Profiles

3.3 Primary Use Cases

uc Primary Use CasesEA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version




































A Web usage mining framework for mining evolvinguser profiles in dynamic web sites

Registers to the system

Customer

The System Boundary shows the logical interface between users and the system being described.

Purchases products

Logs Into system

Searches for Products

Admin

Views Ev olv ing User profiles

Figure 3: Primary Use Cases

3.3.1 Logs Into system

3.3.2 Purchases products

3.3.3 Registers to the system

3.3.4 Searches for Products

3.3.5 Views Evolving User profiles

3.4.5 OBJECT MODEL

Model Detail

This document provides a complete overview of all element details. For simpler and more focused reports, simply copy this initial template and turn off the sections not required.

Class Model

Status: Proposed. Version . Phase 1.0.Package: ModelDetail: Created on 08-11-2008. Last modified on 08-11-2008GUID: {155AD330-1B9D-433c-A7B9-3F5C9916CCB8}

Class Model – (Logical diagram) Created By: Ashok on 19-11-2005Last Modified:08-11-2008Version: 1.0. Locked: FalseGUID: {F5CA008F-8D1F-4c6a-A4BF-8588AD0ADCC2}

class Class ModelEA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version






























The Class Model is a logical model of the software system under construction. Classes generally have a direct relationship to source code or other software artifacts that can be grouped together into executable components.

The System package contains the classes and artifacts which are being built or designed as part of the current model. The Frameworks package generally contains classes and components that have been designed and built earlier and are being reused as part of the current project.


Read about Class Modeling

Figure: 1

Note

Type: Note Status: Proposed. Version 1.0. Phase 1.0.Package: Class Model Keywords: Detail: Created on 20-11-2005. Last modified on 05-01-2006.GUID: {BC6C063F-0F84-4c26-83C3-2455567EAA8A}

The System package contains the classes and artifacts which are being built or designed as part of the current model. The Frameworks package generally contains classes and components that have been designed and built earlier and are being reused as part of the current project.

com

Status: Proposed. Version 1.0. Phase 1.0.Package: Class ModelDetail: Created on 08-11-2008. Last modified on 08-11-2008GUID: {5342F142-0513-40e9-AE3D-DDD51AE4722B}

profileeval

Status: Proposed. Version 1.0. Phase 1.0.Package: comDetail: Created on 08-11-2008. Last modified on 08-11-2008GUID: {BCEFB69C-8ED0-4f7a-8D6C-B46B649E8C1A}

beans

Status: Proposed. Version 1.0. Phase 1.0.Package: profileevalDetail: Created on 08-11-2008. Last modified on 08-11-2008GUID: {D41A0A13-32EF-47e6-9154-C149F3EAFF8A}

beans – (Logical diagram) Created By: Ashok on 08-11-2008Last Modified:08-11-2008Version: 1.0. Locked: FalseGUID: {78775260-6C5D-4b6b-99B9-201638ABFB89}

clas s beansEA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version






































Products

- category: String- description: String- name: String

+ getCategory() : String+ getDescription() : String+ getName() : String+ Products()+ Products(String)+ setCategory(String) : void+ setDescription(String) : void+ setName(String) : void

Users

- address: String- city: String- dateofbirth: Date- education: String- entertainment: String- firstname: String- lastname: String- middlename: String- password: String- pin: Integer- role: String- sports: String- userid: String

+ getAddress() : String+ getCity() : String+ getDateofbirth() : Date+ getEducation() : String+ getEntertainment() : String+ getFirstname() : String+ getLastname() : String+ getMiddlename() : String+ getPassword() : String+ getPin() : Integer+ getRole() : String+ getSports() : String+ getUserid() : String+ setAddress(String) : void+ setCity(String) : void+ setDateofbirth(Date) : void+ setEducation(String) : void+ setEntertainment(String) : void+ setFirstname(String) : void+ setLastname(String) : void+ setMiddlename(String) : void+ setPassword(String) : void+ setPin(Integer) : void+ setRole(String) : void+ setSports(String) : void+ setUserid(String) : void+ Users()

Figure: 2

Products

Type: Class Status: Proposed. Version 1.0. Phase 1.0.Package: beans Keywords: Detail: Created on 08-11-2008. Last modified on 08-11-2008.GUID: {E985C982-3D79-4ef1-AAE9-3A754615E9A9}

Custom Properties isActive = False

AttributesAttribute Notes Constraints and tags category StringPrivate

description StringPrivate

name StringPrivate

OperationsMethod Notes ParametersgetCategory() StringPublicgetDescription() StringPublicgetName() StringPublicProducts() PublicProducts() Public

String [in] name

setCategory() voidPublic

String [in] category

setDescription() voidPublic

String [in] description

Method Notes ParameterssetName() voidPublic

String [in] name

Users

Type: Class Status: Proposed. Version 1.0. Phase 1.0.Package: beans Keywords: Detail: Created on 08-11-2008. Last modified on 08-11-2008.GUID: {7563E228-B554-4710-BC29-2BD3FC24190B}


ConnectionsConnector Source Target NotesAssociation Source -> Destination

Public UsersDAO

Package user Users

AttributesAttribute Notes Constraints and tags address StringPrivate

city StringPrivate

Attribute Notes Constraints and tags dateofbirth DatePrivate

education StringPrivate

entertainment StringPrivate

firstname StringPrivate

lastname StringPrivate

middlename StringPrivate

Attribute Notes Constraints and tags password StringPrivate

pin IntegerPrivate

role StringPrivate

sports StringPrivate

userid StringPrivate

OperationsMethod Notes ParametersgetAddress() StringPublicgetCity() StringPublicgetDateofbirth() DatePublicgetEducation() String

Method Notes ParametersPublicgetEntertainment() StringPublicgetFirstname() StringPublicgetLastname() StringPublicgetMiddlename() StringPublicgetPassword() StringPublicgetPin() IntegerPublicgetRole() StringPublicgetSports() StringPublicgetUserid() StringPublicsetAddress() voidPublic

String [in] address

setCity() voidPublic

String [in] city

setDateofbirth() voidPublic

Date [in] dateofbirth

setEducation() voidPublic

String [in] education

setEntertainment() voidPublic

String [in] entertainment

setFirstname() voidPublic

String [in] firstname

setLastname() voidPublic

String [in] lastname

setMiddlename() voidPublic

String [in] middlename

setPassword() voidPublic

String [in] password

setPin() voidPublic

Integer [in] pin

setRole() voidPublic

String [in] role

setSports() void String [in] sports

Method Notes ParametersPublicsetUserid() voidPublic

String [in] userid

Users() Public

core

Status: Proposed. Version 1.0. Phase 1.0.Package: profileevalDetail: Created on 08-11-2008. Last modified on 08-11-2008GUID: {D29DFC31-E532-4511-A94D-D884705A20A3}

core – (Logical diagram) Created By: Ashok on 08-11-2008Last Modified:08-11-2008Version: 1.0. Locked: FalseGUID: {C1A3724B-BAB5-4a18-B075-26EC18C1CBCF}

clas s coreEA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version


























Hunc

+ Hunc()

TrackProfile Unc

Figure: 3

Hunc

Type: Class Status: Proposed. Version 1.0. Phase 1.0.Package: core Keywords: Detail: Created on 08-11-2008. Last modified on 08-11-2008.GUID: {B61E2CB0-922E-4d2a-A452-440B83EBBFE6}


OperationsMethod Notes ParametersHunc() Public

TrackProfile

Type: Class Status: Proposed. Version 1.0. Phase 1.0.Package: core Keywords: Detail: Created on 08-11-2008. Last modified on 08-11-2008.GUID: {9727790C-8359-415d-9E5E-61F092AAAE99}


Unc

Type: Class Status: Proposed. Version 1.0. Phase 1.0.Package: core Keywords: Detail: Created on 08-11-2008. Last modified on 08-11-2008.GUID: {E39CEDE4-C39F-4815-A447-B4389F59CED7}


dao

Status: Proposed. Version 1.0. Phase 1.0.Package: profileevalDetail: Created on 08-11-2008. Last modified on 08-11-2008GUID: {0740BAA1-4C29-44c6-92B0-16A8822142AE}

dao – (Logical diagram)

Created By: Ashok on 08-11-2008Last Modified:08-11-2008Version: 1.0. Locked: FalseGUID: {1B01956F-8316-4994-8D6C-FE1AFE2BDA7F}clas s daoEA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version




























CommonDao

+ CommonDao()+ getConnection() : Connection

ProductsDAO

+ getAllProducts() : ArrayList<Products>+ getList(String) : ArrayList<Products>+ getList(String, String) : ArrayList<Products>+ getProduct(String) : Products+ ProductsDAO()

UsersDAO

~ rs: ResultSet~ sql: String~ user: Users

+ getAllUserNames() : ArrayList<Users>+ getRole(String, String) : String+ load(String) : Users+ store(Users) : void+ UserDAO() : void

Figure: 4

CommonDao

Type: Class Status: Proposed. Version 1.0. Phase 1.0.Package: dao Keywords: Detail: Created on 08-11-2008. Last modified on 08-11-2008.GUID: {EF17E4BD-115C-4431-AD20-E539776ADC5C}


OperationsMethod Notes ParametersCommonDao() PublicStatic getConnection() ConnectionPublic

ProductsDAO

Type: Class Status: Proposed. Version 1.0. Phase 1.0.Package: dao Keywords: Detail: Created on 08-11-2008. Last modified on 08-11-2008.

GUID: {06E20979-6657-462c-91C7-10BFAEF9E6EE}


OperationsMethod Notes ParametersgetAllProducts() ArrayList<Products>PublicgetList() ArrayList<Products>Public

String [in] key

getList() ArrayList<Products>Public

String [in] key String [in] user

getProduct() ProductsPublic

String [in] name

ProductsDAO() Public

UsersDAO

Type: Class Status: Proposed. Version 1.0. Phase 1.0.Package: dao Keywords: Detail: Created on 08-11-2008. Last modified on 08-11-2008.GUID: {8E016BA0-0026-4033-9DCF-4D8995EAC2EC}


ConnectionsConnector Source Target NotesAssociation Source -> Destination

Public UsersDAO

Package user Users

AttributesAttribute Notes Constraints and tags rs ResultSetPackage

sql StringPackage

user UsersPackage

OperationsMethod Notes ParametersgetAllUserNames() ArrayList<Users>PublicgetRole() StringPublic

String [in] userid String [in] password

load() UsersPublic

String [in] key

store() voidPublic

Users [in] u

UserDAO() voidPublic

3.4.6 USER INTERFACE – NAVIGATIONAL PATHS AND SCREEN MOCKUPS.

SYSTEM DESIGN DOCUMENT

6. INTRODUCTION

1.1. PURPOSE OF THE SYSTEM

To develop a web usage mining framework for mining evolving profiles in

dynamic web sites.

2. CURRENT SOFTWARE ARCHITECTURE

The current software architectures is based on the Three tier framework. The three

tier framework consists for Three layers namely 1. User interface layer, 2. Business

logic Layer and 3. Database access layer.

The user interface layer consists of code for developing the user interface

components since there are the web sites the typical user interface tier is mostly

written in HTML and Java Script.

The Business logic layer consists of code written for the all the logic typically

written using java programming language. This includes the core implementations of

worker beans.

The Data access layer consists of the code to communicate with the database

management system. It implements all the DAO’s (Data Access Objects) and DTO’s

(Data Transfer Objects).

3. PROPOSED SOFTWARE ARCHITECTURE

The proposed architecture adds one more component into the system for

answering the queries. The component will enable the addition of data mining

technique to be implemented on the web log data.

3.2 SUBSYSTEM DECOMPOSITION

The entire system is decomposed into three sub systems. The subsystems are Application

subsystem, Web logging subsystem and Profile Tracking subsystem.

Application Subsystem: In this subsystem all the details of the application domain are

fulfilled. The each domain is based on the application subsystem only.

Web logging: This subsystem will log each and every user event. These events are stored

in the web logging database. The database consists of the user details, to which url the

user is worked on, and the nature of the work the user done.

Profile tracking: This subsystem will implement all the three algorithms that are proposed

by the paper. This will result in mining the web log data and giving out the user profiles.

The view of data cube can be gathered here.

7. HARDWARE AND SOFTWARE MAPPING

The major software requirements of the project are as follows.

Language : Java (JDK1.5.0_06)

Operating System : Microsoft Windows Xp Service Pack 2

IDE : My Eclipse 6.0

Server : Apache Tomcat 6.0

The Hardware requireements that map towards the software are as follows

Processor : Intel Pentium 4

RAM : 256 MB

Hard Disk : 40 GB

8. PERSISTANT DATA MANAGEMENT

For this project the persistent database management can be done using the oracle

11g Enterprise database. The database management techniques used to design the

database.

Data Model Detail

This document provides an overview of the data model. For simpler and more focused reports, simply copy this initial template and turn off the sections not required.

Data Model

Package: ModelDetail: Created on 11/17/2008. Last modified on 11/17/2008.

Data ModelCreated By: ASHOK on 11/22/2005Last Modified:1/11/2006, Version:1.0class Data ModelEA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version































This model describes the data which must be stored and retrieved as part of the overall system design.

Typically this will mean relational database models which describe the tables and data in detail and allow generation of DDL scripts to create and setup databases.

Read about Data Modeling


How to import an existing schema

How to generate DDL scripts

Schema1

+ Products

+ users

+ weblog

A schema package contains a logical grouping of tables

Figure: 1

<anonymous>

Database: <none>, Stereotype: , Package: Data ModelDetail: Created on 1/5/2006. Last modified on 1/7/2006.

Relationships

Columns Association Notes Schema1. <anonymous>.

Schema1

Package: Data ModelDetail: Created on 1/5/2006. Last modified on 1/5/2006.

Schema1Created By: ASHOK on 1/11/2006Last Modified:11/17/2008, Version:1.0

clas s Schem a1EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version


































Products

«column»*PK name category

«PK»+ PK_Products()

users

«column»*PK userid password firstname middlename lastname dateofbirth address city sports entertainment role

«PK»+ PK_users()

weblog

«column»*PK sno userid event_type product_name description url

«PK»+ PK_weblog()

«table» Products

«flow»

«table» users

«flow»

Figure: 2

Products

Database: , Stereotype: «table», Package: Schema1Detail: Created on 11/22/2005. Last modified on 11/17/2008.

ColumnsPK Name Type Not

NullUnique

Len Prec

Scale

Init Notes

True name True FalseFalse category False False

ConstraintsName Type Columns Initial Code NotesPK_Products Public name

RelationshipsColumns Association Notes

Products. weblog.

users



NullUnique

Len Prec

Scale

Init Notes

True userid True FalseFalse password False FalseFalse firstname False FalseFalse middlename False FalseFalse lastname False FalseFalse dateofbirth False FalseFalse address False FalseFalse city False FalseFalse sports False FalseFalse entertainment False FalseFalse role False False

ConstraintsName Type Columns Initial Code NotesPK_users Public userid

Relationships

Columns Association Notes users. weblog.

weblog



NullUnique

Len Prec

Scale

Init Notes

True sno True FalseFalse userid False FalseFalse event_type False FalseFalse product_name False FalseFalse description False FalseFalse url False False

ConstraintsName Type Columns Initial Code NotesPK_weblog Public sno

RelationshipsColumns Association Notes

users. weblog. Products. weblog.

IMPLEMENTATION SCREENS

TESTING

Software Testing is the process used to help identify the correctness,

completeness, security, and quality of developed computer software. Testing is a process

of technical investigation, performed on behalf of stakeholders, that is intended to reveal

quality-related information about the product with respect to the context in which it is

intended to operate. This includes, but is not limited to, the process of executing a

program or application with the intent of finding errors. Quality is not an absolute; it is

value to some person. With that in mind, testing can never completely establish the

correctness of arbitrary computer software; testing furnishes a criticism or comparison

that compares the state and behaviour of the product against a specification. An important

point is that software testing should be distinguished from the separate discipline of

Software Quality Assurance (SQA), which encompasses all business process areas, not

just testing.

There are many approaches to software testing, but effective testing of complex products

is essentially a process of investigation, not merely a matter of creating and following

routine procedure. One definition of testing is “the process of questioning a product in

order to evaluate it”, where the “questions” are operations the tester attempts to execute

with the product, and the product answers with its behavior in reaction to the probing of

the tester[citation needed]. Although most of the intellectual processes of testing are

nearly identical to that of review or inspection, the word testing is connoted to mean the

dynamic analysis of the product—putting the product through its paces. Some of the

common quality attributes include capability, reliability, efficiency, portability,

maintainability, compatibility and usability. A good test is sometimes described as one

which reveals an error; however, more recent thinking suggests that a good test is one

which reveals information of interest to someone who matters within the project

community.

Introduction

In general, software engineers distinguish software faults from software failures. In case

of a failure, the software does not do what the user expects. A fault is a programming

error that may or may not actually manifest as a failure. A fault can also be described as

an error in the correctness of the semantic of a computer program. A fault will become a

failure if the exact computation conditions are met, one of them being that the faulty

portion of computer software executes on the CPU. A fault can also turn into a failure

when the software is ported to a different hardware platform or a different compiler, or

when the software gets extended. Software testing is the technical investigation of the

product under test to provide stakeholders with quality related information.

Software testing may be viewed as a sub-field of Software Quality Assurance but

typically exists independently (and there may be no SQA areas in some companies). In

SQA, software process specialists and auditors take a broader view on software and its

development. They examine and change the software engineering process itself to reduce

the amount of faults that end up in the code or deliver faster.

Regardless of the methods used or level of formality involved the desired result of testing

is a level of confidence in the software so that the organization is confident that the

software has an acceptable defect rate. What constitutes an acceptable defect rate depends

on the nature of the software. An arcade video game designed to simulate flying an

airplane would presumably have a much higher tolerance for defects than software used

to control an actual airliner.

A problem with software testing is that the number of defects in a software product can

be very large, and the number of configurations of the product larger still. Bugs that

occur infrequently are difficult to find in testing. A rule of thumb is that a system that is

expected to function without faults for a certain length of time must have already been

tested for at least that length of time. This has severe consequences for projects to write

long-lived reliable software.

A common practice of software testing is that it is performed by an independent group of

testers after the functionality is developed but before it is shipped to the customer. This

practice often results in the testing phase being used as project buffer to compensate for

project delays. Another practice is to start software testing at the same moment the

project starts and it is a continuous process until the project finishes.

Another common practice is for test suites to be developed during technical support

escalation procedures. Such tests are then maintained in regression testing suites to

ensure that future updates to the software don’t repeat any of the known mistakes.

It is commonly believed that the earlier a defect is found the cheaper it is to fix it.

Time Detected

Time Introduced Requirements Architecture Construction System Test

Post-Release

Requirements 1 3 5-10 10 10-100

Architecture - 1 10 15 25-100

Construction - - 1 10 10-25

In counterpoint, some emerging software disciplines such as extreme programming and

the agile software development movement, adhere to a “test-driven software

development” model. In this process unit tests are written first, by the programmers

(often with pair programming in the extreme programming methodology). Of course

these tests fail initially; as they are expected to. Then as code is written it passes

incrementally larger portions of the test suites. The test suites are continuously updated as

new failure conditions and corner cases are discovered, and they are integrated with any

regression tests that are developed.

Unit tests are maintained along with the rest of the software source code and generally

integrated into the build process (with inherently interactive tests being relegated to a

partially manual build acceptance process).

The software, tools, samples of data input and output, and configurations are all referred

to collectively as a test harness.

History

The separation of debugging from testing was initially introduced by Glenford J. Myers

in his 1978 book the “Art of Software Testing”. Although his attention was on breakage

testing it illustrated the desire of the software engineering community to separate

fundamental development activities, such as debugging, from that of verification. Drs.

Dave Gelperin and William C. Hetzel classified in 1988 the phases and goals in software

testing as follows: until 1956 it was the debugging oriented period, where testing was

often associated to debugging: there was no clear difference between testing and

debugging. From 1957-1978 there was the demonstration oriented period where

debugging and testing was distinguished now – in this period it was shown, that software

satisfies the requirements. The time between 1979-1982 is announced as the destruction

oriented period, where the goal was to find errors. 1983-1987 is classified as the

evaluation oriented period: intention here is that during the software lifecycle a product

evaluation is provided and measuring quality. From 1988 on it was seen as prevention

oriented period where tests were to demonstrate that software satisfies its specification, to

detect faults and to prevent faults. Dr. Gelperin chaired the IEEE 829-1988 (Test

Documentation Standard) with Dr. Hetzel writing the book “The Complete Guide of

Software Testing”. Both works were pivotal in to today’s testing culture and remain a

consistent source of reference. Dr. Gelperin and Jerry E. Durant also went on to develop

High Impact Inspection Technology that builds upon traditional Inspections but utilizes a

test driven additive.

White-box and black-box testing

To meet Wikipedia’s quality standards, this section may require cleanup.

Please discuss this issue on the talk page, and/or replace this tag with a more specific

message. Editing help is available.

This section has been tagged since February 2007.

White box and black box testing are terms used to describe the point of view a test

engineer takes when designing test cases. Black box being an external view of the test

object and white box being an internal view. Software testing is partly intuitive, but

largely systematic. Good testing involves much more than just running the program a few

times to see whether it works. Thorough analysis of the program under test, backed by a

broad knowledge of testing techniques and tools are prerequisites to systematic testing.

Software Testing is the process of executing software in a controlled manner; in order to

answer the question “Does this software behave as specified?” Software testing is used in

association with Verification and Validation. Verification is the checking of or testing of

items, including software, for conformance and consistency with an associated

specification. Software testing is just one kind of verification, which also uses techniques

as reviews, inspections, walk-through. Validation is the process of checking what has

been specified is what the user actually wanted.

• Validation: Are we doing the right job?

• Verification: Are we doing the job right?

In order to achieve consistency in the Testing style, it is imperative to have and follow a

set of testing principles. This enhances the efficiency of Testing within SQA team

members and thus contributes to increased productivity. The purpose of this document is

to provide overview of the testing, plus the techniques.

At SDEI, 3 levels of software testing is done at various SDLC phases

• Unit Testing: in which each unit (basic component) of the software is tested to

verify that the detailed design for the unit has been correctly implemented

• Integration testing: in which progressively larger groups of tested software

components corresponding to elements of the architectural design are integrated and

tested until the software works as a whole.

• System testing: in which the software is integrated to the overall product and

tested to show that all requirements are met

A further level of testing is also done, in accordance with requirements:

• Acceptance testing: upon which the acceptance of the complete software is based.

The clients often do this.

• Regression testing: is used to refer the repetition of the earlier successful tests to

ensure that changes made in the software have not introduced new bugs/side effects.

In recent years the term grey box testing has come into common usage. The typical grey

box tester is permitted to set up or manipulate the testing environment, like seeding a

database, and can view the state of the product after his actions, like performing a SQL

query on the database to be certain of the values of columns. It is used almost exclusively

of client-server testers or others who use a database as a repository of information, but

can also apply to a tester who has to manipulate XML files (DTD or an actual XML file)

or configuration files directly. It can also be used of testers who know the internal

workings or algorithm of the software under test and can write tests specifically for the

anticipated results. For example, testing a data warehouse implementation involves

loading the target database with information, and verifying the correctness of data

population and loading of data into the correct tables.

Test levels

• Unit testing tests the minimal software component and sub-component or modules

by the programmers.

• Integration testing exposes defects in the interfaces and interaction between

integrated components(modules).

• Functional testing tests the product according to programmable work.

• System testing tests an integrated system to verify/validate that it meets its

requirements.

• Acceptance testing can be conducted by the client. It allows the end-user or

customer or client to decide whether or not to accept the product. Acceptance testing may

be performed after the testing and before the implementation phase. See also

Development stage

o Alpha testing is simulated or actual operational testing by potential

users/customers or an independent test team at the developers’ site. Alpha testing is often

employed for off-the-shelf software as a form of internal acceptance testing, before the

software goes to beta testing.

O Beta testing comes after alpha testing. Versions of the software, known as beta

versions, are released to a limited audience outside of the company. The software is

released to groups of people so that further testing can ensure the product has few faults

or bugs. Sometimes, beta versions are made available to the open public to increase the

feedback field to a maximal number of future users.

It should be noted that although both Alpha and Beta are referred to as testing it is in fact

use emersion. The rigors that are applied are often unsystematic and many of the basic

tenets of testing process are not used. The Alpha and Beta period provides insight into

environmental and utilization conditions that can impact the software.

After modifying software, either for a change in functionality or to fix defects, a

regression test re-runs previously passing tests on the modified software to ensure that the

modifications haven’t unintentionally caused a regression of previous functionality.

Regression testing can be performed at any or all of the above test levels. These

regression tests are often automated.

Test cases, suites, scripts and scenarios

A test case is a software testing document, which consists of event, action, input,

output, expected result and actual result. Clinically defined (IEEE 829-1998) a test case is

an input and an expected result. This can be as pragmatic as ‘for condition x your derived

result is y’, whereas other test cases described in more detail the input scenario and what

results might be expected. It can occasionally be a series of steps (but often steps are

contained in a separate test procedure that can be exercised against multiple test cases, as

a matter of economy) but with one expected result or expected outcome. The optional

fields are a test case ID, test step or order of execution number, related requirement(s),

depth, test category, author, and check boxes for whether the test is automatable and has

been automated. Larger test cases may also contain prerequisite states or steps, and

descriptions. A test case should also contain a place for the actual result. These steps can

be stored in a word processor document, spreadsheet, database or other common

repository. In a database system, you may also be able to see past test results and who

generated the results and the system configuration used to generate those results. These

past results would usually be stored in a separate table.

The term test script is the combination of a test case, test procedure and test data. Initially

the term was derived from the byproduct of work created by automated regression test

tools. Today, test scripts can be manual, automated or a combination of both.

The most common term for a collection of test cases is a test suite. The test suite often

also contains more detailed instructions or goals for each collection of test cases. It

definitely contains a section where the tester identifies the system configuration used

during testing. A group of test cases may also contain prerequisite states or steps, and

descriptions of the following tests.

Collections of test cases are sometimes incorrectly termed a test plan. They might

correctly be called a test specification. If sequence is specified, it can be called a test

script, scenario or procedure.

A sample testing cycle

Although testing varies between organizations, there is a cycle to testing:

9. Requirements Analysis: Testing should begin in the requirements phase of the

software development life cycle.

During the design phase, testers work with developers in determining what aspects of a

design are testable and under what parameter those tests work.

2. Test Planning: Test Strategy, Test Plan(s), Test Bed creation.

3. Test Development: Test Procedures, Test Scenarios, Test Cases, Test Scripts to

use in testing software.

4. Test Execution: Testers execute the software based on the plans and tests and

report any errors found to the development team.

5. Test Reporting: Once testing is completed, testers generate metrics and make final

reports on their test effort and whether or not the software tested is ready for release.

6. Retesting the Defects

Not all errors or defects reported must be fixed by a software development team. Some

may be caused by errors in configuring the test software to match the development or

production environment. Some defects can be handled by a workaround in the production

environment. Others might be deferred to future releases of the software, or the

deficiency might be accepted by the business user. There are yet other defects that may

be rejected by the development team (of course, with due reason) if they deem it

inappropriate to be called a defect.

- Reference www.wikipedia.org

Test Model

Testing Admin User

Type: UseCaseStatus: Proposed. Version 1.0. Phase 1.0.

Test Plans

Master Test Plan

Type: ArtifactStatus: Proposed. Version 1.0. Phase 1.0.

Test Cases

CONCLUSION

We presented a framework for mining, tracking, and validating evolving

multifaceted user profiles on Web sites that have all the challenging aspects of real-life

Web usage mining, including evolving user profiles and access patterns, dynamic Web

pages, and external data describing an ontology of the Web content. A multifaceted user

profile summarizes a group of users with similar access activities and consists of their

viewed pages, search engine queries and inquiring and inquired companies. The choice of

the period length for analysis depends on the application or can be set, depending on the

cross-period validation results. Even though we did not focus on scalability, the latter can

be addressed by following an approach similar to, where Web click streams are

considered as an evolving data stream, or by mapping some new sessions to persistent

profiles and updating these profiles, hence eliminating most sessions from further

analysis and focusing the mining on truly new sessions.

BIBLIOGRAPHY

Base Paper: A Web Usage Mining Framework for Mining Evolving User profiles in

Dynamic Web sites.

- IEEE 2008 Olfa Nasraoui, Maha Soliman, Esin Saka, Antonio Badia, Richard

Germain.

Java 2 Complete Reference

- Herbert Schildt.

Data Mining

- BPB Publications

Professional Java Server Programming

- Subrahmanyam Allamaraju

Algorithm Design

- Robert Callway.

A Web Usage Mining Framework for Evolving User Profiles.

Documents

Transcript of A Web Usage Mining Framework for Evolving User Profiles.