SellSmart Project Proposal



CS551 Advanced Software Engineering

SellSmart©

Project Design

October 22, 2003

by

DesiGeeks

Vinit Nagda (vmn5xc@umkc.edu)

Deepa Colluru (dczn6@umkc.edu)

Uday Kapoor (uk5w9@umkc.edu)

Venetia Raheja (vsrxtd@umkc.edu)

Sampath Akkineni (skaty8@umkc.edu)

Vijay Bhaskar Puram (vbprh7@umkc.edu)

Wenxuan Kang (wkq49@umkc.edu)

School of Computing & Engineering

University of Missouri Kansas City

Table Of Contents

1 Dictionary 4

2 REQUIREMENT SPECIFICATION 7

2.1 Stakeholders 7

2.2 Functional Requirements 7

2.2.1 Display Welcome Screen 7

2.2.2 Registration and Authentication 7

2.2.3 Search Screen 7

2.2.4 Search Results Screen 7

2.2.5 Favorites List 7

2.2.6 Sales Agents Requirements 8

2.2.7 Concurrent use 8

2.2.8 Performance / SLA 8

2.2.9 Consistency 8

2.2.10 Reliability/Accuracy 8

2.2.11 Comparison Analysis 8

2.3 Non-Functional Requirements 8

2.3.1 Mobility 8

2.3.2 Information from Other Dealers 9

2.3.3 Portability 9

2.3.4 User Interface requirements 9

2.4 Technical / Business Requirements 9

3 FRAMEWORK SPECIFICATIONS 10

3.1 Algorithms [Pseudo Code] 10

3.1.1 Pseudo Code for Client application 10

3.1.2 Pseudo Code for a SOAP Interface Call 10

3.1.3 Pseudo code for SQL Queries 11

3.1.4 Pseudo code for CORBA 11

3.1.5 Pseudo code for EJB 12

3.1.6 Pseudo code for DCOM 14

3.2 Data Structures 15

3.2.1 Vectors 15

3.2.2 Arrays 15

3.2.3 Lookup Hash Structure 15

3.3 Design Patterns 16

3.3.1 Adapter 16

3.3.2 Facade 18

3.3.3 Abstract Factory 19

3.3.4 Proxy 19

3.4 Database Design 20

3.4.1 Entity Relationship Diagram 20

3.4.2 Database Tables 21

4 SYSTEM SPECIFICATION 22

4.1 Use Case Diagram 22

4.1.1 System Use Case Diagram 22

4.1.2 Use Case Diagram for user: Guest 23

4.1.3 Use Case Diagram for user: Customer 23

4.1.4 Use Case Diagram for user: Sales Agent 24

4.1.5 Explanation for Use Case Diagram for all type of users 24

4.1.6 Clearly Defining System boundary 26

4.1.7 System and External Roles (for users, hardware, software) 27

4.1.8 Abstract Use Cases and Collaborations 27

4.2 Sequence Diagram for Use Cases 29

4.2.1 Sequence diagram for user: Guest 29

4.2.2 Sequence diagram for user: Customer 30

4.2.3 Sequence diagram for user: Sales Agent 31

4.3 Collaboration Diagram 32

4.3.1 Collaboration Diagram for user: Guest 32

4.3.2 Collaboration Diagram for user: Customer 33

4.3.3 Collaboration Diagram for user: Sales Agent 34

4.4 Operation Specification 35

4.5 Concrete Scenarios 38

5 SYSTEM USER INTERFACE 41

6 SYSTEM ARCHITECTURE DESIGN 48

6.1 SellSmart System Type Model 48

6.2 Component Diagram 49

6.3 Package Diagram 51

6.4 Protocol Design 52

6.4.1 Communication Channels between components 52

6.4.2 Utility Components and code 53

7 CLASS DIAGRAM 54

7.1 SellSmart system class diagram 54

7.2 External System Class Diagram 57

7.2.1 Class Diagram for EJB 57

7.2.2 Class Diagram for DCOM 58

Dictionary

|Type |Description |

| | |

|Abstract Factory pattern: |Provides an interface for creating families of related or dependent objects without |

| |specifying their concrete classes. |

|Adapter |searchcriteria |These are the factors on which the search is carried out. Search criteria includes |

| | |make, model, price, color etc., |

| |Sessionid |Each session is identified by a unique session id. |

|AdapterFactory: |Represents the factory of abstract factory design pattern. Provides an interface for|

| |creating families of adapters without specifying their concrete classes. It is also |

| |the subsystem of Facade pattern. |

|Adaptor pattern: |Converts the interface of a class into another interface that clients expect. |

| |Adapter lets classes work together that couldn’t otherwise because of incompatible |

| |interfaces. |

|Auto dealer |He is the one who provides SellSmart system. Using the SellSmart system he can get |

| |better results from the sales agents. |

|Car |Carid |Every car has a unique car id |

| |Make |This field describes the make of the car |

| |Model |This field describes the model of the car |

| |Year |This field describes the year of manufacturing of the car |

| |Price |This field describes the cost of the car |

| |Color |This field describes the color of the car |

| |Mileage |This field describes the mileage on the car |

| |Location |This field describes the location of the car in the parking lot basically it is a |

| | |combination of one letter and two digits like A21, b25. |

| |New |This field describes whether the car is brand new or used |

| |Engine |This field describes the engine type like v6 and v4. |

| |Automatic |This field specifies whether it is automatic or manual |

| |Type |This field describes the type of the car whether it is a sedan or coupe |

| |Bestprice |This field specifies the bottom price of the car. Only the salesperson has access to|

| | |this field. He can negotiate with the customer instantaneously by looking this |

| | |field. |

| |Specifications |This field contains extra specifications that are not displayed in the initial |

| | |stages. When the user likes to see more details of the car then this will be |

| | |displayed. |

| |Externalid |This field contains the id of the car in the external database |

| |externalFlag |This field is checked when the external database is accessed |

| |Lock |If the car has a defect or sold then it will be locked and will not be displayed |

|COMAccess: |Includes both COM server and client. |

|COMSearchAdapter: |One adapter of Adapter Pattern. Adapts COM subsystem. |

|CORBASearchAdapter: |One adapter of Adapter Pattern. Adapts CORBA subsystem. |

|Customer |A customer is a registered user for this system. He maintains his favorite list of |

| |cars by searching the system using various criteria like make, model, price, color |

| |etc., |

|EJBSearchAdapter: |One adapter of Adapter Pattern. Adapts EJB subsystem. |

|External Search |User can search several partnership companies for a specific type of car |

|ExternalSearchAdapter: |The target of Adapter Pattern. Abstract the interfaces of three subsystems |

| |(COMSearchAdapter, EJBSearchAdapter, CORBASearchAdapter) into one interface that its|

| |client expects. |

|ExternalSearchFacade: |The facade of all ExternalSearch subsystems. Provides a unified interface to a set |

| |of interfaces in all the subsystems. The higher-level interface makes the subsystems|

| |easier to use. |

