Tài liệu CUSTOMER RELATION MANAGERMENT Software Architecture and Detailed Design docx

Shared Code and Increased Efficiency Because the .NET Compact Framework delivers the same programming model across a range ofdevices, it simplifies the process of developing an applicati

Software Architecture and Detailed Design

Project Code: CRM Document Code: CRM_ Architecture_and_Detailed_Design_v1.0

Hanoi, january 2007

Change Description New Version

SIGNATURE PAGE

ORIGINATOR:Phan Xuan Truong 04-Jan-2007

Architecture and Solution Design

REVIEWERS: Phan Xuan Truong 04-Jan-2007

TABLE OF CONTENTS

1 INTRODUCTION 7

1.1 How this document is organized 7

1.2 Purpose 7

1.3 Definitions, Acronyms and Abbreviations 7

1.4 Referenced Documents 8

2 ARCHITECTURE DESIGN 9

2.1 CRM Overview 9

2.1.1 External/Internal interfaces 9

2.1.2 Constraints and assumptions 9

2.1.3 Transaction management 10

2.1.4 Connection pooling 10

2.1.5 The NET Framework 11

2.2 CRM System Architecture 12

2.3 Module Hierarchy 17

2.3.1 CRM Modules 17

2.4 Logical View 17

2.4.1 UI Package 18

2.4.2 BO Package 18

2.4.3 DAO Package 18

2.4.4 Common Package 19

2.4.5 Controls Package 19

2.4.6 System Package 19

2.5 Deployment 19

2.5.1 CRM Side 19

2.5.2 Other Sides 19

2.6 Hardware and Software requirement 19

2.6.1 Handheld Device 19

2.6.2 Software 20

3 DETAILED DESIGN 20

3.1 Detailed Design Methodology 20

3.2 Detailed Design Overview 20

3.3 Use Cases View 22

3.4 Packages 22

3.4.1 DAO Package 22

3.4.2 Business Object Package 24

3.4.3 UI Package 25

3.4.4 Common Package 26

3.4.5 Controls Package 27

3.4.6 System Package 28

3.5 Exception Handling and Logging 28

3.5.1 Exception Handling 28

3.5.2 Logger 29

3.6 Diagrams 30

3.6.1 Logon 30

3.6.2 Route Management 31

3.6.3 Download 33

3.6.4 Import Data 35

3.6.5 Totals 36

3.6.6 Setup 37

3.6.7 Beginning of Day 39

3.6.8 Loads 41

3.6.9 Sales 44

3.7 Database 47

3.7.1 Relationship Diagram 47

3.7.2 CommProfiles table 47

3.7.3 Routes table 47

3.7.4 AppSettings table 48

3.7.5 SecurityCodes table 49

3.7.6 Loads table 50

3.7.7 LoadDetails table 50

3.7.8 LiquorLicenses table 51

3.7.9 Messages table 51

3.7.10 Customers table 51

3.7.11 Surveys table 52

3.7.12 LookUp table 52

3.7.13 Vending table 52

3.7.14 DailyInfo table 52

3.7.15 Products table 53

3.7.16 Expenses table 53

3.7.17 RouteStop table 53

3.7.18 Orders table 54

1 INTRODUCTION

1.1 How this document is organized

Here are brief summaries for the parts of this document:

Part 1: Introduction to the document, purpose, definitions and references

Part 2: Architecture Design

Part 3: Detailed Design

1.2 Purpose

Architecture Design:

Purpose of this document is to provide an architectural overview of CRM system Through thisdocument, project team and IT Department can have an overview and understand the wholesystem They can know how CRM system will be developed and which systems CRM will have tointegrate with

This document also describes all constraints that the design of the system must follow to meetthe business and maintenance requirements

Detailed Design

This document aims at to describe the details of Classes of CRM application By studying thisdocument, project team, developers and related groups can have an overview of the internal ofCRM application and they can have more information to implement CRM application

1.3 Definitions, Acronyms and Abbreviations

SRS Software Requirement Specification

1.4 Referenced Documents

CRM-SRS-v1.0.doc Functional Specification of CRM application

CRM Server System

CRM Application

