Luận văn Tìm hiểu và ứng dụng xml web service trong công nghệ thông tin

B2B têu biểu như thế nào? 2.5.4.1 Quản lý giao tác phân tán Web Service quản lý các điều khiển giao tác phân tán rất chặt chẽ ngay cả đối với các hệ thống và ứng dụng riêng rẽ trong hệ thống kinh doanh. Giao tác B2B có thể được truyền khắp các hệ thống và ứng dụng riêng rẽ qua các hệ thống kinh doanh khác nhau nên đôi khi làm chúng trở nên khó khăn hơn cho việc quản lý và kiểm soát. Trong trạng thái hiện hành, Web Service không là giao tác mặc nhiên và nó cung cấp chức năng”yêu cầu/trả lời”_request/reponse cơ bản . 2.5.4.2 Vấn đề bảo mật B2Bi yêu cầu hai mức độ bảo mật. Đầu tiên, B2Bi cần mở ra bức tường lửa _firewall để truyền thông giữa các hệ thống kinh doanh. Vì vậy, cho dù bất kỳ chế độ tích hợp nào được dùng thì các công ty phải bảo mật an toàn hệ thống mạng bên trong của họ nhằm tránh các cuộc tấn công phá hoại thông qua các cổng mở này. Bên cạnh đó, dữ liệu truyền đi thông qua đường truyền thuê chuyên dụng, như EDI, Internet, hoặc bất kỳ chế đệ nào cũng phải được bảo mật. Dữ liệu có thể chứa nhiều loại thông tin như thông tin tổ chức, thông tin giao tác nghiệp vụ do đó phải luôn được bảo mật. Trong trạng thái hiện hành, Web service thiếu các đặc tính hỗ trợ cho bảo mật. Vì vậy, Web Service dựa trên kiến trúc B2Bi tiềm ẩn vấn đề lớn về lỗ hỏng bảo mật. 2.4.2.3 Tính năng động và linh hoạt Để các công ty tham gia các nghiệp vụ năng động thật sự với các công ty khác,thì sự tích hợp giữa các hệ thống của hai công ty phải thực thi trong thời gian thực. Hơn nữa, sự tích hợp này chỉ hiện thực được khi B2Bi được thực thi bởi các chuẩn mở thông qua Internet. Web Service cung cấp cách thức linh hoạt phục vụ cho tích hợp bằng cách đưa ra giao diện năng động. Web Service được xây dựng dựa trên chuẩn mở như UDDI, SOAP và HTTP_đây là một nhân tố quan trọng nhất dẫn đến sự chấp nhận rộng rãi của Web Service đối với công nghệ B2Bi. 2.4.5.4 Chế độ tích hợp Chế độ tích hợp là yếu tố quan trọng nhất của công nghệ B2Bi. Có phải B2Bi là dữ liệu hướng đối tượng, xử lý nghiệp vụ hướng đối tượng, ứng dụng hướng đối tượng, hàm chức năng hướng đối tượng ? Câu trả lời cho câu hỏi này xác định rất nhiều đáp án bao gồm cách thức và công nghệ dùng cho B2Bi. Điển hình trong công nghệ tích hợp B2B, các công ty quyết định dựa trên cơ sở công nghệ dùng được trong hãng, ngân sách và mức độ của nhu cầu đồng bộ hóa để hỗ trợ các hàm nghiệp vụ chức năng. Trong thế hệ Web Service này, nó có thể đạt được mức chức năng là tích hợp giữa các ứng dụng.Tuy nhiên, thế hệ kế tiếp của Web service sẽ được nâng cấp về chức năng và kỹ thuật nhằm cung cấp sự đóng gói giao diện người dùng và bảo mật an tòan.Và chúng có khả năng đóng gói một ứng dụng và nhúng nó vào ứng dụng khác. Ví dụ về Web Service cho công nghệ B2Bi Biểu đồ dưới đây đưa ra một minh họa cho việc dùng Web Service trong trường hợp B2Bi. Trong ví dụ này, ứng dụng dùng chung có được của tổ chức thực thi trong ứng dụng máy chủ yêu cầu đặt giá từ nhiều nhà cung cấp. Ứng dụng đang có của người mua lấy thông tin về Web Service mà các nhà cung cấp đưa ra bằng cách đăng ký UDDI và gọi những dịch vụ này thông qua Internet để nhận thông tin về giá cả cho từng mặt hàng riêng biệt. Các bước tuần tự đó như sau: Ứng dụng sẵn có của người mua thực thi bên trong ứng dụng server phải tảo ra hóa đơn mua mặt hàng chỉ định. Ứng dụng đó lấy thông tin về Web Service của các nhà cung cấp khác nhau cho mặt hàng này bằng cách tìm kiếm trong mục đăng ký UDDI. Địa chỉ và WSDL xác nhận thông tin Web Service được gửi đến ứng dụng. Ứng dụng lấy thông tin Web Service mà nhà cung cấp xuất ra để lấy thông tin giá cả cho mặt hàng đó. Sự truyền thông dựa trên thông điệp SOAP qua Internet. Ứng dụng nhận được thông tin giá cả từ các nhà cung cấp khác nhau. Sự truyền thông dựa trên thông điệp SOAP qua Internet. Sau đó, thông tin này được phân tích và điều khiển để tạo ra hóa đơn bán hàng. Tóm lại, Web Service có tiềm năng cho việc định nghĩa lại mô hình của B2B bởi tính năng động, dễ thực thi ở dạng từng phần riêng biệt và chi phí vận hành lại thấp. Tuy nhiên, ứng dụng của Web Service cho công nghệ B2Bi sẽ bị giới hạn nếu dịch vụ về xác nhận bảng quyền, mã hóa, điều khiển truy cập và tích hợp dữ liệu không hịêu lực. Web Service đóng vai trò trung gian nhằm cung cấp các dịch vụ như thông tin đang ký UDDI, dịch vụ bảo mật, chất lượng an tòan của Web Service, kiểm tra việc thực thi chiếm vị trí quan trọng trong công nghệ B2Bi. CHƯƠNG 3 NÊU CÁC GIẢI PHÁP VÀ CHỌN LỰA GIẢI PHÁP Hiện nay, công nghệ phần mềm thành phần đã trở nên phổ biến. Phần lớn các ứng dụng được xây dựng ngày nay điều bao gồm sự tác động của các thành phần từ những nhà cung cấp khác nhau ở vài hình thức. Và vì các ứng dụng phát triển ngày càng phức tạp nên nhu cầu sử dụng các thành phần phân tán truy cập từ xa cũng ngày càng tăng. Một ví dụ điển hình của ứng dụng công nghệ thành phần là giải pháp thương mại điện tử toàn qui trình. Giải pháp thương mại điện tử trên các Web có nhu cầu xử lý hóa đơn ở chương trình của ứng dụng kế hoạch tài nguyên doanh nghiệp( ERP). Trong nhiều trường hợp, ứng dụng ERP tập trung ở những phần cứng khác nhau và thực thi trên những hệ điều hành khác nhau. Mô hình đối tượng thành phần phân tán (DCOM) của Microsoft_một cấu trúc cơ sở của đối tượng phân tán cho phép ứng dụng dùng các thành phần mô hình hướng đối tượng được cài đặt ở máy chủ (server) khác mà được chuyển lên một số nền không phải Windows(non-Windows platform). Nhưng DCOM không bao giờ đạt được sự chấp nhận rộng rãi của các nền này, vì thế DCOM hiếm khi được sử dụng để truyền thông giữa các máy tính thuộc Windows và không thuộc Windows. Các nhà cung cấp phần mềm ERP thường tạo ra các thành phần cho nền Windows truyền thông với hệ thống xử lý đầu cuối thông qua giao thức riêng. Một số dịch vụ được dùng bởi ứng dụng thương mại điện tử có thể không lưu trữ ở trung tâm dữ liệu. Chẳng hạn, nếu ứng dụng thương mại điện tử chấp nhận thanh toán bằng thẻ của khách hàng khi mua sản phẩm thì nó phải gọi dịch vụ của ngân hàng thương mại để xử lý thông tin thẻ thanh toán của khách hàng. Nhằm phục vụ cho mục đích trên, DCOM và các công nghệ liên quan như cấu trúc trung gian yêu cầu đối tượng chung (CORBA), phương thức gọi hàm từ xa của Java (Java RMI) bị giới hạn bởi các ứng dụng và thành phần được cài đặt bên trong tổ chức của trung tâm dữ liệu. Hai nguyên nhân chính là do mặc định các công nghệ này tác động đến giao thức riêng và các giao thức này vốn đã kết nối hướng đối tượng. Các máy khách (client) truyền thông với máy chủ thông qua Internet đối mặt với nhiều sự ngăn cách tiềm ẩn để kết nối đến máy chủ. Các nhà quản trị về bảo mật mạng trên thế giới cài đặt những bộ định tuyến và bức tường lửa để ngăn cản hữu hiệu mọi kiểu truyền thông qua Internet. Thật may mắn nếu nhà quản trị mạng mở các cổng truyền phù hợp để hỗ trợ dịch vụ, cơ hội cho các máy khách là rất ít. Điều đó dẫn đến kết quả: Các giao thức riêng được dùng bởi DCOM, CORBA, Java RMI không dành cho Internet trong tương lai. Vấn đề khác nữa là với những công nghệ này vốn đã kết nối hướng đối tượng, hơn nữa không thể điều khiển được sự ngắt mạng. Vì Internet không điều khiển trực tiếp được nên ta không thể giả định về chất lượng và tính đáng tin cậy của việc kết nối. Nếu việc ngắt mạng xảy ra thì lời gọi kế tiếp của máy khách đến máy chủ sẽ bị không thực thi. Kết nối hướng đối tượng cũng đặt ra thử thách đối với các công nghệ này khi xây dựng cở sở cân bằng tải (load-balanced) cần thiết để đạt sự hiệu chỉnh tốt nhất. Bởi vì sự kết nối giữa máy khách và máy chủ rất khó khăn nên ta không thể định tuyến yêu cầu kế tiếp đến máy chủ khác mộ cách dễ dàng. Các nhà phát triển đã cố gắng khắc phục sự giới hạn này bằng cách dùng một mô hình gọi là mô hình lập trình không trạng thái, nhưng họ có sự thành công bị giới hạn bởi những công nghệ này thật sự khó khăn và tốn nhiều chi phí để thiết lập lại kết nối với đối tượng từ xa. Vì việc xử lý thẻ thanh toán của khách hàng được hoàn thành bởi máy chủ trên Internet nên DCOM không lý tưởng cho đặc tính truyền thông giữa máy khách thương mại điện tử và máy chủ xử lý thẻ thanh toán. Trong giải pháp ERP, thành phần ở lớp thứ ba (third-party) thường được cài đặt bên trong trung tâm dữ liệu của máy khách (trong trường hợp này là nhà cung cấp giải pháp xử lý thẻ thanh toán). Thành phần này phục vụ tốt hơn proxy truyền thông giữa phần mềm thương mại điện tử và ngân hàng thương mại thông qua giao thức riêng. Vì sự giới hạn của các công nghệ hiện tại trong việc truyền thông giữa các hệ thống máy tính nên các nhà cung cấp phần mềm thường tím phương cách để xây dựng cơ sở hạ tầng của riêng họ. Điều này có nghĩa là nguồn tài nguyên được dùng để tăng các hàm chức năng cho hệ thống ERP hoặc hệ thống xử lý thẻ thanh toán thay vì dành cho việc tạo ra các giao thức mạng riêng. Trong nổ lực nhằm hỗ trợ tốt hơn cho Intrenet tương lai, Microsoft đã khởi đầu chấp nhận chiến lược thêm vào yếu tố mới cho công nghệ hiện tại bao gồm CIS cho phép thiết lập kết nối DCOM giữa máy khách và thành phần từ xa thông qua cổng 80. Nhưng vì nhiều lý do khác nhau, CIS đã không được chấp nhận rộng rãi. Và một cách tiếp cận mới là nhu cầu tất yếu. Vì thế, Microsoft quyết định xem xét vấn đề và đưa ra những yêu cầu cho giải pháp mới như sau: Tính tương tác giữa các phần: Dịch vụ từ xa phải được dùng bởi các máy khách trên các nền khác. Tính thân thiện của Internet: Giải pháp phải họat động hiệu quả cho việc hỗ trợ các máy khách truy cập dịch vụ từ xa từ Internet. Định kiểu giao diện tốt: Không có sự mơ hồ nào về kiểu dữ liệu gửi và nhận từ dịch vụ từ xa. Hơn nữa, các kiểu dữ liệu được định nghĩa nên sắp xếp phù hợp với kiểu dữ liệu được định nghĩa bởi hầu hết các ngôn ngữ lập trình thủ tục. Có khả năng tương tác với các chuẩn Internet hiện tại: Việc thực thi các dịch vụ từ xa tương tác được với các chuẩn Internet hiện tại nhiều như có thể và tránh thay đổi giải pháp dẫn đến vấn đề cũ vừa được giải quyết. Giải pháp dựa trên sự chấp nhận rộng rãi các chuẩn Internet có thể tương tác với tập các công cụ hỗ trợ và các sản phẩm được tạo ra cho công nghệ. Hỗ trợ mọi ngôn ngữ lập trình: Giải pháp không nên chỉ giới hạn ở một số ngôn ngữ lập trình riêng biệt. Ví dụ như Java RMI thì chỉ hỗ trợ cho ngôn ngữ Java. Thật khó mà gọi hàm chức năng trên đối tượng Java từ xa từ Visual Basic hoặc Perl. Máy khách phải có thể thực thi được dịch vụ Web mới hoặc dùng dịch vụ Web sẵn có bất chấp máy khách được viết bởi ngôn ngữ lập trình nào. Hỗ trợ mọi cấu trúc cơ sở thành phần phân tán: Giải pháp không chỉ hỗ trợ vài cấu trúc cơ sở thành phần. Trên thực tế, ta không nên mua, cài đặt, lưu trữ cấu trúc cơ sở đối tượng phân tán chỉ để xây dựng một đối tượng từ xa hoặc để thực thi một dịch vụ có sẵn. Giao thức cơ sở nên làm cho việc truyền thông giữa các cấu trúc cơ sở hướng đối tượng hiện tại trở nên dễ dàng về cơ bản như: DCOM và CORBA. Và không ngạc nhiên khi giải pháp Microsoft đưa ra là Web Service. Web Service chỉ ra một giao diện để gọi hoạt động riêng biệt với tư cách đại diện cho máy khách. Máy khách có thể truy cập Web Service qua việc sử dụng các chuẩn Internet. CHƯƠNG 4 THIẾT KẾ VÀ CÀI ĐẶT CHƯƠNG TRÌNH Hệ thống Website kinh doanh sản phẩm thời trang được xây dựng để phục vụ các đối tượng người dùng sau: Người quản trị: Quản lý thông tin về khách hàng, sản phẩm, đơn đặt hàng, quản lý và báo cáo các giao tác xảy ra Nhà phân phối:Quản lý thông tin về kho hàng và báo cáo doanh thu Khách hàng: Người dùng chính của hệ thống, khách hàng có thể ghé thăm website để xem và đăng ký mua các sản phẩm quần áo thời trang. Biểu đồ use case: 4.1 ĐẶC TẢ USE CASE 4.1.1 CHỨC NĂNG CHUNG 4.1.1.1 Đăng nhập Người dùng: Người quản trị, nhà phân phối, khách hàng. Mối quan hệ giữa các use case: Extend <<Thoát Người quản trị <<Xem danh sách loai sản phẩm <<Thay đổi thông tin loại sản phẩm <<Tạo loại sản phẩm mới <<Xem danh sách sản phẩm <<Thay đổi thông tin sản phẩm <<Tạo sản phẩm mới <<Xem thông tin hoá đơn <<Tìm hóa đơn <<Xem danh sách nhà phân phối <<Thay đổi thông tin nhà phân phối <<Xem danh sách khách hàng <<Thay đổi thông tin khách hàng <<Xóa đối tượng <<Xem danh sách kho hàng <<Báo cáo doanh thu Nhà phân phối <<Thêm kho hàng <<Cập nhật kho hàng <<Xóa kho hàng << Báo cáo doanh thu Khách hàng <<Mua hàng trực tuyến Mục đích: Người sử dụng muốn đăng nhập vào hệ thống . Điều kiện ban đầu: Người dùng phải có tài khoản đã đăng ký. Kết quả: Người dùng đăng nhập được vào hệ thống. Dòng sự kiện chính : Người dùng chọn đăng nhập. Người dùng điền thông tin theo yêu cầu. Hệ thống kiểm tra tính xác thực của thông tin. Hệ thống cho phép đăng nhập. Mở rộng: 3a.Hệ thống xác nhận thông tin không hợp lệ.. 3a1. Hệ thống trả về bước hai và thông báo lỗi cho người dùng. Luật : 2a.Tên đăng nhập là địa chỉ email (đối với khách hàng). 2b.Người dùng không thể sử dụng chức năng của hệ thống nếu không đăng nhập thành công. 4.1.1.2 Thoát Người dùng: Người quản trị, khách hàng . Mục đích: Người dùng muốn thoát khỏi hệ thống. Điều kiện ban đầu: Người dùng đã đăng nhập vào hệ thống. Kết quả: .Người dùng thoát khỏi hệ thống. Dòng sự kiện chính: 1. Người dùng chọn chức năng thoát. 2. Hệ thống trở về trang đăng nhập. Luật: 2. Một khi đã thoát khỏi hệ thống thì người dùng không thể sử dụng các hàm chức năng của ứng dụng. 4.1.2 CHỨC NĂNG PHẦN QUẢN TRỊ 4.1.2.1 Xem danh sách loại sản phẩm Người dùng: Người quản trị. Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Người dùng muốn xem danh sách các loại sản phẩm trong hệ thống. Điều kiện ban đầu: Người đăng nhập thành công vào hệ thống . Kết quả: Người dùng có thể xem được danh sách loại sản phẩm. Dòng sự kiện chính: 1. Người dùng chọn chức năng xem danh sách loại sản phẩm trong hệ thống. 2. Hệ thống hiển thị danh sách sản phẩm. 3. Người dùng muốn chọn một loại sản phẩm bấ kỳ để cập nhật thông tin 4. Hệ thống chuyển đến trang hiệu chỉnh thông tin loại sản phẩm. 5. Người dùng chọn tạo loại sản phẩm mới. 6. Hệ thống chuyển đến trang thêm loại sản phẩm mới. 7. Người dùng có thể chọn vài loại sản phẩm để xóa khỏi danh sách. Mở rộng: 2a.Không có loại sản phẩm nào. 2a.1 Hệ thống sẽ thông báo điều này cho người dùng. Luật: 7a. Chỉ những loại sản phẩm rỗng mới bị xóa được . Yêu cầu kỹ thuật: 2a. Năm loại sản phẩm được hiển thị ở mỗi trang. Hệ thống cũng phân trang. 4.1.2.2 Cập nhật thông tin loại sản phẩm Người dùng: Người quản trị. Quan hệ giữa các use case: Extends: >>Đăng nhập Điều kiện ban đầu: Người quản trị đăng nhập thành công vào hệ thống. Mục đích: Người quản trị muốn thay đổi thông tin loại sản phẩm. Kết quả: Người quản trị cập nhật thành công thông tin mới cho loại sản phẩm. Dòng sự kiện chính: 1. Người quản trị thay đổi thông tin của loại sản phẩm đã chọn. 2. Hệ thống chuyển đến trang cập nhật thông tin loại sản phẩm . 3. Người quản trị chỉ định các thông tin cần cập nhật. 4. Người quản trị lưu thông tin sản phẩm vừa cập nhật. 5. Hệ thống xác nhận tính hợp lệ của thông tin. 6. Hệ thống cập nhật thông tin. Mở rộng: 5a.Thông tin về loại sản phẩm mới không hợp lệ. 5a.1 Hệ thống thông báo lỗi. 5a.2 Người quản trị sửa lỗi. 6a. Hệ thống không lưu được thông tin loại sản phẩm 6a.1 Hệ thống thông báo lỗi. 4.1.2.3 Tạo loại sản phẩm mới Người dùng: Nhà quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Người dùng muốn tạo loại sản phẩm mới. Điều kiện ban đầu: Người dùng đăng nhập thành công. Kết quả: Người dùng thêm loại sản phẩm mới thành công. Dòng sự kiện chính: 1. Người dùng chọn tạo mới loại sản phẩm. 2 Hệ thống chuyển đến trang tạo sản phẩm mới. 2. Người dùng điền thông tin về loại sản phẩm. 3. Người dùng phải upload hình ảnh cho loại sản phẩm. 4. Người dùng lưu thông tin chỉ định. 5. Hệ thống xác nhận tính hợp lệ. 6. Hệ thống lưu thông tin. Mở rộng: 5a.Có lỗi trong dữ liệu nhập. 5a.1 Hệ thống thông báo lỗi. 5a.2 Người quản trị sửa lỗi. 6a. Hệ thống không lưu được thông tin. 6a.1 Hệ thống thông báo lỗi đến người dùng. Luật: 2a. Tên loại sản phẩm phải là duy nhất trong hệ thống. 3a. Khi loại sản phẩm được tạo, nó sẽ được thêm vào cuối danh sách sản phẩm. 4.1.2.4 Xem danh sách sản phẩm Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích:Người dùng muốn xem danh sách sản phẩm trong hệ thống. Điều kiện ban đầu:Người quản trị đăng nhập thành công vào hệ thống. Kết quả: Người quản trị xem danh sách sản phẩm của một loại sản phẩm. Dòng sự kiện chính: 1. Người dùng chọn xem danh sách sản phẩm của một loại sản phẩm. 2. Hệ thống hiển thị danh sách sản phẩm. 3. Người quản trị có thể chọn một sản phẩm và thay đổi thông tin của nó. 4. Hệ thống chuyển đến trang thay đổi thông tin sản phẩm. 5. Người quản trị có thể muốn tạo sản phẩm mới. 6. Hệ thống chuyển đến trang tạo sản phẩm mới. 7. Người quản trị có thể chọn xóa vài sản phẩm. Mở rộng: 2a.Hệ thống thông báo không có sản phẩm. Yêu cầu kỹ thuật: 2a. Năm loại sản phẩm được hiển thị ở mỗi trang. Hệ thống cũng phân trang. 4.1.2.5 Thay đổi thông tin sản phẩm Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Điều kiện ban đầu: Người quản trị đăng nhập thành công. Mục đích: Người quản trị muốn thay đổi thông tin sản phẩm Kết quả: Người quản trị cập nhật thành công thông tin sản phẩm. Dòng sự kiện chính: 1. Người quản trị chọn thay đổi thông tin sản phẩm. 2. Hệ thống chuyển đến trang cập nhật thông tin sản phẩm. 3. Người quản trị điền thông tin sản phẩm cần cập nhật. 4. Người quản trị lưu thông tin sản phẩm. 5. Hệ thống xác nhận tính hợp lệ. 6. Hệ thống lưu thông tin vừa cập nhật. Mở rộng: 5a.Thông tin sản phẩm mới không hợp lệ 5a.1 Hệ thống thông báo lỗi 5a.2 Người quản trị sửa lỗi 6a. Hệ thống không lưu được thông tin cập nhật 6a.1 Hệ thống thông báo lỗi Luật 3a. Người quản trị phải upload hình ảnh cho mỗi sản phẩm 4.1.2.6 Tạo sản phẩm mới Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Người dùng muốn tạo sản phẩm mới Điều kiện ban đầu: Người dùng phải đăng nhập thành công vào hệ thống Kết quả:Người quản trị tạo thành công sản phẩm mới Dòng sự kiện chính: 1. Nhà quản trị chọn tạo sản phẩm mới. 2 Hệ thống chuyển đến trang tạo sản phẩm mới. 3. Người quản trị điền thông tin chỉ định. 4. Người quản trị phải upload hình ảnh cho sản phẩm mới 5. Người quản trị lưu thông tin sản phẩm. 6. Hệ thống xác nhận tính hợp lệ. 7. Hệ thống lưu thông tin sản phẩm mới. Mở rộng: 3a.Có lỗi trong dữ liệu nhập 3a.1 Hệ thống thông báo lỗi 3a.2 Hệ quản trị sửa lỗi. 7a. Hệ thống không lưu được thông tin sản phẩm 6a.1 Hệ thống hiển thị thông báo lỗi 4.1.2.7 Xem danh sách nhà phân phối Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Người quản trị muốn xem danh sách các nhà phân phối sản phẩm Điều kiện ban đầu: Người quản trị đăng nhập thành công vào hệ thống. Kết quả: Người quản trị có thể xem danh sách các nhà phân phối. Dòng sự kiện chính: 1. Người quản trị chọn xem danh sách các nhà phân phối. 2. Hệ thống hiển thị danh sách các nhà phân phối. 3. Có thể nhà quản trị chọn một nhà phân phối để cập nhật thông tin. 4. Hệ thống chuyển đến trang cập nhật thông tin nhà phân phối. Yêu cầu kỹ thuật: 2a. Năm nhà phân phối được hiển thị ở mỗi trang. Hệ thống cũng phân trang. 4.1.2.8 Thay đổi thông tin của nhà phân phối Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Điều kiện ban đầu: Người quản trị phải đăng nhập thành công vào hệ thống. Mục đích: Người quản trị muốn thay đổi thông tin của nhà phân phối. Kết quả: Người quản trị cập nhật thành công thông tin mới về nhà phân phối. Dòng sự kiện chính: 1. Người quản trị chọn một nhà phân phối để thay đổi thông tin. 2. Hệ thống chuyển đến trang cập nhật thông tin của nhà phân phối. 3. Người quản trị điền thông tin được chỉ định. 4. Người quản trị chọn lưu thông tin mới. 5. Hệ thống xác nhận tính hợp lệ. 6. Hệ thống cập nhật thông tin mới. Mở rộng: 5a.Thông tin mới cập nhật của nhà phân phối không hợp lệ 5a.1 Hệ thống thông báo lỗi. 5a.2 Người quản trị sửa lỗi 6a. Hệ thống không lưu được thông tin vừa cập nhật 6a.1 Hệ thống thông báo lỗi đến người dùng. 4.1.2.9 Xem danh sách kho hàng Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Người quản trị muốn xem danh sách kho hàng của một nhà phân phối. Điều kiện ban đầu: Người quản trị đăng nhập thành công vào hệ thống Kết quả: Người quản trị xem được danh sách các kho hàng của một nhà phân phối. Dòng sự kiện chính: 1. Người quản trị chọn xem danh sách kho hàng của một nhà phân phối. 2. Hệ thống hiển thị danh sách sản phẩm. Mở rộng: 2a.Hệ thống thông báo khi nhà phân phối không có kho hàng nào. Yêu cầu kỹ thuật: 2a. Năm kho hàng được hiển thị ở mỗi trang. Hệ thống cũng phân trang. 4.1.2.9 Xem thông tin của hóa đơn Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập <<Tìm hóa đơn Điều kiện ban đầu: Người quản trị phải đăng nhập thành công vào hệ thống Mục đích: Người quản trị muốn xem thông tin hóa đơn Kết quả: Xem được thông tin hóa đơn. Dòng sự kiện chính: 1. Người quản trị chọn xem thông tin hóa đơn. 2. Hệ thống hiển thị thông tin hóa đơn. 4.1.2.10 Tìm hóa đơn Người dùng: Người quản trị Quan hệ giữa các use case: Extends: <<Đăng nhập >>Xem thông tin hóa đơn Mục đích: Người dùng muốn xem vài hóa đơn thỏa điều kiện. Điều kiện ban đầu: Người dùng phải đăng nhập thành công vào hệ thống. Kết quả: Người quản trị xem được danh sách các hóa đơn thỏa yêu cầu. Dòng sự kiện chính: 1. Người quản trị chọn chức năng tìm hóa đơn thỏa yêu cầu. 2. Hệ thống hiển thị trang thông tin hóa đơn cùng điều kiện tìm. 3. Người quản trị điền thông tin điều kiện tìm. 4. Hệ thống hiển thị dannh sách hóa đơn thỏa yêu cầu. Mở rộng: 4a. Hệ thống không tìm thấy hóa đơn thỏa yêu cầu. 4a2. Hệ thống thông báo không có hóa đơn nào. 4a3. Hệ thống trở về bước 2. Yêu cầu kỹ thuật: Nếu người dùng không điền thông tin từ ngày (“FromDate”) thì hệ thống sẽ chọn tất cả các hóa đơn có ngày hóa đơn nhỏ hơn hoặc bằng ngày hiện tại( <= “ToDate”). Nếu người dùng không điền thông tin đến ngày (“ToDate”) thì hệ thống sẽ chọn tất cả các hóa đơn có ngày hóa đơn lớn hơn hoặc bằng từ ngày(FromDate). 4.1.2.11 Xóa các đối tượng Người dùng: Người quản trị Quan hệ giữa các use case: Include <<Xóa sản phẩm <<Xoá loại sản phẩm Extend >>Đăng nhập Mục đích: Người dùng muốn chọn xóa một đối tượng Điều kiện ban đầu: Người dùng phải đăng nhập vào hệ thống và có quyền thực hiện chức năng này. Phải có ít nhất một đối tượng trong hệ thống. Kết quả: Xóa thành công đối tượng được chọn. Dòng sự kiện chính: 1. Người dùng chọn đối tượng cần xóa. 2. Người dùng chọn chức năng xóa. 3. Hệ thống xóa đối tượng được chọn. Mở rộng: 1a. Người dùng chọn xóa loại sản phẩm 1a1. Loại sản phẩm có nhiều sản phẩm liên quan. 1a2. Hệ thống thông báo cho người dùng biết nếu xóa loại sản phẩm này thì các sản phẩm liên quan sẽ bị xóa và yêu cầu người dùng xác nhận lại 1a3. Người dùng xác nhận xóa loại sản phẩm. 1a4. Hệ thống xóa các sản phẩm liên quan. 4.1.2.12 Báo cáo doanh thu Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Người dùng muốn xem báo cáo doanh thu. Điều kiện ban đầu: Người quản trị đăng nhập thành công. Kết quả: Người quản trị có thể xem báo cáo doanh thu. Dòng sự kiện chính: Người dùng xem báo cáo doanh thu Hệ thống chuyển đến trang thông tin báo cáo doanh thu. Mở rộng: 1a. Người quản trị có thể xem báo cáo doanh thu trong mỗi tháng. 1a1. Hệ thống hiển thị kết quả báo cáo. 4.1.2.13 Xem danh sách khách hàng Người dùng: Người quản trị Quan hệ giữa các usse case: Extends: >>Đăng nhập Mục đích: Người quản trị muốn xem danh sách khách hàng Điều kiện ban đầu: Đăng nhập thành công vào hệ thống. Kết quả: Người quản trị có thể xem danh sách khách hàng. Dòng sự kiện chính: 1. Người quản trị chọn xem danh sách khách hàng . 2. Hệ thống hiển thị danh khách hàng 3. Người quản trị có thể chọn một khách hàng trong danh sách để cập nhật thông tin. 4. Hệ thống chuyển đến trang cập nhật thông tin khách hàng. 5. Người quản trị cập nhật thông tin mới. 6. Hệ thống lưu thông tin vừa cập nhật. Yêu cầu kỹ thuật 2a. Năm khách hàng được hiển thị ở mỗi trang. Hệ thống cũng phân trang. 4.1.2.14 Thay đổi thông tin khách hàng Người dùng: Người quản trị Quan hệ giữa các use case: Extends: >>Đăng nhập Điều kiện ban đầu: Người quản trị đăng nhập thành công vào hệ thống. Mục đích: Thay đổi thông tin khách hàng. Kết quả:Cập nhật thành công thông tin khách hàng. Dòng sự kiện chính: 1. Người quản trị chọn thay đổi thông tin khách hàng. 2. Hệ thống chuyển đến trang cập nhật thông tin khách hàng. 3. Người quản trị điền thông tin cần cập nhật vào. 4. Người quản trị lưu thông tin. 5. Hệ thống xác nhận tính hợp lệ của thông tin. 6. Hệ thống cập nhật thông tin chỉ định. Mở rộng: 5a.Thông tin khách hàng mới không hợp lệ 5a.1 Hệ thống thông báo lỗi. 5a.2 Người quản trị sửa lỗi. 6a. Hệ thống không lưu được thông tin mới của khách hàng. 6a.1 Hệ thống hiển thông báo lỗi. 4.1.2.15 Thêm kho hàng Người dùng: Nhà phân phối Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Người dùng muốn thêm kho hàng mới. Điều kiện ban đầu: Đăng nhập thành công vào hệ thống. Kết quả: Thêm kho hàng mới thành công . Dòng sự kiện chính: 1. Người dùng chọn thêm kho hàng mới. 2 Hệ thống chuyển đến trang thêm kho hàng. 3. Người dùng điền thông tin kho hàng. 4. Người dùng chọn lưu thông tin chỉ định 5. Hệ thống xác nhận thôngtin hợp lệ. 6. Hệ thống lưu thông tin mới. Mở rộng: 5a.Có lỗi trong cơ sở dữ liệu 5a.1 Hệ thống thông báo lỗi. 5a.2 Người dùng sửa lỗi. 6a. Hệ thống không lưu được thông tin mới. 6a.1 Hệ thống thông báo lỗi. 4.1.2.16 Cập nhật kho hàng Người dùng: Nhà phân phối Quan hệ giữa các use case: Extends: >>Đăng nhập Điều kiện ban đầu: Đăng nhập thành công vào hệ thống. Mục đích: Cập nhật thông tin kho hàng. Kết quả: Thông tin kho hàng mới được cập nhật thành công. Dòng sự kiện chính: 1. Người dùng chọn cập nhật thông tin kho hàng. 2. Hệ thống chuyển đến trang cập nhật. 3. Người dùng điền thông tin cập nhật. 4. Người dùng chọn lưu thông tin vừa cập nhật. 5. Hệ thống xác nhận tính hợp lệ. 6. Hệ thống lưu thông tin vừa cập nhật Mở rộng: 5a.Thông tin kho hàng không hợp lệ 5a.1 Hệ thống thông báo lỗi. 5a.2 Người dùng sửa lỗi. 6a. Hệ thống không lưu được thông tin kho hàng. 6a.1 Hệ thống thôngbáo lỗi. 4.1.2.17 Xóa kho hàng Người dùng: Nhà phân phối. Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Xóa kho hàng chỉ định Điều kiện ban đầu: Người dùng phải đăng nhập vào hệ thống và được phép thực hiện chức năng này. Có ít nhất một sản phẩm trong danh sách sản phẩm. Kết quả: Xóa kho hàng được chọn. Dòng sự kiện chính: 1. Người dùng chọn kho hàng cần xóa. 2. Người dùng xóa kho hàng. 3. Hệ thống xóa kho hàng được chọn. 4.1.2.18 Báo cáo doanh thu Người dùng: Nhà phân phối Quan hệ giữa các use case: Extends: >>Đăng nhập Mục đích: Nhà phân phối muốn làm báo cáo doanh thu. Điều kiện ban đầu: Nhà phân phối đăng nhập thành công vào hệ thống. Kết quả: Nhà phân phối có thể xem thông tin báo cáo. Dòng sự kiện chính: Nhà phân phối làm báo cáo doanh thu. Hệ thống trả về trang báo cáo doanh thu. Mở rộng: 1a. Nhà phân phối có thể làm báo cáo doanh thu cho mỗi tháng 1a1. Hệ thống trả về kết quả báo cáo 4.1.3 CHỨC NĂNG PHẦN KHÁCH HÀNG 4.1.3.1 Đăng ký tài khoản Người dùng: Khách hàng Mục đích: Người dùng muốn đăng ký tài khoản Kết quả:Thông tin khách hàng được lưu. Dòng sự kiện chính: Người dùng chọn đăng ký tài khoản. Hệ thống chuyển đến trang đăng ký. Khách hàng điền thông tin. Hệ thống lưu thông tin đăng ký của khách hàng. Mở rộng: 4a. Thông tin đăng ký không lệ. 4a1. Hệ thống thông báo lỗi đến người dùng. 4a2. Khách hàng sửa lại thông tin cho hợp lệ. Luật: 3a. Tên đăng nhập là duy nhất trong hệ thống. 4.1.3.2 Xem danh sách loại sản phẩm Người dùng: Khách hàng Quan hệ giữa các use case: Extend <<Xem danh sách sản phẩm Mục đích: khách hàng muốn xem tất cả các loại sản phẩm trong hệ thống. Điều kiện ban đầu: Khách hàng đăng nhập thành công Kết quả: Khách hàng xem các loại sản phẩm chính trong hệ thống. Dòng sự kiện chính: Người dùng chọn xemdanh sách sản phẩm. Hệ thống hiển thị danhsách các loại sản phẩm. Khách hàng có thể chọn một loại sản phẩm và xem danh sách sản phẩm. Hệ thống hiển thị danh sách sản phẩm. Khách hàng có thể chọn một sản phẩm và xem chi tiết sản phẩm. Hệ thống chuyển đến trang chi tiết sản phẩm. Khách hàng có thể chọn một sản phẩm để thêm vào giỏ hàng. 4.1.3.3 Xem danh sách sản phẩm Người dùng: Khách hàng Relationship: Extend >>Xem danh sách loại sản phẩm >>Xem chi tiết sản phẩm >>Thêm sản phẩm vào giỏ hàng Mục đích: Khách hàng muốn xem chi tiết của loại sản phẩm. Điều kiện ban đầu: Khách hàng đăng nhập thành công vào hệ thống. Kết quả: Khách hàng xem chi tiết loại sản phẩm đã chọn. Dòng sự kiện chính: Khách hàng chọn loại sản phẩm. Hệ thống hiển thị danh sách các sản phẩm của loại sản phẩm đó. Khách hàng chọn sản phẩm và xem chi tiết. Hệ thống chuyển đến trang chi tiết sản phẩm. Khách hàng có thể chọn thêm sản phẩm vào giỏ hàng. Kỹ thuật: Hệ thống hiển thị hình và tên sản phẩm cho mỗi sản phẩm. 4.1.3.4 Xem chi tiết sản phẩm Người dùng: Khách hàng Quan hệ: Extend >>Xem danh sách sản phẩm. Kết quả: Khách hàng xem được chi tiết sản phẩm. Mục đích: Khách hàng muốn xem sản phẩm. Dòng sự kiện chính: Khách hàng chọn loại sản phẩm. Hệ thống hiển thị danh sách sản phẩm. Khách hàng chọn sản phẩm muốn xem. Hệ thống hiển thị chi tiết sản phẩm. Khách hàng chọn thêm sản phẩm vào giỏ hàng. 4.1.3.5 Thêm sản phẩm vào giỏ hàng Người dùng: Khách hàng Quan hệ: Extend <<Xem danh sách sản phẩm Mục đích: Khách hàng muốn mua sản phẩm đã chọn. Điều kiện ban đầu: Khách hàng đang xem chi tiết sản phẩm. Dòng sự kiện chính: Khách hàng chọn mua sản phẩm. Hệ thống kiểm tra số lượng sản phẩm trong kho. Mở rộng: 2a. Hệ thống xác nhận không còn sản phẩm tồn. 2a1. Hệ thống hiển thị thôngbáo lỗi. 2a2. Hệ thống chuyển về trang danh sách sản phẩm cho khách hàng mua sản phẩm khác. 4.1.3.6 Xem giỏ hàng Người dùng: Khách hàng Quan hệ: Extend <<Cập nhật/xóa sản phẩm trong giỏ hàng <<Mua hàng từ kho <<Mua hàng trực tuyến Mục đích: Khách hàng muốn xem tất cả sản phẩm trong giỏ hàng hiện hành. Kết quả: Khách hàng có thể xem tất cả sản phẩm có trong giỏ hàng của mình. Dòng sự kiện chính: Khách hàng muốn xem giỏ hàng. Hệ thống mở giỏ hàng và hiển thị thông tin. Khách hàng muốn xem lại giỏ hàng. Khách hàng có thể chọn mua sản phẩm từ kho. Hệ thống hiển thị thông tin các kho hàng. Khách hàng có thể chọn mua hàng trực tuyến. Hệ thống hiển thị trang mua hàng trực tuyến. Mở rộng: 2a. Không có sản phẩm trong giỏ hàng. 2a1. Hệ thống hiển thị thông báo lỗi. 4.1.3.6 Cập nhật / Xoá sản phẩm trong giỏ hàng Người dùng: Khách hàng Quan hệ giữa các use case: Extend: >>Xem giỏ hàng Điều kiện ban đầu: Hệ thống có ít nhất một sản phẩm trong giỏ hàng. Kết quả: Giỏ hàng được cập nhật/xóa. Mục đích: Khách hàng muốn cập nhật/xóa sản phẩm trong giỏ hàng. Dòng sự kiện chính: Người dùng chọn xem giỏ hàng. Hệ thống hiển thị giỏ hàng hiện tại. Khách hàng cập nhật xóa sản phẩm trong giỏ hàng. Hệ thống xác nhận việc khách hàng cập nhật/xóa sản phẩm trong giỏ. Khách hàng xác nhận muốn cập nhật/xóa sản phẩm trong giỏ hàng.t. Hệ thống xóa/cập nhật ssản phẩm trong giỏ hàng. Mở rộng: 2a. Khách hàng không muốn cập nhật/xóa sản phẩm trong giỏ hàng 2a1. Hệ thống không cập nhật/xóa sản phẩm trong giỏ hàng. 2a2. Hệ thống cho phép người dùng tiếp tục bước ba. Luật: Việc thay đổi số lượng sản phẩm trong giỏ hàng thành 0 thì tương đương với việc xóa sản phẩm đó ra khỏi giỏ hàng. 4.1.3.7 Mua hàng trực tuyến Người dùng: Khách hàng Quan hệ giữa các use case: Extend: >>Đăng nhập >>Xem giỏ hàng Điều kiện ban đầu: - Khách hàng đăng nhập thành công vào hệ thống. - Hệ thống có ít nhất một sản phẩm trong giỏ hàng. Mục đích: Khách hàng muốn mua hàng trực tuyến. Dòng sự kiện chính: Người dùng chọn mua sản phẩm trực tuyến. Hệ thống hiển thị form nhập thông tin của người thanh toán và thông tin của người nhận hàng. Khách hàng điền thông tin theo yêu cầu. Khách hàng chọn xử lý thẻ tín dụng. Hệ thống xử lý thẻ tín dụng thành công. Hệ thống hiển thị thông tin xác nhận hoá đơn mua hàng. Mở rộng: *1- Khách hàng huỷ việc xử lý và kết thúc thanh toán mà không thực hiện bất kỳ giao tác nào. Thông tin này sẽ được lưu như một giao tác không hoàn tất. 3a1. Khách hàng điền thông tin không hợp lệ ở form nhập thông tin người thanh toán và người nhận hàng. 3a2. Hệ thống xác nhận thông tin nhập không hợp lệ. 3a3. Hệ thống hiển thị thông báo lỗi và chuyển về trang nhập thông tin của người thanh toán và người nhận hàng. 3a4. Khách hàng điền thông tin hợp lệ. 3a5. Hệ thống trả về bước hai. 4a1. Khách hàng hủy việc xử lý thanh toán. 4a2. Hệ thống không xử lý giao tác và cho phép người dùng tiếp tục mua hàng. 5a1. Hệ thống xử lý thanh toán thẻ tín dụng không thành công. 5a2. Hệ thống trả về bước hai đến form nhập thông tin người thanh toán và người nhận hàng. 4.1.3.8 Mua sản phẩm từ kho hàng Người dùng: Khách hàng Quan hệ giữa các use case: Extend: >>Xem giỏ hàng Điều kiện ban đầu: Có ít nhất một mặt hàng trong giỏ hàng. Mục đích: Khách hàng muốn mua sản phẩm từ kho hàng. Dòng sự kiện chính: Người dùng chọn mua hàng ở kho hàng cục bộ. Hệ thống hiển thị danh sách kho hàng cho người dùng tự chọn. 4.1.4 ĐẶC TẢ DỮ LIỆU Trên cơ sở khảo sát thực tế ta cần phải thiết lập một cơ sở dữ liệu có đầy đủ các thông tin cần thiết và các thông tin đó phải thống nhất,tức là phải có sự ràng buộc với nhau bằng các qui định một cách chặt chẽ. ADMINISTRATOR_lưu trữ thông tin của nhà quản trị . CUSTOMERS– lưu trữ thông tin của khách hàng. CATEGORIES– lưu trữ thông tin của loại sản phẩm. PRODUCTS– lưu trữ thông tin của sản phẩm. ORDERS – lưu trữ thông tin của hóa đơn. ORDERDETAIL – lưu trữ thông tin chi tiết hóa đơn. DISTRIBUTORS_ lưu trữ thông tin củanhà phân phối. STORES_ lưu trữ thông tin kho hàng. 4.1.4.1 CÁC BẢNG DỮ LIỆU VÀ LƯỢC ĐỒ CƠ SỞ DỮ LIỆU 1. BẢNG ADMINISTRATOR Thuộc tính Kiểu dữ liệu Độ dài Ràng buộc Ghi Chú AdminID int 4 PrimaryKey Identity Not Null Mã nhà quản trị Username nvarchar 50 Not Null Tên đăng nhập Password nvarchar 20 Not Null Mật khẩu Type tinyint 1 Not Null Loại quản trị 2. BẢNG CUSTOMERS Thuộc tính Kiểu dữ liệu Độ dài Ràng buộc Ghi chú CustomerID int 4 PrimaryKey Identity Not Null Mã khách hàng CustomerName nvarchar 255 Not Null Tên khách hàng Email nvarchar 127 Not Null Password nvarchar 50 Not Null Mật khẩu Company nvarchar 50 Allow Null Tên công ty Address nvarchar 255 Not Null Địa chỉ Province_City nvarchar 50 Not Null Tỉnh_Thành phố PhoneNumber nvarchar 20 Not Null Số điện thoại Fax nvarchar 20 Allow Null Country nvarchar 50 Allow Null Tên quốc gia 3. BẢNG CATEGORIES Thuộc tính Kiểu dữ liệu Độ dài Ràng buộc Ghi chú CategoryID int 4 PrimaryKey Identity Not Null Mã loại sản phẩm CategoryName nvarchar 255 Not Null Tên loại sản phẩm LargeImage nvarchar 50 Allow Null Hình kích thước lớn SmallImage nvarchar 50 Allow Null Hình kích thước nhỏ Description nvarchar 2000 Allow Null Mô tả chi tiết 4.BẢNG PRODUCTS Thuộc tính Kiểu dữ liệu Độ dài Ràng buộc Ghi chú ProductID int 4 PrimaryKey Identity Not Null Mã sản phẩm CategoryID int 4 ForeignKey Mã loại sản phẩm ProductName nvarchar 255 Not Null Tên sản phẩm ProductDescription nvarchar 2000 Not Null Mô tả chi tiết sản phẩm LargeImage nvarchar 50 Not Null Hình lớn sản phẩm SmallImage nvarchar 50 Not Null Hình nhỏ sản phẩm Price float 8 Not Null Giá sản phẩm Quantity int 4 Not Null Số lượng tồn longDescription nvarchar 2000 Not Null Mô tả chi tiết hơn về size , màu sắc sản phẩm (nếu có). 5. BẢNG ORDERS Thuộc tính Kiểu dữ liệu Độ dài Ràng buộc Ghi chú OrderID int 4 PrimaryKey Identity Not Null Mã hóa đơn CustomerID int 4 ForeignKey Mã khách hàng DistributorID int 4 ForiegnKey Mã nhà phân phối OderDate datetime 8 Not Null Ngày hóa đơn OrderStatus tinyint 1 Not Null Trạng thái hóa đơn (Unfinalized, Pending, Paid, Shipped, Complete, Cancelled) CardName nvarchar 255 Not Null Tên thẻ tín dụng CardType nvarchar 50 Not Null Loại thẻ tín dụng CardNumber nvarchar 50 Not Null Mã thẻ tín dụng ExMonth nvarchar 2 Not Null Tháng hết hạn thẻ tín dụng ExYear nvarchar 4 Not Null Năm hết hạn thẻ tín dụng BillingName nvarchar 255 Not Null Tên người trả tiền BillingCompany nvarchar 50 Not Null Tên công ty người trả tiền BillingPhone nvarchar 20 Not Null Số điện thoại người trả tiền BillingEmail nvarchar 50 Not Null Email người trả tiền BillingFax nvarchar 50 Allow Null Fax của người trả tiền BillingAddress nvarchar 255 Not Null Địa chỉ người trả tiền BillingCity nvarchar 20 Not Null Thành phố BillingCountry nvarchar 20 Not Null Tên quốc gia ShippingName nvarchar 255 Not Null Tên người nhận hàng ShippingCompany nvarchar 50 Not Null Công ty người nhận hàng ShippingPhone nvarchar 20 Not Null Điện thoại của người nhận hàng ShippingEmail nvarchar 50 Not Null Email của người nhận hàng ShippingFax nvarchar 20 Allow Null Fax của người nhận hàng ShippingAddress nvarchar 255 Not Null Địa chỉ người nhận hàng ShippingCity nvarchar 20 Not Null Thành phố nơi nhận hàng ShippingCountry nvarchar 20 Not Null Quốc gia nơi nhận hàng Tax Money 8 Not Null Thuế Total Money 8 Not Null Tổng trị giá hóa đơn 6. BẢNG ORDERDETAIL Thuộc tính Kiểu dữ liệu Độ dài Ràng buộc Ghi chú ProductID int 4 PrimaryKey Mã sản phẩm OrderID int 4 PrimaryKey Mã hóa đơn Proprice money 8 Not Null Giá bán trên hóa đơn Procredit money 8 Not Null Tiền hoa hồng cho mỗi sản phẩm Quantity int 4 Not Null Số lượng bán 7. BẢNG DISTRIBUTORS Thuộc tính Kiểu dữ liệu Độ dài Ràng buộc Ghi chú DistributorID int 4 PrimaryKey Identity Not Null Mã nhà phân phối DisName nvarchar 255 Not Null Tên nhà phân phối DisAddress nvarchar 255 Not Null Địa chỉ nhà phân phối DisPhone nvarchar 10 Not Null Điện thoại nhà phân phối DisFax nvarchar 10 Allow Null DisEmail nvarchar 50 Allow Null Email nhà phân phối UserName nvarchar 50 Not Null Tên đăng nhập Password nvarchar 20 Not Null Mật khẩu 8. BẢNG STORES Thuộc tính Kiểu dữ liệu Độ dài Ràng buộc Ghi chú StoreID int 4 PrimaryKey Identity Not Null Mã kho hàng DistributorID int 4 ForeignKey Mã nhà cung cấp StoreName nvarchar 50 Not Null Tên kho hàng StoreAddress nvarchar 50 Not Null Địa chỉ kho hàng StorePhone nvarchar 10 Not Null Điện thoại kho hàng Province_City nvarchar 10 Not Null Tỉnh _thành phố 4.1.4.2 LUỢC ĐỒ CƠ SỞ DỮ LIỆU CÁC BIỂU ĐỒ MÔ TẢ CHỨC NĂNG HỆ THỐNG 4.2.1 BIỂU ĐỒ LỚP Các biểu đồ lớp trong hệ thống: Các Entity class chung: 4.2.1.1 Phần quản trị Các boundary class: Các control class: Thay đổi thông tin sản phẩm Thêm loại sản phẩm mới Xem danh sách người dùng (khách hàng và nhà phân phối) 4. Xem thông tin hóa đơn 4.2.1.2 Phần khách hàng Các boundary class: Các control class: Đăng ký tài khoản Thêm sản phẩm vào giỏ hàng Cập nhật/xóa sản phẩm trong giỏ hàng Mua hàng trực tuyến 4.2.2 BIỂU ĐỒ TUẦN TỰ 4.2.2.1 Chức năng phần quản trị Tạo sản phẩm mới Xem thông tin hóa đơn Tìm hóa đơn Xóa các đối tượng Xóa loại sản phẩm Xóa sản phẩm Báo cáo doanh thu Thay đổi thông tin khách hàng 4.2.2.3 Chức năng phục vụ khách hàng Xem danh sách sản phẩm Xem chi tiết sản phẩm Thêm sản phẩm vào giỏ hàng Xem giỏ hàng Cập nhật/xóa sản phẩm trong giỏ hàng Mua hàng trực tuyến 4.2.3 BIỂU ĐỒ TRIỂN KHAI 4.3 THIẾT KẾ WEBSITE Xem chi tiết trong phần đĩa CD đính kèm. Dưới đây là một số trang Web tiêu biểu 4.3.1 PHẦN KHÁCH HÀNG Trang ListProducts.aspx giới thiệu các sản phẩm theo từng loại: Trang xác nhận hóa đơn mua hàng trực tuyến_Confirm.aspx . Sau khi khách hàng chọn sản phẩm cần mua và điền các thông tin cần thiết về người thanh toán và người nhận hàng thì hệ thống chuyển đến trang xác nhận mua hàng. 4.3.2 PHẦN QUẢN TRỊ Trang quản lý loại sản phẩm, trang tìm hóa đơntheo điều kiện, trang tạo báo cáo doanh thu. 4.3.2 XML WEBSERVICE Phần dành cho nhà quản trị: Hàm chức năng lấy danh sách loại sản phẩm từ cơ sở dữ liệu để dùng cho phần website khách hàng: Hàm chức năng cập nhập kho hàng với các tham số cần truyền : Hàm chức năng thêm sản phẩm mới (phần mô tả thông điệp SOAP) Phần dành cho khách hàng Ta có thể dùng các hàm chức năng này gọi từ cấu trúc XML Web Service xây dựng sẵn để xây dựng nên website bán hàng một cách dễ dàng. CHƯƠNG 5 ĐÁNH GIÁ VÀ HƯỚNG PHÁT TRIỂN 5.1 ĐÁNH GIÁ Sau khi cài hoàn thành xong các bước phân tích và triển khai xây dựng hệ thống, em đã tự hoàn chỉnh lại kiến thức về nhiều mặt: Về lý thuyết, em đã hiểu cơ bản về công nghệ .NET, phương thức hoạt động cũng như các kỹ thuật xây dựng Web bằng ASP.NET, về cấu trúc của XML Web Service và cách xây dựng, ứng dụng XML Web Service vào thực tế cũng như ưu điểm và hạn chế của XML Web Service so với các công nghệ DCOM, CORBA, Java RMI. Em hiểu được vai trò, tầm quan trọng và hiệu quả của việc ứng dụng XML Web Service trong việc trao đổi thông tin giữa các ứng dụng khác nhau chạy trên những platform khác nhau. Bên cạnh đó, qua việc tìm hiểu hoạt động thương mại điện tử, em cũng hiểu được cách giới thiệu hàng hóa và việc thanh toán hóa đơn. Tuy chưa phải là chặt chẽ song rất cơ bản và cần thiết. Về kỹ thuật lập trình, em đã tiếp cận được với mô hình ba lớp kết hợp với việc sử dụng cấu trúc XML Web Service mà em chưa từng thực hành trên đồ án cụ thể. Vì thời gian thực hiện đề tài có hạn nên em không thể hoàn thiện tất cả các chức năng cần thiết cho mô hình. Chính vì lý do này, hệ thống còn một số hạn chế: Quá trình kiểm tra và thử nghiệm hệ thống trên thực tế chưa được thực hiện. Phần giúp đỡ sử dụng cho hệ thống chưa được xây dựng. Hạn chế này sẽ gây khó khăn rất nhiều cho người sử dụng. Phát triển ứng dụng thực thi trên các máy chủ khác nhau trao đổi thông tin một cách dễ dàng ( ví dụ: Win2k Server, Unix server,). Việc bảo mật là vấn đề quan trọng trong thương mại điện tử. Hệ thống chỉ sử dụng công nghệ do .NET hỗ trợ mà chưa thực sự lập được hướng bảo mật riêng. 5.2 HƯỚNG PHÁT TRIỂN Từ những hạn chế nêu trên, em xin đề ra hướng phát triển trong tương lai như sau: Xây dựng chức năng hỗ trợ xử lý thẻ tín dụng bằng mạng Authorizenet để hệ thống có thể thực hiện việc xử lý thanh toán hóa đơn qua mạng. Xây dựng hệ thống bảo mật chặt chẽ hơn về phía khách hàng và quản trị Xây dựng cho hệ thống các hỗ trợ hướng dẫn sử dụng cho người dùng cũng như các tài liệu kỹ thuật cho các nhà phát triển. Định hướng khắc phục những khuyết điểm trong vấn đề bảo mật của Web Service trong tương lai. Trong khoảng thời gian cho phép để hoàn thành đề tài tốt nghiệp, em có thể chưa hoàn tất đầy đủ chức năng, tính linh hoạt và phổ biến của hệ thống. Sau này với điều kiện cho phép, đề tài này có thể phát triển rộng hơn về quy mô hoạt động sao cho hoàn chỉnh và phù hợp với thực tế. TÀI LIỆU THAM KHẢO www.w3schools.com Web Services Business Strategies and Architectures Gunjan Samtani Dimple Sadhwani Microsoft .NET Distributed Applications: Integrating XML Web Services and .NET Remoting. Matthew MacDonald ASP.NET Web Developer’s Guide Mesbah Ahmed Chris Garrett Jeremy FairCloth Chris Payne DotThatCom.com Wei Meng Lee Jonothon Ortiz Building XML Web Service for the Microsoft. Net Platform Scott Short ASP.NET Database Programming Weekend Crash Course Jason Butler Tony CauDill PHỤ LỤC XỬ LÝ THẺ TÍN DỤNG BẰNG MẠNG AUTHORIZENET 1. Giới thiệu 2. Tài khoản ngân hàng ngoại thương (Merchant account) 3. Các kiểu giao dịch thẻ tín dụng 4. Hệ thống xử lý giao dịch của AuthorizeNet 4.1 Virtual Terminal 4.2 WebLink 4.3 ADC Relay Response 4.4 ADC Direct Response 1. Giới thiệu Authorizenet là một hệ thống xử lý thẻ tín dụng theo thời gian thực, số lượng khách hàng thuộc hạng top do có nhiều giải pháp với độ khó khác nhau để khách hàng lựa chọn, và cũng thuộc loại an toàn cao. Các hệ thống khác là Verisign - sử dụng Payflowpro, và USA E-pay. Mỗi hệ thống có một cách tiếp cận khác nhau đối với vấn đề này. Ngoài ra trên thế giới còn rất nhiều những hệ thống khác nhưng nói tổng quát đều hoạt động theo mô hình như sau: - Ta đăng ký một tài khoản (account) với hệ thống để có thể sử dụng dịch vụ của nó. Khoảng hơn 100$/tháng. - Website của ta nhận các thông số từ người dùng rồi chuyển cho các hệ thống xử lý như Verisign, Authorize, SurePay... - Các hệ thống này gởi tiếp lên hệ thống kiểm tra thẻ tín dụng AVS để xác định xem thẻ có hợp lệ không (trúng số, ngày hết hạn, ... ), hoặc hợp lệ nhưng có khả năng bị xài lậu không. Ví dụ ta biết được thông tin credit của ai đó rồi lấy xài, nhưng địa chỉ chuyển hàng về là địa chỉ của ta thì thẻ là hợp lệ nhưng hệ thống vẫn biết là giao dịch có thể là lậu, vì địa chỉ giao hàng không phù hợp với các địa chỉ thường dùng chẳng hạn. - Hệ thống biết được thẻ là hợp lệ và thực hiện đặt giao dịch vào hàng đợi để đến một thời điểm cố định trong ngày sẽ thực hiện lấy tiền từ giao dịch. Trước thời gian này thì khách hàng có thể hủy giao dịch và lấy lại tiền (void transaction) - Hệ thống báo kết quả về thẳng cho khách hàng hoặc truyền tham số về site chúng ta để ta xử lý hiển thị tiếp cho phù hợp. 2. Tài khoản ngân hàng ngoại thương (Merchant account) Thực ra thì tài khoản ta đăng ký với hệ thống xử lý là chưa đủ mà còn cần một tài khoản đăng ký với các ngân hàng thuộc hệ thống Visa và MasterCard để mở dịch vụ chuyển nhận tiền vào tài khoản của bạn, nhưng thông thường thì khi đăng ký với hệ thống như Verisign thì người ta sẽ xử lý nghiệp vụ này. 3. Các kiểu giao dịch thẻ tín dụng Authorizenet chấp nhận sáu kiểu lệnh giao dịch. Giả sử thẻ tín dụng là hợp lệ: - Auth-capture : kiểu mặc định, thường sử dụng nhất. Sau khi đặt lệnh, đến giờ giao dịch trong ngày thẻ sẽ bị trừ tiền và chuyển về tài khoản ngân hàng ngoại thương. - Auth_Only: lệnh đặt giao dịch được đặt vào hàng đợi cho đến khi người bán hàng đặt một lệnh Prior-Auth-Capture để chấp nhận chuyển tiền. Nếu không làm gì thì giao dịch tự động kết thúc sau ba muơi ngày đợi. - Prior-Auth_Capture: để lấy tiền từ giao dịch Auth-Only. - Capture: dùng để thanh toán các giao dịch đã có lúc trước không thực hiện qua Authorizenet. Không dùng trên website mà dùng Virtual Terminal của Authorize để xử lý. - Credit: dùng để hoàn tiền lại thẻ tín dụng sau khi thẻ đã bị trừ tiền, chẳng hạn như ta mua hàng về, trả tiền rồi mà món hàng đó bị hỏng do (nguyên nhân khách quan) thì được trả tiền lại. - Void: hủy bỏ một giao dịch trước khi tiền trong thẻ tín dụng bị trừ. 4. Hệ thống xử lý giao dịch của AuthorizeNet Bao gồm Vitual Terminal, WebLink, ADC Relay/Direct Response. 4.1 Virtual Terminal Người bán hàng sử dụng trực tiếp website của Authorize để đặt các giao dịch. Website của ta không phải xử lý . 4.2 WebLink Website thực hiện đến bước tính tổng số tiền cần trả và post một form sang WebLink và WebLink thực hiện tất cả các công việc còn lại, có nghĩa là các thông tin như số thẻ tín dụng, họ tên người mua, ... sẽ nhập vào form bên phía Web link, máy chủ của Authorizenet xử lý và báo kết quả về. Ta chỉ phải cung cấp một URL đặt vào form kết quả của Weblink để khách quay về website của ta sau quá trình thanh toán. Cách này tốn ít công sức phát triển nhất nhưng có điểm hạn chế là khách hàng sẽ bị chuyển sang site khác một cách rõ ràng. Mặc dù ta có thể tùy biến giao diện các form bên Authorizenet (logo, màu) nhưng địa chỉ site sẽ khác. Ta cũng không thể dùng frame để dấu đi sự chuyển đổi site này. 4.3 ADC Relay Response Website của ta gởi các thông tin giao tác (transaction) cần thiết bằng form đến địa chỉ https://secure.authorize.net/gateway/transact.dll. Nếu chưa đủ thông tin cho giao dịch, nó sẽ hiển thị tiếp form nhập như weblink. Khi xử lý xong, kết quả giao dịch được truyền qua https về một URL mà ta muốn nhận kết quả để xử lý tiếp. Vì lý do an toàn, URL này phải là một URL hợp lệ được định nghĩa qua URL manager có trong tài khoản của ngân hàng ngoại thương. Ví dụ: --> chưa đủ info cho transaction, hiển thị tiếp Payment form của Weblink 4.4 ADC Direct Response An toàn hơn Relay Response nhưng yêu cầu kết nối lúc gởi form (có đầy đủ thông tin để xử lý giao dịch) từ trình duyệt máy khách (client browser) qua https thẳng đến Authorizenet, thay vì chỉ yêu cầu https từ máy chủ của website đến cổng vào Authorize . Hoàn toàn không thể dùng Payment form của WebLink trong ADC Direct Response như ADC Relay Response. Khi lập trình, ta có thể thiết lập chế độ kiểm tra và mọi thao tác sẽ diễn ra bình thường như xử lý thực, chỉ ngoại trừ tiền là không bị trừ. Nếu không có số thẻ tín dụng thật có thể sử dụng các số thẻ tín dụng kiểm tra của các hãng cung cấp. Đối với dạng trừ tiền định kỳ hàng loạt như thu tiền thành viên hàng năm, ta có thể upload file dạng csv để xử lý batch và download file trả kết quả về.