SellSmart© Project ProposalSeptember 27, 2003
CS551 Advanced Software Engineering
SellSmart©
Project Proposal
September 27, 2003
by
DesiGeeks
Vinit Nagda ()
Deepa Colluru ()
Uday Kapoor ()
Venetia Raheja ()
Sampath Akkineni ()
Vijay Bhaskar Puram ()
Wenxuan Kang ()
School of Computing & Engineering
University of Missouri Kansas City
Table Of Contents
1Introduction
1.1Purpose of this document
1.2Scope of this document
1.3Brief Overview
1.4Business Context
2Project Goal and Objectives
2.1Overall Goal
2.2Specific Objective
2.3Significance
3PROJECT BACKGROUND
3.1Work Done By Others (Critiques)
3.1.1Component Technologies: Java Beans, COM, CORBA, RMI, EJB and the CORBA Component Model
3.1.2Mobile Computing in the retail Arena
3.1.3Designing Interfaces for Handheld Computers
3.1.4Java Native Interface: Technology Programming
3.1.5Use of a CORBA/RMI Gateway: Characterization of Communication Overhead
3.1.6Web Services: An Architectural Overview
3.1.7A Detailed Comparison of CORBA, DCOM and Java/RMI
3.1.8PDA Car Lot [2]
3.1.9Car Buyer Calculator 1.0
3.1.10Pocket Verifier- Windows CE 3.12
3.1.11Starcloser
3.1.12Stronghold
3.1.13CarSmart
4General plan OF WORK
4.1Proposed Solution
4.2Methods & Procedures
4.2.1Display()
4.2.2Login/Authentication
4.2.3Browse inventory
4.2.4Search the inventory
4.2.5Find Availability
4.2.6DbConnect()
4.2.7InitSQL()
4.2.8ProcessResults()
5Proposed System
5.1Domain Analysis
5.2Requirements
5.2.1Display Welcome Screen
5.2.2Registration and Authentication
5.2.3Search Screen
5.2.4Search Results Screen
5.2.5Favorites List
5.2.6Sales Agents Reqs
5.2.7Information From Other Dealers
5.2.8Concurrent use
5.2.9Portability
5.2.10Reliability/Accuracy
5.2.11Performance/SLA
5.3Business Model
5.4Stakeholders
5.5Proposed System Architecture
6Timetable
7Bibilography
1Introduction
1.1Purpose of this document
This document is intended for the use by the business analysts to examine basic functionality and also provides a brief overview of the product details. The document compares the product “SellSmart” with similar products available in the market and provides a comparison between them. The document describes the objective behind developing the product. The plan of work that would comprise of descriptions of the methods and procedures along with the expected results is also provided. The document analyses the requirements, business model and interest of the stakeholders.
1.2Scope of this document
The document provides detailed requirements, which would be used to develop the product. The developers would analyze the requirements and bring to the knowledge of the project requestor any conflicting requirements that cannot be met.
1.3Brief Overview
SellSmart is a software system that provides the car dealers and customers the benefits of a handheld device to access car details while shopping at the car lot. Customers could browse through the online information database and search for the cars they have in mind by using various search criteria such as the Make, Model and Price etc. Car salesmen, on the other hand have access to the above-mentioned data as well as critical and confidential information. The system also provides the customer and salesman the ability to search for a car beyond the confines of the dealership.
1.4Business Context
SellSmart would aid in the sales effort of the dealership to maximize sales while reducing the required manpower. Millions of car shoppers do not buy cars online because automakers are misfiring with their marketing efforts [1]. SellSmart offers the customers to search the dealers inventory using many offered search criteria with the added advantage of viewing, test driving, comparing various available options in the car lot.
2Project Goal and Objectives
2.1Overall Goal
The overall purpose of SellSmart is to redefine car sales by automating the entire process beginning from selection to negotiation and ending in a successful deal. SellSmart enhances the customer car shopping experience by keeping a constant focus on the customer’s requirements and satisfaction. Highlights of SellSmart are:
Customers can search for the car they have in mind using various criteria and start their short-listing process by viewing the exact cars and what they have to offer as specified by the search results.
Sales representatives would not require subsequent trips to their office to fetch details pertaining to each customer query.
Customers can maintain a profile in which they could shortlist cars they are interested in.
Sales people could take additional notes regarding a prospective customers contact information which will come in handy during follow up sales calls.
SellSmart helps save customers their precious time by avoiding to wait for a sales representative to help them, instead they could help themselves using the PDA client application.
The dealership could guarantee customer satisfaction by diverting their queries to partner dealerships if the customer requests cannot be satisfied by them.
2.2Specific Objective
The dealership would like to be a channel partner and become point of contact to sell cars available in the partner’s car lot. A major challenge to be overcome is to bridge the gap between various technologies used by different partner dealerships and provide a single point of access to the end consumer. To overcome the above-mentioned obstacle, SellSmart proposes the development of an “Adaptation Layer” which communicates with various technologies at the backend and presents the front end with a consistent user interface.
The dealership does not intend to limit its partnerships to select few dealerships but instead requires that the solution be flexible and scalable to add and remove partner links as required. One of the ways the requirement can be satisfied is to provide a web-service to provide a unified method to access information available in their own database along with information obtained via the adaptation layer. SellSmart would provide such a web-service to access information from the PDA client application. The utilization of the web-service could be increased by developing a web portal to access the same information using a web browser. The mentioned web portal is beyond the scope of this project and could be considered as a future enhancement.
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 would develop a PDA client using Microsoft Mobile .Net framework. 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.3Significance
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. 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.
3PROJECT BACKGROUND
3.1Work Done By Others (Critiques)
In this section, we present an analysis of our research on products parallel to SellSmart. (Our Competitors!!!)
3.1.1Component Technologies: Java Beans, COM, CORBA, RMI, EJB and the CORBA Component Model
This paper describes the evolution of object oriented programming into local component models such as Java Beans and distributed object technologies such as CORBA, RMI and COM. Existing component-based and distributed technologies are classified into three categories, local component technology, distributed object technology and distributed component technology. In local component technology, all components reside on the same host at execution time. Examples of the local component technologies are Sun’s Java Beans and Microsoft’s COM. Bean components communicate by sending events to one another using a publish/subscribe model. In distributed object technology, communication between objects occurs by method invocations. Application developers do not have to deal with complexities such as location of objects and heterogeneous hardware/software platforms. Middleware technologies also offer other services such as security, persistence, naming and trading. Distributed component models evolved from the deficiencies existed in different middleware technologies. These technologies combine the characteristics of components with the functionality of middleware systems to provide inter-process communication between components. Two distributed component models that are available now are Sun’s Enterprise Java Beans (EJB) and CORBA component model. These are server-side component models used for developing distributed business objects.
3.1.2Mobile Computing in the retail Arena
With the rapid rate at which wireless technology is improving, more PDA’s and handheld computers are becoming a part of every day life. The authors at Georgia Institute of technology conducted a study on how the use of a PDA aids our grocery shopping. They observed the shopping habits of several people and designed an application that would help them grocery shop from the “shopping” perspective, leaving aside the shopping environment. A noteworthy observation was made that shoppers want more information, control and convenience. The designed application provided people with an option to create a shopping list. The in-store information system could even analyze the shopping habits of a customer and present a shopping list based on buying frequency. Specialemphasis was maintained while designing the user interface, which was incorporated with the store map and provided shopperswith anicon, marking the location of items on the list. The prototype was developed for the MS Pocket PC platform. User comments about the applications formed a mixed bag, people familiar with PDA usage found the application made their shopping experience better. On the other hand, people not familiar with PDA usage and interface found the application limiting. More of such applications will become available as people become more familiar with PDA usage day by day.
3.1.3Designing Interfaces for Handheld Computers
This paper discusses guidelines for designing effective Handheld Application Interfaces. It tries to explain the point that developers should not use desktop metaphors in their designs while designing a user interface for handhelds. It provides very good insights into designing screens and dialog boxes, designing for speed, employing benchmarks and also overall application design.
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 fresh design are absence of keyboard, use of finger or stylus, limited user screen, and many more. The author suggests careful placement of controls on screen, using progressive disclosure, large buttons over which stylus can be used, and consistency with platform of choice. Also considering factors like integration with desktop computer; design for speed, decreasing the overall navigation in application, and very less reliability on always being connected.
We found the article extremely useful, all of us being novice handheld application developers.
3.1.4Java Native Interface: Technology Programming
Computer languages are created, reformed, and die at a rapid pace with the evolution of computer engineering. This cycle presents problems throughout any system’s life cycle as the system’s core technologies become dated and new technologies arise that could streamline operations. While the new technologies often provide benefits, these benefits rarely justify rewriting entire libraries of code. Another problem with this cycle is that in any given environment (office, lab, building, etc.), a number of systems may exist all written in different languages that reflected the height of technology at its birth. Integrating these systems then becomes a large chore.
The JNI presented here provides solutions to both of the above problems: by allowing access to any native language the JNI allows Java to access any legacy code library or system directly, cutting out the need to string objects between the two. It also allows for the consolidation of any number of differently programmed systems into one unified architecture because once JNI extracts the classes from the native language it can use the core Java principles of inheritance to cast these native objects to well defined Java objects.
We were facing a technical problem during designing the SellSmart system, how to call COM from Java. From this paper we got a solution, using JNI as the bridge to connect COM and Java code. Is it the only way to do this? Need more effort to know.
3.1.5Use of a CORBA/RMI Gateway: Characterization of Communication Overhead
The paper discusses about the gateway module, which acts as a link between two different communication frameworks. The gateway passes service requests between different middle ware solutions. In this paper CORBA AND RMI are taken as the middle ware solutions. The problems involved and the counter measures that are to be taken for the improved performance are briefly explained.
Integration of number of service components in a web service system is based on keeping the same transport framework and adding to that number of service components. The gateway module described allows these service components on different frameworks to access each other. The problem involved is quick response which is measured by considering Round Trip Time and generating various graphs. Solution proposed to the above problem is aptly placing the gateway in the client side or server side. We can use this concept of integrating different communication frame works in the adapter layer of our project.
3.1.6Web Services: An Architectural Overview
Web services represent an architectural structure that allows communication between applications. A service can be invoked remotely or be used to employ a new service together with other services. The standard technologies for web services are Web Service Description Language (WSDL), Simple Object Access Protocol (SOAP) and Universal Description, Discovery and Integration (UDDI). The choice of web services is made because it is platform independent. A web service component is described in service description language, published in a registry and discovered by a standard mechanism. Web services contain the best accomplishments of web-based component development. Web services contain black-box functionalities that can be reused without caring in what language it will be used in.
3.1.7A Detailed Comparison of CORBA, DCOM and Java/RMI
Three of the most popular distributed object paradigms are Microsoft’s Distributed Component Object Model (DCOM), OMG’s Common Object Request Broker Architecture (CORBA) and Javasoft’s Remote Method Invocation (RMI). This article describes the three different technologies and provides a comparison from a programmer’s standpoint and an architectural standpoint.
The following are the similarities/differences between the three different technologies. DCOM supports multiple interfaces whereas CORBA and RMI support multiple inheritance at interface level. In DCOM, every object implements IUnknown, in CORBA every interface inherits from CORBA.Object and in RMI every server object implements java.rmi.Remote, java.rmi.UnicastRemoteObject. DCOM uniquely identifies a remote server object through its interface pointer, CORBA identifies remote server objects through object references and RMI identifies remote server objects using object id. DCOM uniquely identifies an interface using interface ids and uniquely identifies a named implementation of the server object using class ids. Interface id and class id mapping is found in the registry. CORBA identifies interface using interface name and identifies a named implementation of server object by mapping in the implementation repository. RMI identifies interface using interface name and identifies named implementation of server object by its mapping to a URL in the registry. In DCOM, the object exporter performs remote server object reference generation. CORBA performs remote server object reference generation with the object adapter. In RMI, remote server object reference generation is performed by the call to the method UnicastRemoteObject.exportObject(this). Author has done a great job by providing a detail description of the similarities and differences that are beyond the scope of this project proposal.
3.1.8PDA Car Lot [2]
The PDA Car Lot tool developed by Palmtree.ca assists auto sales. The program has customizable drop lists for fields such as vehicle make, model color and others. The database can be filtered to show data specified. Many filter/search capabilities are available. It will keep track of the inventory and will also log your potential clients and their information. The product does not give the location of cars and only gives the details of the car available with the dealer and does not fetch information from the web. Moreover it is a tool for salespersons, not for the customers.