Figure 1 External/Internal interfaces of ROUTEPAD-PDA system

Component Interface type Connection type

PDA < -> FTP Server Data will be download and upload

via FTP

Network FTP PDA -> Printer Data will be print out on paper Infra, Bluetooth, Serial port

2.1.2 Constraints and assumptions

There are some key requirements and system constraints that have a significant bearing on thearchitecture They are:

1 The server-side system: server will be enabled FTP Server

2 CRM machine: Window Server 2003,XP OS and MS NET Framework 1.1

3 Database of CRM is SQL Server 2000 Service Pack 3

4 Local CRM will be authenticated against the locally stored security code The locallysecurity code must be securely stored and should be accessible to users and must not store

in clear text

5 Sensitive data held on the CRM must be held in such a manner to ensure that the data

is not accessible before a CRM has been successfully authenticated

6 If we need to scale beyond the target number of CRMs it should be capable of beingscaled by the introduction of further CRM proxy processes and possibly further proxymachines without requiring code changes to any component

7 The code dealing with the interaction with user input / output to-and-from the CRMshould be abstracted to allow for the future upgrade to later version of the CRM operatingsystem and replacement of the CRM hardware

2.1.3 Transaction management

The ROUTEPAD-PDA is developed using NET Framework, so we will use manual transactionprovided by ADO.NET There isn’t complex calculation in Pocket Routepad system so that wedon’t use COM+ as business layer

ADO.NET provides a powerful manual transaction management mechanism You have to write

some code to control the how the transaction should perform That means with ADO.NET you

have a flexible way to manage transaction processing Transaction object can be passed (by

reference) between method calls to build up a complex process in one transaction However, it’srather complicated to setup a model that is easy for maintenance Distributed transaction is also

not supported by ADO.NET.

Logging processing can be embedded into source code quite easily The .NET Frameworkincludes classes and data types that make it easy to log trace messages You can evenimplement your own trace listener

Controlling a transaction through ADO.NET objects results in less efficient locking in comparison

to using explicit transactions in stored procedures The reason is that an ADO.NET manualtransaction takes at least as many round trips to the DBMS as there are operations to executewithin the transaction in addition to trips that begin and end the transaction

2.1.4 Connection pooling

Database connection pooling enables an application to reuse an existing connection from a pool,instead of repeatedly establishing a new connection with the database This technique cansignificantly increase the scalability of an application, because a limited number of databaseconnections can service a much larger number of clients This technique also improvesperformance, because the significant time which is required to establish a new connection could

be avoided

In the DPA system, we will use ADO.NET connection pooling mechanism We don’t need to spendeffort for this module but still have effective features

By default and implicitly ADO.NET supports connection pooling mechanism You can configure

minimum and maximum value of your connections to be pooled just by defining some attributes

in the connection string ADO.NET doesn't throw sqlCeConnection objects away when the

Close or Dispose methods are called Instead, it returns them to the connection pool If a futurerequest for a sqlCeConnection can be satisfied by a pooled connection, ADO.NET recycles thatconnection instead of opening a new one ADO.NET also allows you to control the connectionpool simply by adding values to the connection string

2.1.5 The NET Framework

Developers can reuse their knowledge about .Net technology With code written in .Net,developers can reuse code and easy to maintain the system

Shared Code and Increased Efficiency

Because the NET Compact Framework delivers the same programming model across a range ofdevices, it simplifies the process of developing an application that will run on multiple devices.Much of the core code for an application, such as the business logic, data access layer, can beshared across multiple devices and the desktop This greatly increases the efficiency of

application development.

Easy to reuse code

It is important to note that the NET Framework does not take the lowest-common denominatorapproach used by other device programming platforms Developers can get broad portability andreusability by writing to the common programming model, but the NET Framework is alsodesigned to be extended with class libraries that expose features unique to a family of devices, oreven unique to a particular device model This approach allows developers to create the bestpossible application experience on each specific device, while reusing skills and code

Enterprise-Class Features for More Capable Devices

The success of Microsoft Pocket PC devices is growing, in part, because they have the computingresources necessary to handle sophisticated business applications The NET Compact Frameworktakes advantage of the Pocket PC platform by providing enhanced frameworks that greatlysimplify the process of developing enterprise applications on Pocket PC devices