|Facade pattern: |Provide a unified interface to a set of interfaces in a subsystem. Façade defines a |

| |higher-level interface that makes the subsystem easier to use. |

|Favorites List: |This contains the lists of the cars liked by the user |

|Guest: |Guest is not a registered user. He can search for various cars just like a normal |

| |registered customer but the difference is he cannot save his profile with out being |

| |registered. |

|IclassFactory: |The IClassFactory interface contains two methods intended to deal with an entire |

| |class of objects, and so is implemented on the class object for a specific class of |

| |objects (identified by a CLSID). The first method, CreateInstance, creates an |

| |uninitialized object of a specified CLSID, and the second, LockServer, locks the |

| |object's server in memory, allowing new objects to be created more quickly. |

|IexternalSearch: |The interface for the COMAccess. |

|Iunknown: |The IUnknown interface lets clients get pointers to other interfaces on a given |

| |object through the QueryInterface method, and manage the existence of the object |

| |through the IUnknown::AddRef and IUnknown::Release methods. All other COM interfaces|

| |are inherited, directly or indirectly, from IUnknown. Therefore, the three methods |

| |in IUnknown are the first entries in the VTable for every interface. |

|JNIAccess: |The abstract class includes several native methods, JVM to call JNIImpl. |

|JNIImpl: |The class that implement the JNIAccess. |

|Proxy pattern: |Provide a surrogate or placeholder for another object to control access to it. |

|Sales Agent |Sales Agent can have privileged access to this system. He has access to the |

| |confidential information like best price, using this he can negotiate with the |

| |customer instantly rather than making turns to and fro the auto dealer’s office. |

|Salesman |Refers to the same class of users as Sales Agent. Sales Agent and Salesman have been|

| |used interchangeably throughout the document. |

|SellSmartRemote |It is the default remote interface provided by the EJB container tools |

|SellSmartBean |This will give the implementation of all the business methods as well as methods |

| |defined in this interface. |

|SellSmartHome |It is the default home interface provided by the EJB container tools. |

|User |Refers to the generic class of users of the SellSmart system. They can be further |

| |specialized as guest (unregistered user), customer (registered user) and Sales |

| |Agent. |

| | |

| |Userid |Gives the userid of the user |

| |Password |Gives the password of the user |

| |Firstname |Gives the firstname of the user |

| |Lastname |Gives the lastname of the user |

| |Phone |Gives the phone number of the user |

| |Email |Gives the email id of the user |

| |Lastvisit |Gives when the user has last visited the system |

| |Rating |Rating is a value Sales Agent attaches to each customer (registered user) depending |

| | |on the interest shown by them. The rating field along with the LastVist field can be|

| | |used by the dealership later to follow up with potential customers. |

| |Type |This classifies the broad generic field of users into specific ones like guest |

| | |(unregistered user), customer (registered user), and Sales Agent (registered user |

| | |with special privileges). |

REQUIREMENT SPECIFICATION

1 Stakeholders

Stakeholders of the SellSmart system are auto dealers, sales agents and customers. Auto dealers can get increased sales from their sales agents by making use of this system. Through the path of collaborations, the auto dealers can target customers who are even farther away from their reach. Also the auto dealers can cut down on the manual labor costs, associated with the car sales. Sales agents can be very productive and offer better service to their customers as they have all the information readily available. The SellSmart system enables the sales agents to save trips back to their office and thus serve more customers. Customers can search for cars available with various dealers, based on different search criteria and maintain a favorite list without needing the assistance of sales agents.

2 Functional Requirements

1 Display Welcome Screen

SellSmart should display the welcome screen on startup. This screen will help differentiating between registered users and guest users.

2 Registration and Authentication

SellSmart should authenticate the existing users’ login and password information. If the authentication fails, a message should be displayed and the user should be prompted for re-login. The system also provides a means for prospective customers/first time users to use the system without registration. A ‘Guest’ login would be provided which would enable guests to browse the inventory and select cars to add to their favorites list. However guests need to register, if they want to save the favorite list and personal information in the SellSmart system.

3 Search Screen

Search screen should have several fields to accept the users search criteria. Search can be performed using any one or combination of price, car id, make, model and year.

4 Search Results Screen

Search Results screen should display the car id, make, model, year, and price and car location if any of the cars in the dealer’s inventory match the search criteria. User can sort the search results on the basis of any of these criteria. Default sort order will be on descending price.

5 Favorites List

Registered users of the SellSmart system can maintain a favorites list of cars. This favorites list is valid only for that session for customers that do not have accounts. If the customer wants to save his favorites, then customer should be prompted for account creation if he/she doesn’t already have an account.

6 Sales Agents Requirements

Sales agents should have access to confidential information such as best price that can be offered on a particular vehicle, any promotions available for this vehicle. Also the sales person will be able to assign ratings for a customer, based on the amount of interest the particular user shows in buying a car. The salesman can later use this information along with the ‘last accessed’ date information of various users to follow up with them.

7 Concurrent use

Multiple users should be able to use the system at the same time.

8 Performance / SLA

The system should have reasonable response time. Response time should not increase with the increased number of users.

9 Consistency

SellSmart should at any point of time only show car information that is consistent. We provide a mechanism for the sales agent to be able to ‘lock’ a car if the car is already sold or if any defect has been discovered in a particular car. Cars with a ‘locked’ attribute will not be displayed in search results. SellSmart also maintains consistency of the information by fetching ‘fresh’ results each time, and not caching local copies. This can affect the response time; however SellSmart gives more importance to consistent data over response time.

10 Reliability/Accuracy

The system should provide reliable and accurate information to the users.

11 Comparison Analysis

After the successful implementation and deployment of SellSmart in the field, DesiGeeks will perform comparison analysis to gauge the performance of various middleware technologies used to connect to external dealership systems. Below mentioned are some of the analysis criteria:

✓ Platform Independence.

✓ Language Independence.

✓ Ease of use.

✓ Portability.

✓ State Management.

✓ Persistence Management.

3 Non-Functional Requirements

1 Mobility

One of the requirements of the dealership is to make its work force mobile and increase their productivity by servicing the customers better and provide instantaneous answers to their queries. To meet the requirements of a mobile client application, SellSmart, a PDA client using Embedded Visual Basic is developed. The requirement could be met by making the client application as thin as possible, restricting it to be used as an interface to receive customer input and display result. In this architecture the web-service would be used as a medium to provide bi-directional communication between the client application and the server application, which will be doing the bulk of the processing.

2 Information from Other Dealers

System should provide the ability to communicate with other dealers/partners and get the information of the cars available with them.

3 Portability

Though this is a PDA based system, it should be extendable to a web based system with minimal changes. However extending the system to be Web based is not a part of the project and will be regarded as future work.

4 User Interface requirements

Despite similarities in functionality, or being made of the same components, desktop and handheld computers are different entities with different users and uses. The obvious reasons for a different design are absence of keyboard, use of finger or stylus, limited user screen, and many more. For handhelds one requires careful placement of controls on the screen, progressive disclosure, large buttons over which stylus can be used, and consistency with platform of choice. Also considering factors like integration with desktops, design for speed, decreasing the overall navigation in application, and low reliability due to being connected.

4 Technical / Business Requirements

SELLSMART would change the way people buy cars and the way car dealerships do business. The project aims at taking the auto sales industry to the next level by promoting co-operation amongst various dealerships. Successful implementation of SellSmart would result in various partnership agreements amongst competing dealerships and benefit the customer by providing a vast collaborated inventory to choose from. Implementing SellSmart over the Web, could result in global partnerships, and help businesses develop a strategic alliance to take advantage of additional business opportunities. SELLSMART implements the adaptation layer which bridges the gap between various technologies making it easier for dealerships to collaborate on sales efforts and maintaining their own infrastructure and individual identity at the same time.

FRAMEWORK SPECIFICATIONS

1 Algorithms [Pseudo Code]

1 Pseudo Code for Client application

//define objects

Dim env As PocketSOAP.Envelope

Dim http As PocketSOAP.HTTPTransport

Dim Request As String

Dim Response As String

//create SOAP envelope

Set env = CreateObject(“PocketSOAP.Envelope”)

Env.MethodName = “searchCar”

Env.URI = “xyz”

//create initialize parameters

Env.CreateParameter “Criteria”, “Car”

// serialize the request to be sent using http protocol

Request = env.serialize

//create HTTP transport to access web service

Set http = CreateObject(“PocketSOAP.HTTPTransport”)

http.send “…”, Request

//receive response

Response = http.Receive

2 Pseudo Code for a SOAP Interface Call

//sending or receiving a soap message

honda

Accord

2001

15000

used

60000

3 Pseudo code for SQL Queries

//Query to retrieve car information from the database

SELECT * FROM car_info

WHERE make = ? AND model = ?

AND price = ? AND year = ?

//Create a new user in the system

INSERT INTO user(userId, password, firstName, lastName, phoneNo, email)

VALUES( ?, ?, ?, ?, ?, ?)

//Retrieve user details

SELECT * FROM user WHERE userId = ?

4 Pseudo code for CORBA

CORBA Client

Create SellSmart client

{

main method

{

create and initialize ORB

get root naming context

resolve object reference in naming

invoke search method from the obtained server object

}

}

CORBA Server

Begin

Create a SellSmartServant class by extending from ImplBase class

Implement the business method

Vector search(Car car)

{

retrieve search parameters from Car object

prepare sql statement

execute sql

process result set

compile results into a Vector object

return Vector object

}

Create a SellSmart server class

{

create main method

{

create and initialize ORB

create servant object

register with ORB using connect method

get the root naming context

resolve initial references

narrow

bind the object reference using rebind method

wait for invocations from clients

}

}

end

5 Pseudo code for EJB

EJB Container

EJB Client

Class SellSmartClient

{

main method

{

declare and initialize url string

create HashTable to save initial_context_factory and provider_url

populate HashTable with the values of initial_context_factory and provider_url

create InitialContext with the above information

obtain SellSmartHome reference using lookup and narrow methods

create a SellSmart object from the obtained SellSmartHome reference

invoke search(Car car) method from SellSmart reference

}

}

SellSmart Bean

Class SellSmartBean

{

implement session bean

SellSmartBean() constructor

define method ejbCreate()

define method ejbRemote()

define method ejbActivate()

define method ejbPassivate()

method setSessionContext()

Vector search(Car car) // method that provides business functionality

}

//SellSmartRemote the remote interface

Interface SellSmartRemote

{

extend it from EJBObject

Vector search(Car car)

}

//SellSmartHome the home interface

interface SellSmartHome

{

extend it from EJBHome

SellSmart create()

}

6 Pseudo code for DCOM

DCOM Client

SearchByCOM

{

Create JNIAccess class in Adaptor

Call native method search with search criteria

{

JVM Call JNIImpl

Create COM proxy intance by using ClassFactory

Call search RPC

{

Remote COM created

Create ADO (Active Data Object) connection object

Create Command Object

Run Execute with search Criteria

Return RecordSet

}

Convert Recordset to be Java Records

Return Records

}

Convert Java Records to adaptor expected type

Return to Adaptor

}

2 DATA STRUCTURES

Definition: An organization of information, usually in memory, for better algorithm, efficiency, such as vectors, queue, stack, linked, heap, dictionary, and tree, or conceptual unity, such as the name and address of a person. It may include redundant information, such as length of the list or number of nodes in a sub tree.

1 Vectors

Vector is a type-independent pattern for a self-contained array class whose capacity may vary.  The capacity of a vector object is the number of data values it can hold (can be increased as necessary).

In SellSmart when the user performs a search for his dream car. He receives a vector of cars as the response and these are displayed on the screen. Here each car is an object with attributes (color, mileage, engine, transmission, etc.)The car objects in the vector will be retrieved from the SellSmart Database Table: ‘Car’.

Similarly when the salesperson is SEARCHING for customers, a vector of customers is returned to the calling program. Each customer is analogous to an object. Again the data for the arrays will be obtained from the database table ‘User’.

When a user is browsing a car he can keep adding car descriptions to his Favorites’ List. For a particular session, this is done locally as a temporary vector. When a user logs out of the system, he is prompted within update screen that asks him whether he wishes to update his favorites list. If the user is interested then the UPDATE is performed in the SellSmart Database in the form of a vector of car objects.

2 Arrays

An array is a group of elements, which are all of the same type, size and name. It can be thought of as a box with multiple compartments, each compartment capable of storing one data item.

The session id for each client is stored in the Web Service and Adaptor. This is maintained in the web Service and adaptor as an array.

The results of a car search can be displayed in a sorted format as selected [ascending/descending]. This is accomplished by implementing Bubble Sort with the help of arrays.

3 Lookup Hash Structure

Lookup tables are a sequence of data (numbers or characters) that are used for conversion purposes.

SellSmart maintains a mapping data structure for each external dealer and the technology that they use for communication [CORBA, EJB, and DCOM]

|Dealer 1 |CORBA |

|Dealer 2 |EJB |

|Dealer 3 |DCOM |

3 Design Patterns

[pic]

In SellSmart, we are using 4 design patterns namely Adapter, Facade, Proxy and Abstract Factory.

1 Adapter

This design pattern states to convert the interface of a class into another interface that the clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

[pic]

Participants:

Target (ExternalSearchAdaptor)

Defines the domain-specific interface that client uses.

Client (webservice)

Collaborates with the objects conforming to the Target interface.

Adapter (COMSearchAdaptor, EJBSearchAdaptor, CORBASearchAdaptor)

Adapts the interface of Adaptee to the Target interface.

Adaptee (COM subsystem, EJB subsystem, CORBA subsystem)

Defines an existing interface that needs adapting.

How it applies to SellSmart:

In the SellSmart System, we use DCOM, CORBA and EBJ subsystems to simulate possible existing systems. To be more precise, there are a lot of unforeseen subsystems that do not necessarily have the same interface. To adapt these existing or unknown upcoming subsystems, an object adapter can adapt the interface of its parent class.