Robust Code, Secure Execution

The NET Compact Framework offers a robust and secure environment for running client-sidecode The managed code model supported by the .NET Compact Framework increases thereliability of code, thus reducing software defects The managed code execution engine ensuresthat an ill-behaved application will not be able to "crash" the device At the same time, theevidence-based security model built into the NET Compact Framework ensures that maliciouscode will not be allowed to gain access to secure system resources The security model alsoenables software updates to be delivered over the wireless network in a secure way, decreasingthe possibility of a costly device recall

Great Offline Application Support

With secure client-side code, the NET Compact Framework enables responsive applications thatcan be used offline This allows a smooth execution despite any intermittent connectivityproblems that might occur when accessing the network The developer can choose the right mix

of client-side and server-side programming to deliver a rich and always interactive application

Reduced Cost of Development Creates New Opportunities

This new ease of development provided by the NET Compact Framework will lead to the creation

of a broad new range of applications and services that will help manufacturers win greatermarket acceptance for their mobile devices and create new opportunities for developers Manybusinesses that were unable to afford the cost or special developer training necessary for mobile

development will be able to develop new mobile applications much more efficiently, which in turncan help lower their costs of doing business, and increase their market opportunities.

2.2 CRM System Architecture

The architecture of CRM system will be designed to illustrate:

- Transaction Data exchange between Insight host system and CRM machine

- Architecture in CRM machine

From above information and flow constraints:

- CRM client program is built upon NET Framework 1.1

- The communication via network FTP

- Transaction management mechanism is ADO.NET

We provide the architecture of CRM system as follow:

Figure 2 CRM system architecture

Presentation layer:

Purpose of this layer is for user-interaction In CRM system, Windows-based GUI application will

be used for most business processes Built upon System.Windows.Form package from NET

Framework, the interface is used for inputting complex data and displaying complex views This

layer will be containing some business actions that manual data in local database

Business layer:

The Business layer manages all internal business logic It will receive data\request fromPresentation, process necessary business logic, access or update data from\to local DB on CRMApplication

Data layer:

This layer includes storage database, data access components and data conversion sub system

- Data access component: ADO.NET (CRUD Methods – Create – Read – Update – Deleteand orther methods) – Data access logic components retrieve data from database andsave entity data back to the database.Data Access Logic Components also contain anybusiness logic needed to achieve data – related operations

- Business Entities components: Data is used to represent real world business entities,such as products or order.there are numerous ways to represent these businessentities in your application – for example , XML or DataSets or custom object –oriented classes – depending on the physical and logical design constraints of theapplication

CRM Business Process Layer

CRM Data Access Logic

Component CRMWebAdmin

OS, Hardware driver, Network interface

Services

Figure 3 CRM MVC model

Figure 4 CRM System Logical Architeture

The CRM System was built exactly to resolve problem dispersion of Business unit,Howeverdatabase Store require common managerment.For this reason,we have been combined CRMArchiteture Application and XML Web Service base on .NET Framework follow Multi tierArchiteture and MVC model is sensible

This Model is principle for CRM System.follow this Model:

 Application will resolve business functions,user methods with unique

presentation,application cover work under structure with user

 XML Web Service,supply Serviceses message- based that be called by Application through Business Layers tier of Application

CRM System has been built combine of Application components :

Figure 5 CRM Components Model

 CRM clients Application(Windows forms) : supply Customer Relation Managerment and Business managerment tools,WareHouse for Enterprise

 CRM Admin Application(ASP.NET Forms):supply Administrator tools and synthetize data business Process of Enterprise

 CRM XML Web Service :supply Services about synchronous data,manipulate so far with data center

described in Detailed Design session.

Figure 6 CRM Logical Package

2.4.1 UI Package

This package contains all business object classes which encapsulate business logic of theapplication They will receive requests from Presentation layer, process business logic and callDAO layer to update/retrieve data to/from CRM Database

2.4.2 BO Package

This package contains all business object classes which encapsulate business logic of theapplication They will receive requests from Presentation layer, process business logic and callDAO layer to update/retrieve data to/from CRM Database