Here, ExternalSearchAdapter is an abstract class that defines the interface SellSmart needs. COMSearchAdapter, EJBSearchAdaptor and CORBASearchAdapter will implement this interface, and will coordinate with its own subsystem respectively.

2 Facade

Provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Participants:

Façade (ExternalSearchFacade)

-Knows which subsystem classes are responsible for a request

-Delegates client requests to appropriate subsystem objects.

Subsystem classes (AdaptorFactory, ExternalSearchAdaptor, COMSearchAdaptor, etc. )

-Implement the subsystem functionality.

-Handle the work assigned by the Facade object.

-Have no knowledge of the facade.

How it applies to SellSmart:

In SellSmart System, Adapter has to deal with complicated subsystems like DCOM, EJB, CORBA and so forth. Our goal is to build one front door through which we can expose and control the calling message traffic. As far as adapter is concerned, to make it more flexible and open that is essential for Object Oriented design, we do not want to limit its use to a specific type of communication protocol and the calling system. ExternalSearchFacade makes it possible for different callers to view the External Search System as a whole.

3 Abstract Factory

Provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Factories are powerful tools. They can be of great benefit in conforming to the DIP (Dependency Inversion Principle). They allow high-level policy modules to create instances of classes without depending on the concrete implementations of those classes. They also make it possible to swap in completely different families of implementations for a group of classes

How it applies to SellSmart:

In our system, AdapterFactory is responsible for creating corresponding subsystem adapter, and return an abstract ExternalSearchAdapter reference.

AdapterFactory makes high-level object control easier. Caller does not need to depend on the concrete implementation. What caller knows is just the AdapterFactory and ExternalSearchAdapter interface, which makes the calling system loosely coupled with the unstable subsystems.

4 Proxy

Provides a surrogate or placeholder for another object to control access to it.

Proxy pattern is hidden applied. For middleware systems such as COM, EJB or CORBA, proxy pattern is widely used to take care of transport level communication, marshaling / unmarshaling messages, distributed garbage collection and so forth. Moreover, it guarantees exposing the same interface as the remote interface, which makes it transparent for the caller.

4 Database Design

1 Entity Relationship Diagram

[pic]

Entity Relationship Diagram will give the overall logical structure of the database graphically.

Our ER diagram mainly consists of 3 entities Users: Car_info: and Favorites. Each user will be given a userid and a password for authentication based on the first name, last name, phone no and email id. Rating is given to the user based on his favorites list and how frequently he has visited the system. User can look at car information and can add to the favorites if he likes the car. A car can have car id, make, model, year of manufacturing, price of the car, best price up to which it can be negotiated, color, mileage on the car, external id, external flag, lock, location in the parking lot, whether new or a used one, engine type, automatic or manual, other specifications of the car and type of the car.

1 Database Tables

|[pic] |[pic] |

|[pic] |[pic] |

SYSTEM SPECIFICATION

1 Use Case Diagram

1 System Use Case Diagram

[pic]

3 Use Case Diagram for user: Guest

[pic]

5 Use Case Diagram for user: Customer

[pic]

6 Use Case Diagram for user: Sales Agent

[pic]

7 Explanation for Use Case Diagram for all type of users

Use Case: Register

Actor: Guest

Type: Primary

Description: A guest user needs to register if he/she wants to use features like favorites list. A sales agent needs to register before using the system. Users will select user id and password when they register into the system.

Use Case: Login

Actor: Sales Agent, Customer, Guest

Type: Primary

Description: All users can login into the system by using their user id and password. Guest users will be given a default user id to login

Use Case: InternalSearch

Actor: Sales Agent, Customer, Guest

Type: Primary

Description: Users can use search functionality to find the cars that match their requirements. Search can be performed by different criteria like make, model, price, mileage, used or new etc.

Use Case: ExternalSearch

Actor: Sales Agent, Customer, Guest

Type: Primary

Description: External search can be performed when internal search doesn’t return any results. This search will be performed only when the customer/guest wants to find out if other dealers in the region have any vehicles that match their search criteria.

Use Case: ViewResults

Actor: Sales Agent, Customer, Guest

Type: Primary

Description: Results can be viewed in two different ways. Initial search results will have one line displays showing make, model, car price and mileage. Detailed information about a particular vehicle will be displayed on double clicking on the initial search result.

Use Case: AddFavorites

Actor: Customer, Guest

Type: Primary

Description: Guest users and customers can maintain their favorites lists. Guest favorite list is valid only for that session. Customer can save his/her favorite list and view on next visit. This use case maintains the favorite list in the memory temporarily.

Use Case: SaveFavorites

Actor: Customer, Guest

Type: Primary

Description: Users need to be registered before they can save their favorites. This favorite list information will be saved to the database.

Use Case: ViewFavorites

Actor: Customer, Guest

Type: Primary

Description: Customers can view their favorites list on subsequent visits. This will be helpful when customers want to come back after couple of weeks and compare saved favorite vehicles with any new vehicles that may have arrived since their last visit.

Use Case: ShowBestPrice

Actor: Sales Agent

Type: Primary

Description: Best price that can be offered to customers is saved in the database. Salesagents have access to this information so they need not go to their supervisors before they can offer that price to customers.

Use Case: ShowPromotions

Actor: Sales Agent

Type: Primary

Description: Sales agents also can view any special promotions going on at that time. These promotions can be like special interest rates, cash back bonus etc.

Use Case: SaveCustomerInfo

Actor: Sales Agent

Type: Primary

Description: Sales agents can save customers contact information for follow up. This information includes the vehicles they are interested in, the price they are willing to pay etc.

8 Clearly Defining System boundary

This section binds what is “inside” and “outside” the SellSmart System.

Inside system Boundary:

✓ PDA Client

✓ Dealership Web Service

✓ Adaptor

Outside System Boundary:

✓ Partner Dealer with DCOM interface

✓ Partner Dealer with EJB interface

✓ Partner Dealer with CORBA interface

✓ In house Database System: We assume that the database is shared amongst various other systems that have been implemented at this dealership, and thus falls outside the SellSmart System Boundary.

9 System and External Roles (for users, hardware, software)

The following modules are external to the system

EJB: This software module is external to the SellSmart system. This module will provide search functionality from one of the other dealers in the region. This will be implemented using J2EE / EJB specification.

CORBA: This module is external to the SellSmart system as well. This module will provide search functionality from one of the other dealers in the region. This will be implemented using CORBA specification.

DCOM/JNI: This is another external module that provides the search functionality. This will be implemented using COM/JNI

PDA Emulator: This PDA Emulator is not implemented in the system. Instead this simulator will be used to host the UserInterface module.

Administrator: Administrator is an external user of the system. Administrator can set up accounts for sales agents in addition to maintaining the system.

10 Abstract Use Cases and Collaborations

[pic]

PerformSearch is an abstract use case that can be used by all actors of the system. InternalSearch and ExternalSearch are the two system use cases that make use of this abstract use case.

AcessSystem is another abstract use case that will be used by all actors of the system. Use cases Register and Login are abstracted by AccessSystem.

The FavoriteList abstract use case will be used by Actors Customer and Guest. It abstracts the AddFavorites, SaveFavorites and ViewFavorites use cases.

OtherFeatures abstract use case is used by SalesAgents. It abstracts the ShowBestPrice, ShowPromotions and SaveCustomerInfo use cases.

2 Sequence Diagram for Use Cases

1 Sequence diagram for user: Guest

[pic]

2 Sequence diagram for user: Customer

[pic]

3 Sequence diagram for user: Sales Agent

[pic]

3 Collaboration Diagram

1 Collaboration Diagram for user: Guest

[pic]

2 Collaboration Diagram for user: Customer

[pic]

3 Collaboration Diagram for user: Sales Agent

[pic]

5 Operation Specification

Operation: A Registered user accessing SellSmart

Pre-condition

The user should be at the SellSmart Dealership. He can be either a registered sales representative or a customer. A registered person has a valid username and password.

Post-condition

The system will validate the userid and password and if it is correct then the user will be taken to the main menu where he will be able to perform searches, perform operations on his ‘Favorites List’, update his profile or Logout. An error message will be displayed if the authentication fails. The user is taken back to the login screen.

Operation: Guest accessing SellSmart

Pre-condition

The guest should be at the SellSmart Dealership. The user is not registered into the system.

Post-condition

The search screen will be displayed where the user will be able to perform searches. The user should select at least one criterion for the search {model, make, price, year, mileage, carid, color, sort, and new/used}.

Operation: An authenticated user accessing main menu

Pre-condition

The user must be an authenticated salesperson or customer.

Post-condition

The main menu gives various options like search, operations on Favorites List, updating user profile and logout. If the login belongs to a sales representative, he must have the additional facility of performing a CUSTOMER SEARCH.

Operation: Search for the dream car

Pre-condition

The user who intends to perform the search should have logged onto the system as a registered salesperson, customer or a guest. The user should have select at least one criterion for the search {model, make, price, year, carid, mileage, color, sort, new/used}.

Post-condition

The system will perform a search based on the criteria and display the available cars. The search results will be displayed as a list of links. Detailed specifications are displayed when an individual link is selected.

Operation: Accessing an existing Favorites List.

Pre-condition

The registered user accesses his favorites list by selecting the Favorites List options in the main menu. The sales representative can also access the customer’s favorites list.

Post-condition

The favorites list that was saved by the user in the previous sessions will be displayed.

Operation: Adding to the Favorites List

Pre-condition

Any user can add to the favorites list.

Post-condition

The particular car will be added to the personal favorites list of the registered user. If the user is a guest, he will be prompted to either register or continue. If the guest chooses to just continue, a temporary favorites list will be maintained for the session.

Operation: Displaying the detailed results of a car from search

Pre-condition

The user should have made his search based on certain criteria. The user should select a particular car from the search results screen.

Post-condition

The following details are displayed: model, make, price, year, carid, color, sort, new/used, mileage, engine, transmission, type. If the login belongs to a sales representative then Lock and Pricing button are displayed.

Operation: Locking the car

Pre-condition

This operation can be only performed and viewed only by the sales representative. The sales representative should be in the detailed car specifications screen to perform a lock. Also the salesperson is prompted to enter the password. This information can be arrived at from the Search Results screen as well as the Favorites list.

Post-condition

By locking the car the system makes sure that the same car is not sold twice, or to flag the car as not available at the moment.

Operation: Accessing the confidential pricing information

Pre-condition

This operation can be only performed and viewed by the sales representative. The sales representative should be in the detailed car specifications screen to view the pricing information. Also the salesperson is prompted to enter the password before displaying the information. This information can be arrived at from the Search Results screen as well as the Favorites list.

Post-condition

The salesperson will be given the best bargain price at which the car can be sold. This avoids time lag created by the salesperson consulting the manager for every deal.

Operation: Updating profiles

Pre-condition

The user should be an authenticated registered user.

Post-condition

The user can update his phone number, email, first name, and last name.

Operation: External Search

Pre-condition

Any user can perform an external search (beyond the dealership of SellSmart)

Post-condition

The user will select a dealership from a list of available dealers and the search will return the list of available cars based on the criteria specified. The same criteria as specified earlier will be used.

Operation: Customer Search

Pre-condition:

Only the sales representative can perform the customer search operation based on first name, last name, customer id, by date [depends on when the user last accessed the SellSmart system] , and the rating [based on a scale of 1..5, a high rating indicates a high probability of the customer buying the car from the dealer]

Post-condition

A list of customers that satisfy the criteria is displayed. On selecting one of them the details {example: first and last name, phone, email, date, rating, favorites list} can be viewed.

Operation: Update customer rating

Pre-condition

Only the salesperson can do this in the customer details screen.

Post-condition

The rating signifies the probable customer on a scale of 1..5. The rating is updated for the customer.

Operation: Logout

Pre-condition

The option to logout is given at various stages in the system flow of searching a car. The operation is initiated by clicking the logout button.

Post-condition

The registered user is logged out of the system and taken back to the welcome screen. If the user is a guest and he has a temporary favorites list for the session, then he is prompted to register if he wants to save the list or logout of the system.

Operation: Registering into the system

Pre-condition

Any user who is interested can register into the system from the welcome screen. A guest can register when he tries to add the first car to the favorites list. A guest can also register when he is prompted to save his favorites and he selects ‘YES’

Post-condition

The registration form is displayed and asks for customer details like Name, Phone number and email address.

6 Concrete Scenarios

Scenario Name: A Registered user accessing SellSmart

Actors: Fred (customer), George (sales representative)

Event flow:

1. Fred/George clicks the login button on the welcome screen.

2. Fred/George enters the userid = {F00001/G00001} and password = fredishome / wilmageorge }.

3. Fred/George clicks the OK button to continue their login.

4. Fred/George clicks the CANCEL button to discontinue their login and come back to the welcome screen.

5. If the userid and password are authenticated then the MAIN MENU is displayed

6. The MAIN MENU for Fred comprises of SEARCH, MY FAVORITES and UPDATE PROFILE.

7. The MAIN MENU for George comprises of SEARCH, MY FAVORITES, CUSTOMER SEARCH and UPDATE PROFILE.

8. If the userid and password are invalid then an error message is displayed. Fred/George click OK on the error message and is taken to the login screen.

Scenario Name: A Registered Customer browsing SellSmart

Actors: Fred (registered customer)

Event flow:

1. Fred is logged into the system and comes to the MAIN MENU.

2. The MAIN MENU comprises of SEARCH, MYFAVORITES and UPDATE PROFILE.

3. Fred can access his Favorites List by clicking on the VIEW FAVORITES button.

4. Fred then views the list and can select his favorite BMW model.

5. Fred then views the detailed specifications of the BMW selected.

6. Fred can UPDATE his profile by clicking on the update button.