This package contains objects used for logging purpose and objects to download/upload files

We will use Log4Net to log necessary information for later tracking This library is open source,run very fast and reliable

2.5 Deployment

2.5.1 CRM Side

Packages to be deployed on handheld device:

PC CRM Application CRM application running on PC

CPU Intel Pentium IV

3.1 Detailed Design Methodology

In this detailed design document, UML is used as main methodology to illustrate the structure ofROUTEPAD-PDA application Diagrams in this document are created in Visual Studio.NET 2005,Microsoft Visio 2003, and Rational Rose

3.2 Detailed Design Overview

Figure 7 ROUTEPAD-PDA Architecture Overview

As described in Figure 4, PDA application will have three layers- Presentation Layer, BusinessLayer, Data Access Layer and Value Objects Common package

 Presentation Layer contains User Graphical Components, UI Process Components (Form Package)

o User Graphical Components and UI Process Components build screens to interact with users They show the information to the user or capture data oractions from the user to call business layer in order to update into database

 Business Layers contains all Business Object classes that will encapsulate business logic of the application They will receive requests from Presentation layer, process business logic and call DAO layer to update/retrieve data to/from PDA Database

 Data Access layer contains classes which will be used for manipulating data on PDA machine and synchronize data between insight host and PDA Database

SQL Mobile 2005 Edition ROUTEPAD-DB

SQL Mobile NET Data Provider

Presentation Layer

Business Layer

Data Access Layer

Data Layer

UI Components

UI Process Components

Business Workflows ComponentsBusiness Business Entities

Data Access Logics Components

Insight Server

PDA

Network FTP FTP

FTP

 Value Objects classes are used to contain data for transferring between internal Modules/Layers in PDA application.

3.3 Use Cases View

Figure 8 ROUTEPAD-PDA Use Cases View

3.4 Packages

3.4.1 DAO Package

The base class of DAO package implements common methods to manipulate database Derivedclasses can override those methods if necessary Below is the specification of DAO base class:

Figure 9 DAO Class Diagram

No Member Name class to implement Require derived Description

Below is description of all classes in DAO package

No Class Name Description

1 CommProfileDAO

Encapsulates methods to interact with CommProfiles datatable

4 AppSettingsDAO Encapsulates methods to interact with AppSettings datatable

5 LiquorLicenseDAO Encapsulates methods to interact with LiquorLicenses datatable

6 SecurityCodeDAO Encapsulates methods to interact with SecurityCodes datatable

8 CustomerDAO Encapsulates methods to interact with Customers data

12 DailyInfoDAO Encapsulates methods to interact with DailyInfo data table

13 ProductDAO Encapsulates methods to interact with Products data table

15 RouteStopDAO Encapsulates methods to interact with RouteStop datatable

3.4.2 Business Object Package

The following figure describes the class diagram of Business Objects package

Figure 10 Business Layer Class Diagram

No Member Name class to implement Require derived Description

Below is description of Business Objects

No Class Name Description

1 CommProfileBO Encapsulates business logic related to communicationprofile

4 AppSettingsBO Encapsulates business logic related to application settings

5 LiquorLicenseBO Encapsulates business logic related to liquor license

6 SecurityCodeBO Encapsulates business logic related to security code

12 DailyInfoBO Encapsulates business logic relates to daily information

15 RouteStopBO Encapsulates business logic relates to route stop

3.4.3 UI Package

The following figure describes the class diagram of UI package

Figure 11 Presentation Class Diagram

No Member Name class to implement Require derived Description

1 previousForm Stores the form which calls this form

3.4.4 Common Package

Each class in this package, except base class, contains appropriate properties to represent the

corresponding data table Below is the specification of common base class:

Figure 12 Common Class Diagram

No Member Name class to implement Require derived Description

Here is the list of classes derived from base class:

No Class Name Description

5 LiquorLicenseVO Represents a record of LiquorLicense data table

6 SecurityCodeVO Represents a record of SecurityCodes data table.

3 RPADButton Can display text on the left, right and center position

6 RPADTextBox Can display a currency symbol at the beginning of the text

3.4.6 System Package

Refer to Error Handling and Logging