7. Fred is taken to the UPDATE screen where he can update his First Name, Last Name, Phone Number, and Email.

8. Fred then clicks OK.

Scenario Name: A Guest accessing SellSmart

Actors: Nancy (unregistered customer)

Event flow:

1. Nancy clicks the GUEST button on the welcome screen.

2. The SEARCH SCREEN is displayed.

Scenario Name: A Salesperson browsing SellSmart

Actors: George (salesperson)

Event flow:

1. George is logged into the system and comes to the MAIN MENU.

2. The MAIN MENU comprises of SEARCH, MY FAVORITES, CUSTOMER SEARCH and UPDATE PROFILE.

3. George can access his Favorites List by clicking on the VIEW FAVORITES button.

4. George then views the list and can select his favorite BMW model.

5. George then views the detailed specifications of the BMW selected.

6. George can show the same to the customer.

7. The MAIN MENU gives George the option of performing a CUSTOMER SEARCH. George clicks the CUSTOMER SEARCH button.

8. George can search by Name, Customer Id, date [depends on when the user last updated his profile] , and the rating [based on a scale of 1..5].

9. After George clicks OK, a list of customers is displayed. George can view the details (phone number, email, rating, favorites list of any desired customer in the Sell Smart Database.

10. The salesperson can change the rating of any registered customer in the SellSmart Database.

Scenario Name: Search for the ‘dream car’ [BMW, 760Li, 2003, Metallic Blue, New]

Actors: Fred (registered customer), Nancy (unregistered customer), George (sales representative)

Event flow:

1. Fred/Nancy/George performs a search for their dream car.

2. MAKE: select BMW.

3. MODEL: select 760Li

4. YEAR: enter 2003

5. COLOR: enter Metallic Blue

6. USAGE: select NEW

7. Fred/Nancy/George hits the OK button.

8. The list of relevant cars is displayed.

9. Fred/Nancy/George select the car of their choice to view specifications

10. The specifications shown are MAKE = BMW, MODEL = 760Li, YEAR = 2003, PRICE = $45000, COLOR = Metallic Blue, MILEAGE = 50, CAR LOT ID = G-4, VIN = EFF45567UHU, TYPE = SEDAN, ENGINE = V8, TRANSMISSION = dual

11. Fred/Nancy/George can add the BMW 760Li to their favorites list by clicking on the ADD TO FAVORITES button [‘+Favorites’ in snapshot] .

12.The first time Nancy adds a car to her favorites list she will be prompted to REGISTER or CONTINUE.

13.If Nancy chooses to CONTINUE her favorites will be stored temporarily for the session.

14.If Nancy chooses to REGISTER then she will be taken to the REGISTRATION SCREEN [explained in subsequent scenarios].

15. On continuation [assuming adding to favorites is complete] Fred/Nancy/George have the option of performing an EXTERNAL SEARCH if they are not satisfied or LOCKING a car if they found their dream car.

16. George has access to the confidential bargain price, which he invokes by clicking the PRICING button. He will be asked for password authentication to view this pricing detail.

Scenario Name: Registering into the system

Actors: Nancy (unregistered customer)

Event flow:

1. Nancy can choose to REGISTER into the SellSmart system either from the WELCOME SCREEN, when prompted for registration when she is trying to add a car to her favorites or when she tries to LOGOUT of SellSmart and wants to save her FAVORITES.

2. Nancy enters the following information in the Registration screen.

3. FIRST NAME: enter Nancy.

4. LAST NAME: enter Jones.

5. PHONE NUMBER: enter 816-705-1060

6. EMAIL: enter jonesn@

7. Nancy can then successfully LOGIN/SAVE HER FAVORITES in the system.

Scenario Name: External Search

Actors: Nancy (unregistered customer), Fred (registered customer), George (sales representative)

Event flow:

1. Fred/Nancy/George can use the EXTERNAL SEARCH button displayed on the results screen after a local search has been performed within the dealership.

2. The EXTERNAL SEARCH is done if Fred/Nancy/George is unsatisfied with the results.

3. On clicking the EXTERNAL SEARCH button, Fred/Nancy/George can choose which dealership they want to search within.

4. The criteria used for the EXTERNAL SEARCH will be the same as that of the local search.

5. The results are displayed as a list and the BMW’s detailed specifications can be obtained by clicking on the desired link.

Scenario Name: Locking the car.

Actors: Nancy (unregistered customer), Fred (registered customer), George (sales representative)

Event flow:

1. Fred/Nancy like the BMW 760Li shown in the search results and tell George to give them a good deal.

2. George can access the confidential pricing information by pressing the PRICING button on the BMW details screen.

3. George is prompted for his password.

4. If authenticated, George can get the last bargain price and put it forth to Fred/Nancy.

5. Fred/Nancy asks George to close the deal and George can complete that transaction by hitting the LOCK button.

6. George is again prompted for his password and requires authentication.

7. George gets authenticated and the LOCK transaction is complete.

8. By locking the BMW 760Li the system makes sure that the same car is not sold twice, or to flag the car as not available at the moment.

Scenario Name:Logout by a registered user

Actors: Fred (registered customer), George (sales representative)

Event flow:

1. Fred/George can logout of SellSmart from the MAIN MENU, CUSTOMER SEARCH, and CAR SEARCH.

2. Fred/George‘s favorites if any are stored in the system.

Scenario Name: Logout by an unregistered user

Actors: Nancy (unregistered customer).

Event flow:

1. Nancy can logout of SellSmart from the MAIN MENU, CUSTOMER SEARCH, and CAR SEARCH.

2.The system gives Nancy the message of ‘ESSENTIAL TO REGISTER’ to SAVE FAVORITES.

3. Nancy again has the option of REGISTERING into SellSmart.

4. If Nancy chooses to REGISTER, she is taken to the REGISTER SCREEN and her list of Favorites is stored in the SellSmart Database.

5. Nancy is logged out of SellSmart.

SYSTEM USER INTERFACE

User Interface design for a handheld differs widely from doing the same for a desktop computer. The reasons for the same are mentioned in the requirements section in 2.3.4. The following are important design criteria while designing user interface for a handheld device.

✓ There is limited real estate, so the number of controls placed on any one screen must be carefully considered.

✓ The design buttons must be large enough so they can be pushed with a finger or the stylus.

✓ The use of icons must be kept to a minimum.

✓ Consistency must be maintained with a platform of choice.

✓ The integration of the handheld with the desktop must be taken into account.

✓ Data input must be reduced.

✓ There should be a design for speed and the amount of navigation necessary throughout the application.

Below are the screenshots of the Graphical User Interface (GUI) for the SellSmart client PDA application.

|[pic] |Screen 1 |

| | |

| |WELCOME |

| | |

| |If the user is a salesperson or registered customer he can |

| |LOGIN. An unregistered customer can REGISTER or start browsing |

| |SELLSMART by clicking on the GUEST button. |

|[pic] |Screen 2 |

| | |

| |LOGIN |

| | |

| |A salesperson or registered customer can LOGIN into SellSmart |

| |by entering a userid and password. |

|[pic] |Screen 3 |

| | |

| |MAIN MENU |

| | |

| |After logging into the system a registered user arrives at |

| |the MAIN MENU where a customer can SEARCH, VIEW HIS |

| |FAVORITES or UPDATES his PROFILE. The Salesperson has an |

| |additional facility of a CUSTOMER SEARCH button, wherein he |

| |can look for a particular CUSTOMER |

|[pic] |Screen 4 |

| | |

| |SALES REPRESENTATIVE’S |

| |MAIN MENU |

| | |

| |A Sales representative can SEARCH, VIEW HIS FAVORITES or |

| |UPDATE his PROFILE. He has the additional facility of a |

| |CUSTOMER SEARCH button, wherein he can look for a |

| |particular CUSTOMER. |

|[pic] |Screen 5 |

| | |

| |SEARCH |

| | |

| |Any user can SEARCH for his dream car by selecting his |

| |criteria. |

|[pic] |Screen 6 |

| | |

| |SEARCH RESULTS |

| | |

| |This is the RESULTS screen and it lists the cars found in the |

| |SELLSMART dealership as per the search criteria. |

| | |

|[pic] |Screen 7 |

| | |

| |CAR DETAILS |

| | |

| |The CAR DETAILS screen can be obtained by clicking on the links|

| |in the results screen. The details like engine, transmission |

| |and mileage are viewed in this screen. |

|[pic] |Screen 8 |

| | |

| |REGISTRATION |

| | |

| |This is the REGISTRATION screen. An unregistered customer can |

| |fill in his details if he desires to be contacted in the future |

| |or SAVE a list of his FAVORITE cars. |

|[pic] |Screen 9 |

| | |

| |DISPLAY REGISTER MESSAGE |

| | |

| |This screen appears when an unregistered customer clicks LOGOUT |

| |on any screen. If the user wants to save his favorites list, he |

| |needs to click PROCEED to go to the registration screen. |

|[pic] |Screen 10 |

| | |

| |REGISTER / CONTINUE |

| | |

| |This screen appears the first time an unregistered user tries to |

| |Add a car to his favorites. If the user chooses to continue his |

| |favorites will be temporarily stored for the particular session. |

|[pic] |Screen 11 |

| | |

| |SAVE FAVORITES |

| | |

| |This screen appears when an unregistered customer clicks |

| |LOGOUT on any screen. |

|[pic] |Screen 12 |

| | |

| |CUSTOMER SEARCH |

| | |

| |This screen appears when a salesperson clicks the CUSTOMER |

| |SEARCH button in the MAIN MENU. A customer can be tracked by |

| |his First Name, Last Name, Customer Id, Joining Date and the |

| |Rating [1..5]. |

| | |

| | |

| | |

|[pic] |Screen 13 |

| | |

| |CUSTOMER DETAILS |

| | |

| |This screen appears when a salesperson wants to view the details |

| |of a particular registered customer. |

SYSTEM ARCHITECTURE DESIGN

1 SellSmart System Type Model

[pic]

2 Component Diagram

[pic]

Component diagram of SellSmart system consists of the following components:

PDA Client: This component consists of the UserInterface system. Several screens will be developed to provide the functionality and meet the requirements of the system. This component will also have an interface to communicate with the Web Services component.

Web Service: This component provides the Web Service. Web Service will be developed to accept input from the PDA Client component, retrieve information from internal database and return it to the PDA Client component. If the internal database doesn’t return any results and the user wishes to search from other dealers, it will communicate with Adaptor component to have the search performed externally.

Adaptor: This component acts as an interface between the SellSmart system and the external components. It is accessed when user wants to perform external search. It accesses the APIs/interfaces provided by the external components with input given by the Web Service component. This component also provides three client modules to access the three components that implement EJB, CORBA and COM technologies.

DCOM: This component implements three classes namely JNIAccess, JNIImpl, COMAccess, and one interface IExternalSearch. JNIAccess class and JNIImpl class will be created in Adaptor to bridge Java and COM. COMAccess class will create Remote COM, ADO (Active Data Object) connection object, Command Object, run Execute with search Criteria.

EJB: This component implements the home, remote interfaces and the bean. Bean object implements the search business method. This search API is accessed by the EJB client of Adaptor component.

CORBA: This component implements the CORBA server stubs and provides a search API. CORBA client stub of the Adaptor component accesses the search API.

3 Package Diagram

[pic]

Package diagram:

A “package diagram” is any UML diagram, mostly a UML Use Case diagram or UML Class diagram, composed only of packages. A package is a UML construct that allows organizing model elements, such as use cases or classes, into groups.

The WebServices package comprises of WebServiceClient and WebServiceServer. WebServices is a server for the client application and receives its requests, processes and give the final response to the PDA client. The WebServices is a client [for an external service]. It passes the requests to the Adaptor and waits for a response.

The Adaptor package comprises of the Adaptor Class which acts as the client for the external dealers and a server to the WebServices.

The PartnerDealers, Guest, User, Salesman and UseWebService classes are included in the Client package since they are the clients to SellSmart.

4 Protocol Design

1 Communication Channels between components

Protocol Name: PDA_Client & Web Service

Description: Protocol to accomplish successful communication between the PDA_client component and the dealership web service component.

Nature of the protocol: ( (

Sender: PDA_client

Receiver: Web Service

Protocol Name: Web Service & Database

Description: Protocol to accomplish successful communication between the web service component and the dealership database component.

Nature of the protocol:

Sender: Web Service

Receiver: Database

Protocol Name: Web Service & Adaptor

Description: Protocol to accomplish successful communication between the web service component and the SellSmart Adaptor component.

Nature of the protocol: (

Sender: Web Service

Receiver: SellSmart Adaptor

Protocol Name: Adaptor & External System

Description: Protocol to accomplish successful communication between the Adaptor component and the External system.

Nature of the protocol: ( OR OR )

Sender: Adaptor

Receiver: External System

2 Utility Components and code

Parsing: SellSmart will be using the Document Object Model (DOM) parser, for parsing the XML messages that travel between components. The DOM parser creates a tree like structure of the XML node which becomes easy to traverse.

Logging: SellSmart will not make use of any specialized tool for this purpose. However we will be using text based logging. The logging functions will be made available which would record errors, exceptions, and other failure modes in text files.

Other Utilities: Other utilities like Microsoft. NET framework system web services and Java utility classes will also be used as shown in the diagram above.

CLASS DIAGRAM

5 SellSmart system class diagram

[pic]

Class Car: An object of the Class:Car identifies/describes a car entity that is at the focus of the business model of SellSmart. The private attributes of Class:Car defines the properties of the car in question. The properties include carId, make, model, year, price, color, mileage, location, new, engine, automatic, type, specification, bestPrice, externalId, externalFlag, lock and vinNumber. The Class:Car also provides the public implementation of the appropriate set and get methods to access the private member variables.

Class Guest: An object of Generalized Class: Guest identifies/describes an actor of type Guest. The guest actor is a user of the system that is not registered with the SellSmart system but has privileges to use a subset of the total functionality offered by SellSmart. The private attributes user and type, identify this actor as a Guest. The implementation of the public methods i.e. register(), searchCar(), addToFavorites(), viewFavorites and getDetails allow the Guest user to access all the functionality of SellSmart offered to a Guest.

Class Customer: An object of Class Customer is a specialization of the general class: Guest. This Class inherits all functionality offered to a Guest in addition to the featured available to registered customers. The private attributes of the Class that identify/describe the registered customer include password (associated with login name), firstName, lastName, phone, email, lastvisit and rating. The specialized class overrides the type private attribute, which distinguishes the customer actor user from the actor Guest. The implemented public methods saveFavorites(), veiwProfile(), updateProfile() and login() help provide a complete feature set to this actor in the SellSmart system.

Class Salesman: An object of Class Salesman is a further specialization of the specialized Class: Customer. An object of Class Salesman identifies/describes the third kind of actor in the SellSmart system that helps the other two actors (i.e. Guest and User) find a desired Car by utilizing the additional privileges granted to this actor, thereby satisfying the business model as specified in the requirement specification. An object of Class Salesman inherits all functionality offered to a Guest and Customer and overrides the private type attribute to distinguish itself as an actor of type Salesman. The Salesman class also overrides the viewProfile() and updateProfile() methods to view and update the private rating attribute with the value assigned to the potential customer by the dealership.

Class WebServiceClient: An object of Class WebServiceClient is responsible to communicate with the web service of the dealership to help customers find a desired car. Class WebServiceClient is a generalized class that is responsible for communication with the WebServiceServer (mentioned below) using SOAP XML. The private attributes uri, request, response, xmlEnvelope and httpTransport along with the implementation of the public methods sendRequest() and receiveResponse() identify the object utilized by the WebServiceClient to take care of the communication process without having to consider any application specific request/response formatting. This reusable Class forms the backbone of the communication process by allowing the SellSmart client PDA application to access a webservice. The WebServiceClient Class sends and receives customer requests and responses in string form while communicating with the web service.

Class UseWebService: An object of Class UseWebService inherits all communication capabilities by extending the WebSeriveClient class. The UseWebService class implements two public methods to access the dealership web service. The methods createRequest() and parseResponse() are responsible to format application specific data i.e. request and response, in a form suitable to be transmitted over HTTP. The createRequest() methods takes the user query in the form of a Car object and invokes the communication method sendRequest() that it inherits from its parent. The createRequest() methods serializes the Car object (customer query) to be sent by packing into a SOAP XML envelope which gets transmitted over the web using the HTTP protocol.

Class PartnerDealer: An object of Class PartnerDealer helps maintain a communication session Id when customers wish to search external partner dealership inventories for their desired car. The private attributes (i.e. sessionId and who) of this class aid the Adaptor to query external systems using different technologies (i.e. DCOM, CORBA and EJB) as identifies by the value of partner dealership private member (i.e. who).

Class Adaptor: An object of Class Adaptor helps extend the customers search to external systems. The private attribute searchCriteria (an arrays of Car objects) stores the concurrent users external search requests. The private attribute where (an array of PartnerDealer objects) provides the adaptor with a sessionId and information about the underlying technology to be used by the adaptor to query the external systems. The Adaptor implements a web service that communicates with the dealership web service at one end and the external systems at the other. The Adaptor bridges the technological gaps between various external system by providing the public implementation of the searchDealer(), receiveRequest() and sendResponse(). The searchDealer() method internally calls either one of the private methods comSearch(), ejbSearch() or corbaSearch() as indicated by the who private member of the partnerDealer parameter.

Class Main: An object of class main instantiates objects of various other class (i.e. Guest, User and Salesman) based on the type private member value at the time of login. This class is also responsible for instantiating the Car class along with the UseWebService class. The Main class also marks the entry point of the SellSmart client PDA application front end.

6 External System Class Diagram

1 Class Diagram for EJB

[pic]

Class: EJBObject

The EJBObject interface is extended by all enterprise Bean’s remote interfaces.

Class: EJBHome

The EJBHome interface is extended by all enterprise Bean's home interfaces.

Class: SellSmartBean

Each enterprise bean has home and remote interfaces. SellSmartBean is the enterprise bean that has SellSmartHome as home interface and SellSmartRemote as remote interface. This bean contain methods like ejbCreate( ), ejbRemove( ), ejbActivate( ), ejbPassivate( ), setSessionContext( ) that are implemented in this interface. The method ejbCreate( ) corresponds to the create method in the SellSmartHome interface. The parameter sets of the two methods are identical. When the client calls the create( ) method of the home interface the container allocates an instance of the EJBean and calls ejbCreate( ).

Interface: SellSmartRemote

This is the remote interface of the SellSmartBean. This interface provides the client’s view of an EJBObject. All the definitions for the business methods are defined in this remote interface. The business method defined in this SellSmartRemote interface is search( ).

Interface: SellSmartHome

This is the home interface of the SellSmartBean. This interface defines methods that allow clients to Create, Find and Remove EJB objects. SellSmartHome interface must have at least one or more create( ) methods defined in it. The container tools generate the implementation of this interface.

2 Class Diagram for DCOM

[pic]

Class: JNIAccess

The abstract class includes several native methods, JVM to call JNIImpl.

Class: JNIImpl

The JNIImpl class implements the JNIAccess.

Class: COMAccess

The COMAccess class includes both COM server and the proxy client.

Interface: IUnknown

The IUnknown interface lets clients get pointers to other interfaces on a given object through the QueryInterface method, and manage the existence of the object through the IUnknown::AddRef and IUnknown::Release methods. All other COM interfaces are inherited, directly or indirectly, from IUnknown. Therefore, the three methods in IUnknown are the first entries in the VTable for every interface.

Interface: IClassFactory

The IClassFactory interface contains two methods intended to deal with an entire class of objects, and so is implemented on the class object for a specific class of objects (identified by a CLSID). The first method, CreateInstance, creates an uninitialized object of a specified CLSID, and the second, LockServer, locks the object's server in memory, allowing new objects to be created more quickly.

Interface: IexternalSearch

The IexternalSearch interface is the interface for the COMAccess.

-----------------------

Facade

SellSmart

Client

Database

SellSmart

Bean

(Session bean)

SellSmart

Remote

SellSmart

Home

SellSmart client stub

Partner Dealers Server stub in CORBA

ORB

COMAccess

Proxy

COM+

IExternalSearch

DLL

JNIImpl

JVM

JNIAccess

Database

COMAccesss

COM+

IExternalSearch

EJB

COM

CORBA

Adaptor

Web Service

PDA Client

Database

.NET

PocketSOAP.Envelope

.NET Framework

system.web.services

WebServices

PDA Client

Javax.ejb.*

Visi broker

ATL

EJB Server

CORBA Server

DCOM Server

Adaptor

java.util.*

java.io.*

Database

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download