Công nghệ hướng đối tượng và ứng dụng phát triển hệ thống quản lý khách hàng trước và sau khi bán hàng của doanh nghiệp

PHẦN MỞ ĐẦU Khi cạnh tranh không đơn thuần thông qua đầu tư trang thiết bị, sử dụng dây truyền công nghệ hiện đại không còn là lợi thế riêng của một doanh nghiệp nào đó nữa thì một yếu t

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LÊ THỊ CHÂU

CÔNG NGHỆ HƯỚNG ĐỐI TƯỢNG

VÀ ỨNG DỤNG PHÁT TRIỂN HỆ THỐNG QUẢN

LÝ KHÁCH HÀNG TRƯỚC VÀ SAU KHI BÁN

HÀNG CỦA DOANH NGHIỆP

LUẬN VĂN THẠC SĨ

Hà Nội – 2010

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC CHỮ VIẾT TẮT 6

PHẦN MỞ ĐẦU 7

Chương 1 – Cơ sở lý luận về công nghệ hướng đối tượng và ngôn ngữ mô hình hóa thống nhất UML 9

1.1 Tổng quan về công nghệ hướng đối tượng và phương pháp mô hình hóa 9

1.2 Ngôn ngữ mô hình hóa thống nhất UML 12

1.2.1 Lịch sử phát triển của UML 12

1.2.2 UML là gì? 13

1.2.3 Mô hình khái niệm của UML 13

1.3 Quy trình phân tích thiết kế hệ thống hướng đối tượng 20

1.3.1 Xây dựng mô hình nghiệp vụ 20

1.3.2 Xác định yêu cầu 21

1.3.3 Phân tích 24

1.3.4 Thiết kế 27

1.3.5 Lập trình và kiểm tra chương trình 36

1.3.6 Vận hành và bảo trì hệ thống 36

Chương 2 – Khái quát về hệ thống quản lý quan hệ khách hàng CRM 37

2.1 Khách hàng quyết định sự thành bại của doanh nghiệp 37

2.1.1 Cạnh tranh bằng sự thân thiết với khách hàng 37

2.1.2 Vai trò của CRM trong giai đoạn khủng hoảng hiện nay 39

2.2 Cơ sở lý luận về quản lý quan hệ khách hàng CRM 40

2.2.1 Định nghĩa 40

2.2.2 Lịch sử học thuyết CRM 45

2.2.3 Lợi ích của CRM 45

2.2.4 Thực trạng triển khai CRM hiện nay 48

2.3 Quy trình tác nghiệp 49

2.3.1 Các chức năng chung 49

2.3.2 Các chức năng con của hệ thống CRM 50

2.3.3 Các hoạt động chính của hệ thống CRM 52

2.4 Các hoạt động nghiệp vụ của hệ thống CRM 55

2.4.1 Các quy trình tác nghiệp 55

2.4.2 Mô tả hoạt động nghiệp vụ giai đoạn trước bán hàng 59

2.4.3 Mô tả hoạt động nghiệp vụ giai đoạn bán hàng 63

2.4.4 Mô tả hoạt động nghiệp vụ giai đoạn sau bán hàng 64

Chương 3 – Đặc tả yêu cầu và các mô hình phân tích hệ thống CRM 65

3.1 Đặc tả yêu cầu 65

3.1.1 Giai đoạn trước bán hàng 65

3.1.2 Biểu đồ ca sử dụng giai đoạn bán hàng 83

3.1.3 Biểu đồ ca sử dụng giai đoạn sau bán hàng 87

3.2 Biểu đồ hoạt động 94

3.2.1 Giai đoạn trước bán hàng 94

3.2.2 Giai đoạn bán hàng 104

3.2.3 Giai đoạn sau bán hàng 106

3.3 Mô hình khái niệm và Biểu đồ tuần tự 107

3.3.1 Giai đoạn trước bán hàng 107

3.3.2 Giai đoạn bán hàng 113

3.3.3 Giai đoạn sau bán hàng 118

Chương 4 – Các mô hình thiết kế hệ thống CRM 119

4.1 Thiết kế chi tiết các biểu đồ lớp 119

4.1.1 Giai đoạn trước bán hàng 122

4.1.2 Giai đoạn bán hàng 123

4.1.3 Giai đoạn sau bán hàng 124

4.2 Thiết kế cơ sở dữ liệu vật lý 125

4.3 Thiết kế hệ thống phần mềm 141

4.3.1 Các nguyên tắc thiết kế 141

4.3.2 Mô hình dữ liệu 142

4.3.3 Mô hình hệ thống 143

Chương 5 – Thử nghiệm 144

5.1 Môi trường thử nghiệm 144

5.2 Cài đặt chương trình 144

5.3 Giao diện sử dụng 144

5.4 Đánh giá kết quả thử nghiệm 151 TỔNG KẾT 153 TÀI LIỆU THAM KHẢO 155

PHẦN MỞ ĐẦU

Khi cạnh tranh không đơn thuần thông qua đầu tư trang thiết bị, sử dụng dây truyền công nghệ hiện đại không còn là lợi thế riêng của một doanh nghiệp nào đó nữa thì một yếu tố giúp các doanh nghiệp, đặc biệt là doanh nghiệp thuộc lĩnh vực dịch vụ, có thể tạo cho mình lợi thế cạnh tranh không thay thế - đó là mỗi quan hệ lâu dài với khách hàng

Cũng như nhiều người tiêu dùng khác khi đi mua sắm, nếu bạn bước chân vào cửa hàng mà được nhân viên tiếp đón nhiệt tình, nồng hậu thì bao giờ bạn cũng có tâm lý thoải mái khi mua đồ và chắc chắn lần sau nếu có nhu cầu mua sắm bạn cũng sẽ quay lại

Đó là tâm lý chung của người tiêu dùng và các cửa hàng nếu biết khai thác tốt điều đó sẽ

có thể thu được lợi nhuận to lớn từ những vị khách hàng trung thành này

Đúc rút từ kinh nghiệm của những cửa hàng nhỏ lẻ, thì những công ty lớn cũng sẽ cần có những khách hàng trung thành hay những khách hàng tiềm năng như vậy Đặc biệt trong xu hướng hiện nay, số lượng các công ty ngày càng nhiều trong khi lượng khách hàng dường như không thay đổi tương xứng Vì vậy, việc cạnh tranh giữa các doanh nghiệp hay công ty là điều tất yếu và ngày càng quyết liệt tinh vi

Trong thời buổi khủng hoảng hiện nay ảnh hưởng trực tiếp tới nền kinh tế toàn cầu, không loại trừ những tập đoàn kinh tế lớn hay những doanh nghiệp tổ chức vừa và nhỏ Khủng hoảng dù tác động đến cả hai mặt nhưng tập trung chủ yếu vẫn là mặt thiệt hại của nó Không ít những công ty hay tập đoàn kinh tế đã chịu sự phá sản từ những tác động của sự khủng hoảng này Vậy làm thế nào để các doanh nghiệp hay tập đoàn kinh tế còn lại có thể trụ vững và vượt qua được giai đoạn khó khăn hiện tại

Tất yếu công ty hay doanh nghiệp muốn tồn tại thì phải dựa vào khách hàng, càng

có nhiều khách hàng thì công ty hay doanh nghiệp càng có thể thành công lớn Việc mở rộng thị trường kinh doanh và tìm kiếm khách hàng là điều không thể lãng quên và phải đặt lên làm nhiệm vụ hàng đầu Có được khách hàng mới đã là khó khăn nhưng việc giữ chân khách hàng để họ trở thành khách hàng tiềm năng, trung thành thì càng khó khăn gấp bội Điều đó đòi hỏi các doanh nghiệp hay công ty phải làm tốt các khâu ngay từ giai đoạn marketing đến những dịch vụ sau bán hàng

Doanh nghiệp muốn chăm sóc khách hàng tốt nhất trước hết phải nắm được những thông tin cần thiết về khách hàng, về nhu cầu và thị hiếu của họ Mô hình quản lý quan hệ khách hàng CRM đã được ứng dụng phát triển mạnh mẽ và mang lại nhiều lợi ích hơn cho người quản lý và cả doanh nghiệp nói chung

Từ thực tiễn như vậy trong luận văn này đưa ra những nghiên cứu về CRM Customer Relationship Management (Quản lý quan hệ khách hàng) với mong muốn đưa

-ra những cơ sở khoa học dựa trên công nghệ hướng đối tượng về việc quản lý quan hệ khách hàng, đồng thời xây dựng được chương trình thử nghiệm cho những nghiên cứu lý thuyết đạt được

Cấu trúc của Luận văn gồm những nội dung chính như sau:

hệ thống tin học Mô tả chi tiết quy trình phân tích thiết kế hướng đối tượng

Chương 2 - Khái quát về hệ thống quản lý quan hệ khách hàng CRM

Chương này trình bày cơ sở lý thuyết về hệ thống quản lý quan hệ khách hàng CRM của doanh nghiệp, đồng thời mô tả các hoạt động nghiệp vụ của hệ thống CRM tổng quát và cho từng giai đoạn cụ thể

Chương 3 – Đặc tả yêu cầu và các mô hình phân tích hệ thống CRM

Chương này tiến hành quá trình phân tích hệ thống CRM và sử dụng ngôn ngữ mô hình hóa thống nhất để mô tả

Chương 4 – Các mô hình thiết kế hệ thống CRM

Dựa trên những kết quả đã thu nhận được từ quá trình phân tích ở chương 3 để tiến hành thiết kế hệ thống CRM ở chương 4

Chương 5 – Thử nghiệm

Chương này trình bày một số kết quả thử nghiệm từ chương trình demo xây dựng

hệ thống CRM

Kết luận

Chương 1 – Cơ sở lý luận về công nghệ hướng đối tượng và ngôn ngữ mô hình hóa thống nhất UML

1.1 Tổng quan về công nghệ hướng đối tượng và phương pháp mô hình hóa

Ngày nay, trong công nghệ phần mềm nói chung và phần mềm công nghiệp nói riêng, công nghệ hướng đối tượng đóng vai trò then chốt Công nghệ hướng đối tượng không những đã cách mạng hóa phương pháp phân tích thiết kế xây dựng phần mềm, mà còn đổi mới cả tư duy của những người sử dụng Từ khóa “hướng đối tượng” đang trở thành từ mốt, được sử dụng rất phổ biến trong các tiêu đề quảng cáo sản phẩm phần mềm, từ các công cụ lập trình, phần mềm soạn thảo văn bản, xử lý đồ họa tới các hệ thống quản lý cơ sở dữ liệu Vậy, thực chất công nghệ hướng đối tượng là gì?

Mô hình hóa hướng đối tượng

Bất cứ thế giới thực nào cũng đều phức tạp dù đó là thế giới tự nhiên hay thế giới

do con người tạo ra Vậy cách thức con người tiếp cận, tìm hiểu, làm chủ thế giới của mình cũng như việc giao tiếp với nhau thế nào… Tất nhiên, con người thường thông qua các mô hình, dù đó chỉ là những phương trình toán học, các định luật vật lý, những hình ảnh hay thậm chí là lời nói và chữ viết Mô hình là một ánh xạ của thế giới thực, mô tả và phản ánh thế giới thực từ một góc nhìn Mô hình đơn giản hơn thế giới thực rất nhiều, nó chỉ mang những thông tin cần thiết cho một mục đích sử dụng cụ thể Chính vì thế mà thông qua mô hình chúng ta có thể tìm hiểu, bàn luận về vấn đề cần giải quyết, cũng như thiết kế và kiểm chứng giải pháp trước khi tiến hành thực thi Có thể nói, tư duy trên cơ

sở mô hình là phương pháp không thể thiếu được của mỗi người làm khoa học, kỹ thuật Đương nhiên, công nghệ phần mềm cũng không thể thiếu vai trò của các phương pháp

mô hình hóa

Việc mô hình hóa hệ thống phần mềm nhằm mục đích sau: Trừu tượng hóa, đơn giản hóa vấn đề cần giải quyết; Tạo ra phương tiện giao tiếp thống nhất trong nhóm phát triển; Tạo ra phương tiện giao tiếp thuận tiện giữa nhóm phát triển và khách hàng; Tạo ra

cơ sở phân tích, thiết kế và kiểm chứng hệ thống; Tư liệu hóa phần mềm

Mô hình của hệ thống có thể là một bản mô tả cách thức hoạt động, một số công thức toán học, một hoặc vài sơ đồ mô tả thành phần và các hoạt động diễn ra trong hệ thống Việc sử dụng mô hình loại nào để nghiên cứu hệ thống phụ thuộc vào mức độ trừu

tượng hóa được chọn lựa, phụ thuộc vào quan điểm phân tích và phụ thuộc vào công cụ

sử dụng Các mô hình vừa là công cụ nghiên cứu và tìm hiểu hệ thống, vừa là công cụ, ngôn ngữ để trao đổi và là công cụ để điều chỉnh, hoàn thiện hệ thống

Việc trừu tượng hóa thế giới tự nhiên thành các lớp đối tượng được gọi là mô hình hóa hướng đối tượng

Trong thế giới luôn biến động của các ứng dụng hướng đối tượng thì việc phát triển và bảo trì các ứng dụng có chất lượng cao trong một khoảng thời gian hợp lý ngày càng trở nên khó khăn hơn Một tổ chức phát triển phần mềm thành công là tổ chức xây dựng được các phần mềm có chất lượng, thỏa mãn tốt những yêu cầu của khách hàng

Mô hình hóa được đánh giá là phần trung tâm trong mọi công việc, các hoạt động để dẫn tới việc có được một phần mềm tốt Thông qua mô hình có thể dùng để trao đổi, bàn bạc

về cấu trúc và ứng xử mong muốn của hệ thống Đồng thời qua mô hình để trực quan hóa

và kiểm soát kiến trúc hệ thống Mặt khác việc sử dụng mô hình có thể mô tả các cấu trúc, nhấn mạnh về mặt tổ chức của hệ thống hoặc mô tả các hành vi ứng xử, tập trung vào những mặt động của hệ thống

Việc xây dựng mô hình không chỉ dành riêng cho các hệ thống lớn, mà nó mang lại nhiều lợi ích cho tất cả các hệ thống khác nhau Nhìn chung, khi xây dựng mô hình sẽ đạt được những mục đích sau:

 Mô hình giúp trực quan hóa hệ thống như theo cách nó vốn có hay là theo cách mà chúng ta muốn nó sẽ như vậy

 Mô hình chỉ rõ các cấu trúc và ứng xử của hệ thống

 Mô hình giúp chúng ta có được một khuôn mẫu để hướng dẫn chúng ta trong suốt quá trình xây dụng hệ thống

 Mô hình đưa ra các dẫn chứng bằng tài liệu về các quyết định mà chúng ta đã đưa

ra trong quá trình thiết kế hệ thống

Thông qua mô hình hóa, chúng ta thu hẹp bài toán mà chúng ta cần nghiên cứu bằng cách chỉ tập trung vào một khía cạnh tại một thời điểm Tùy thuộc vào đặc điểm tự nhiên của hệ thống, mỗi mô hình có thể tập trung vào những mặt khác nhau của hệ thống

đó Chẳng hạn, hệ thống tập trung vào dữ liệu thì các mô hình về phần thiết kế tĩnh của

hệ thống được chú ý hơn Nhưng nếu hệ thống giao diện người dùng thì phần tĩnh và phần động của các ca sử dụng sẽ là quan trọng Đối với hệ thống thời gian thực, các tiến trình động là quan trọng Và cuối cùng, trong hệ thống phân tán dựa trên cơ sở Web thì các mô hình về thực thi và triển khai là quan trọng nhất

Phân tích, thiết kế hướng đối tượng

Công nghệ phần mềm không chỉ là lập trình, mà còn nhiều bước khác nữa như phân tích, thiết kế và bảo trì Theo dòng phát triển công nghệ phần mềm, phương pháp lập trình đã tiến hóa từ lập trình tuần tự lên lập trình có cấu trúc và lập trình hướng đối tượng Phương pháp phân tích, thiết kế phần mềm cũng đi theo các bước tiến hóa này Phương pháp phân tích, thiết kế phần mềm tiên tiến hiện nay là hướng đối tượng, trong

đó khối cơ bản để xây dựng nên phần mềm là đối tượng hay lớp Nói một cách đơn giản, đối tượng là sự phản ánh thế giới tự nhiên xung quanh Ưu điềm lớn nhất của phân tích, thiết kế phần mền hướng đối tượng không phải nằm ở chỗ tạo ra chương trình nhanh tốn

ít công sức, mà nằm ở chỗ nó gần với thực tế và do đó thúc đẩy việc tái sử dụng lại những thành quả đã được xây dựng trước đó

Lập trình hướng đối tượng

Với đa số người quan tâm thì khái niệm hướng đối tượng chỉ mới dừng lại là một phương pháp lập trình ở mức trừu tượng cao hơn lập trình hướng cấu trúc Rõ ràng, xu hướng phát triển của các ngôn ngữ lập trình là hướng dần tới tư duy người lập trình và thoát khỏi sự lệ thuộc vào máy tính cụ thể Điều đó có nghĩa là, người lập trình có thể biểu diễn thế giới thực và ý tưởng của mình thông qua ngôn ngữ lập trình một cách tự nhiên hơn, trực tiếp hơn là phụ thuộc vào từng câu lệnh, thanh ghi hay ô nhớ theo cách thức làm việc của vi xử lý Dù lập trình hướng cấu trúc khiến cho việc lập trình trở nên dễ dàng hơn, hiệu quả hơn nên mã chương trình có độ tin cậy cao hơn và tính khả chuyển cao hơn Tuy nhiên, lập trình hướng cấu trúc vẫn gặp nhiều khó khăn với các dự án lớn bởi tư duy còn gắn nhiều với cấu trúc dữ liệu cụ thể, tính mềm dẻo và khả năng sử dụng lại tương đối thấp của mô hình phân tích, thiết kế cũng như mã chương trình Trong khi

đó, yêu cầu của thị trường ngày càng khắt khe cả về mở rộng phạm vi chức năng, tính thân thiện người sử dụng, độ tin cậy của phần mềm cũng như khung thời gian ra sản phẩm

Lập trình hướng đối tượng được coi là phương pháp lập trình chuẩn hiện nay trong

đa số các lĩnh vực ứng dụng bởi nó có nhiều ưu điểm lớn so với các phương pháp cổ điển Mục tiêu mà lập trình hướng đối tượng đặt ra: Đơn giản hóa việc sử dụng các thư viện, cho phép sử dụng lại phần mềm một cách triệt để, nâng cao độ tin cậy và tính bền vững của phần mềm, hỗ trợ các dự án phát triển phần mềm có quy mô lớn đòi hỏi nhiều người tham gia, cải thiện khả năng bảo trì của mã nâng tính mềm dẻo linh hoạt của phần mềm

Như vậy, công nghệ hướng đối tượng là tất cả công nghệ và kỹ thuật phần mềm dựa trên nền tảng là phương pháp luận hướng đối tượng Nền tảng này bao gồm: mô

hình hóa hướng đối tượng, phân tích và thiết kế hướng đối tượng, lập trình hướng đối tượng Dựa trên mô hình đối tượng thu được khi mô hình hóa hệ thống, phương pháp phân tích thiết kế phần mềm hướng đối tượng sẽ bổ sung thêm các liên kết và lớp đối tượng mới, tinh chỉnh lại… để rạo ra mô hình đối tượng chi tiết của phần mềm Cuối cùng người sử dụng một ngôn ngữ lập trình nào đó (không nhất thiết phải mà ngôn ngữ hướng đối tượng) thể hiện mô hình đối tượng chi tiết thành mã nguồn

1.2 Ngôn ngữ mô hình hóa thống nhất UML

1.2.1 Lịch sử phát triển của UML

Đầu những năm 1980, ngành công nghệ phần mềm chỉ có duy nhất một ngôn ngữ hướng đối tượng là Simula Sang nửa sau thập niên 80, các ngôn ngữ hướng đối tượng như Smaltalk và C++ xuất hiện Cùng với chúng, nhu cầu mô hình hóa các hệ thống phần mềm theo hướng đối tượng đã nảy sinh Vào khoảng đầu thập niên 90, một số ngôn ngữ

mô hình hóa xuất hiện và được nhiều người sử dụng như: Grady Booch’s Mooch Modeling Methodology, James Rambaugh’s Object Modeling Technique – OMT,…

Mỗi phương pháp và ngôn ngữ trên đều có hệ thống ký hiệu riêng, phương pháp

xử lý và công cụ hỗ trợ khác nhau nên đều có những điểm mạnh và yếu riêng Từ đó khiến nảy ra cuộc tranh luận phương pháp nào là tốt nhất Trong thực tế, sự khác biệt giữa các phương pháp đó hầu như không đáng kể Hơn nữa, việc ký hiệu khác nhau của các phương pháp đã gây ra sự mập mờ, nhầm lẫn khi mà chỉ một ký hiệu có thể mang những ý nghĩa khác nhau trong mỗi phương pháp Thời kỳ này còn được biết đến với tên gọi cuộc chiến giữa các phương pháp Tuy nhiên theo tiến trình thời gian, tất cả những phương pháp này đã tiệm cận lại và bổ sung lẫn nhau Trong bối cảnh trên, người ta nhận thấy cần thiết phải cung câp một phương pháp mô hình hóa chuẩn và thống nhất cho việc

mô hình hóa hướng đối tượng

Nhận thấy được sự bất hợp lý này, hai nhà lý luận tiên phong là James Rumbaugh (với ngôn ngữ OMT) và Gray Booch (với ngôn ngữ Booch’94) đã kết hợp cùng công ty Rational Rose để tìm cách đưa ra một phương pháp mô hình hóa thống nhất mang tên

UM (Unified Method) Song chỉ một thời gian ngắn sau hai vị đã kịp nhận ra rằng khó có thể thống nhất một phương pháp, mà chỉ có thể thống nhất một ngôn ngữ mô hình hóa Cái tên ngôn ngữ mô hình hóa thống nhẩt UML (Unified Modeling Language) ra đời từ

đó Đó là do sự hợp nhất các cách ký hiệu của Booch, OMT và Objectory cũng như những ý tưởng tốt nhất của một số phương pháp khác

Bằng cách hợp nhất các ký hiệu sử dụng trong phân tích, thiết kế của các phương pháp đó, UML cung cấp một nền tảng chuẩn trong việc phân tích thiết kế Có nghĩa là các nhà phát triển vẫn có thể tiến hành theo phương pháp mà họ đang sử dụng hoặc có thể tiến hành theo một phương pháp tổng hợp hơn do thêm vào những bước ưu điểm của từng phương pháp Cùng với sự cộng tác sau này của Ivar Jacobson (nổi tiếng với use case) và nhiều đồng nghiệp khác, UML đã trở thành một chuẩn quốc tế được quản lý bởi

tổ chức OMG (Object Management Group) và đang trong tiến trình trở thành một chuẩn ISO

1.2.2 UML là gì?

Unified Modeling Language (viết tắt là UML) là một ngôn ngữ dùng để:

Trực quan hóa

Cụ thể hóa

Sinh mã ở dạng nguyên mẫu

Lập và cung cấp tài liệu [2]

1.2.3 Mô hình khái niệm của UML

Để hiểu rõ hơn về UML ta phải hình dung được mô hình khái niệm của ngôn ngữ

Nó đòi hỏi nắm được ba vấn đề chính như sau:

Các phần tử cơ bản để xây dựng mô hình

Quy tắc liên kết các phần tử mô hình

Một số cơ chế chung sử dụng cho ngôn ngữ

Khi nắm được những vấn đề này thì ta có thể đọc được mô hình UML và tạo ra một số mô hình cơ bản Để hình thành mô hình UML gồm ba khối như sau: phần tử, quan

hệ và biểu đồ Phần tử là trừu tượng căn bản trong mô hình; các quan hệ gắn kết những phần tử này lại với nhau còn biểu đồ nhóm tập hợp các phần tử [1]

1.2.3.1 Phần tử mô hình trong UML

Trong UML có bốn loại phần tử mô hình, đó là phần tử cấu trúc, phần tử hành vi, phần tử nhóm và phần tử chú thích Các phần tử này là các khối để xây dựng hướng đối tượng cơ bản của UML

a Phần tử cấu trúc

Phần tử cấu trúc là các danh từ trong mô hình UML Chúng là bộ phận tĩnh của

mô hình, dùng để biểu diễn các thành phần khái niệm hay vật lý Bao gồm:

Lớp (Class)

Lớp là tập hợp các đối tượng (object) có cùng một tập thuộc tính, các thao tác, các mối quan hệ và ngữ nghĩa với các đối tượng khác

Giao diện (Interface)

Giao diện là tập hợp các thao tác (operation) tạo nên dịch vụ của mộ lớp hoặc một

tả tương tác giữa tác nhân và hệ thống đang xây dựng, nó thể hiện chức năng mà

hệ thống sẽ cung cấp cho tác nhân Tập hợp các ca sử dụng của hệ thống sẽ tạo nên tất cả các trường hợp mà hệ thống có thể sử dụng được Nó được hiện thực

hóa bởi phần tử cộng tác như vừa mô tả trên

Lớp tích cực (Active class)

Lớp tích cực là lớp mà các đối tượng của nó thực hiện các hoạt động điều khiển,

có đối tượng làm chủ một hay nhiều tiến trình (process) hay luồng (thread) Lớp tích cực cũng giống như lớp thông thường ngoại trừ việc các đối tượng của nó thể

hiện các thành phần có hành vi đang tương tranh hay có thể thực hiện đồng thời với các thành phần khác Lớp này thường dùng để biểu diến tiến trình (process) và

luồng (thread)

Thành phần (Component)

Thành phần là biểu diễn vật lý của mã nguồn Trong hệ thống ta sẽ thấy các kiểu khác nhau của thành phần như các thành phần COM+ hay JavaBeans cũng như các thành phần như các file mã nguồn, các file nhị phân tạo ra trong quá trình phát

Tương tác (Interaction)

Tương tác là hành vi bao gồm tập các thông điệp (message) trao đổi giữa các đối tượng trong một ngữ cảnh cụ thể để thực hiện một mục đích cụ thể Hành vi của

nhóm đối tượng hay của mỗi thao tác có thể được chỉ ra bằng tương tác

Máy trạng thái (States machine)

Máy trạng thái là hành vi chỉ ra trật tự các trạng thái mà đối tượng hay tương tác

sẽ đi qua để đáp ứng sự kiện Hành vi của lớp hay cộng tác của lớp có thể được xác định bằng máy trạng thái Máy trạng thái kích hoạt nhiều phần tử, bao gồm trạng thái, chuyển tiếp từ trạng thái này sang trạng thái khác, sự kiện và các hoạt động đáp ứng sự kiện Ký pháp đồ họa của nó bao gồm tên và trạng thái con nếu

có

c Phần tử nhóm

Phần tử nhóm là bộ phận tổ chức của mô hình UML Chỉ có một phần tử thuộc nhóm này là gói (Package)

Gói (Package)

Gói là cơ chế đa năng dùng để tổ chức các phần tử có một ý nghĩa chung nào đó

vào thành nhóm

d Phần tử chú thích (Annotational)

Phần tử chú thích là bộ phận chú giải của mô hình UML

1.2.3.2 Các quan hệ trong UML

Có bốn loại quan hệ trong UML, bao gồm quan hệ phụ thuộc, kết hợp, khái quát hóa và hiện thực hóa Chúng là các khối cơ sở để xây dựng mọi mối quan hệ trong UML

a Quan hệ Phụ thuộc (Dependency)

Quan hệ phụ thuộc là quan hệ ngữ nghĩa giữa hai phần tử trong đó thay đổi phần

tử độc lập sẽ tác động ảnh hưởng tới phần tử phụ thuộc

b Quan hệ Kết hợp (Association)

Kết hợp là quan hệ cấu trúc chỉ ra mối liên kết giữa hai lớp, trong đó mỗi liên kết

là kết nối giữa các đối tượng Hay nói một cách đơn giản, khi một đối tượng của lớp này gửi thông điệp tới hoặc nhận thông điệp từ một đối tượng của lớp kia thì ta nói giữa hai

Quan hệ Khái quát hóa (Generalization)

Khái quát hóa là mối quan hệ tổng quát hóa, cụ thể hóa mà trong đó đối tượng cụ

thể sẽ kế thừa các thuộc tính và hành vi của đối tượng tổng quát hóa

Quan hệ hiện thực hóa (Realization)

Hiện thực hóa là quan hệ ngữ nghĩa giữa giao diện (interface) và lớp (class) hay thành phần (component) hiện thực lớp, giữa use case và phần tử cộng tác

(collaboration) hiện thực use case đó

1.2.3.3 Các biểu đồ trong UML

Biểu đồ là biểu diễn đồ họa tập các phần tử mô hình Vẽ biểu đồ để biểu diễn hệ thống đang xây dựng dưới những góc độ quan sát khác nhau Có thể hiểu biểu đồ chính là ánh xạ của hệ thống Một phần tử có thể xuất hiện trong một hay nhiều biểu đồ Về lý thuyết thì biểu đồ có thể bao gồm tổ hợp vô số phần tử đồ họa và quan hệ vừa mô tả ở trên UML cho khả năng xây dựng một số kiểu biểu đồ trực quan để biểu diễn các khía cạnh khác nhau của hệ thống [1]

a Biểu đồ ca sử dụng (Use case diagram)

Biểu đồ này chỉ ra tương tác giữa các ca sử dụng (use case) và các tác nhân (actor) Ca sử dụng (use case) biểu diễn các chức năng của hệ thống, trong khi, tác nhân

là con người hay hệ thống khác cung cấp hay thu nhận thông tin từ hệ thống đang được xây dựng Biểu đồ ca sử dụng tập trung vào quan sát trạng thái tĩnh của các ca sử dụng trong hệ thống Nó đặc biệt quan trọng trong việc tổ chức và mô hình hóa hệ thống.Vì ca

sử dụng biểu diễn yêu cầu hệ thống từ góc độ người dùng, cho nên ca sử dụng là chức năng mà hệ thống phải có Biểu đồ này chỉ ra tác nhân nào khởi động ca sử dụng nào và khi nào tác nhân nhận thông tin từ hệ thống

Biểu đồ ca sử dụng chỉ ra chức năng tổng thể của hệ thống đang xây dựng Thông qua biểu đồ này, khách hàng, quản trị dự án, phân tích viên, lập trình viên, kỹ sư kiểm tra chất lượng và những ai quan tâm tổng thể đến hệ thống đều có thể biết được hệ thống sẽ

hỗ trợ gì thông qua biểu đồ này

b Biểu đồ trình tự (Sequence diagram)

Biểu đồ trình tự là một dạng biểu đồ tương tác (interaction), trong đó chỉ ra luồng chức năng xuyên qua các ca sử dụng (use case), nó biểu diễn sự tương tác giữa các đối tượng và tập trung vào mô tả trật tự thông điệp theo thời gian Nó mô tả các đối tượng

liên quan trong một tình huống cụ thể và các bước tuần tự trong việc trao đổi các thông điệp giữa các đối tượng đó để thực hiện một chức năng cụ thể nào đó

Biểu đồ trình tự có ích cho mọi người tham gia dự án Khách hàng có thể thấy được tiến trình tác nghiệp cụ thể của họ; phân tích viên thấy được luồng tiến trình, người phát triển thấy được các đối tượng cần xây dựng và các thao tác cho các đối tượng này;

kỹ sư kiểm tra chất lượng hệ thống có thể thấy chi tiết của tiến trình để xây dựng quy trình thử nghiệm…

c Biểu đồ cộng tác (Collaboration diagram)

Biểu đồ cộng tác chỉ ra các thông tin như biểu đồ trình tự, nó là một cách khác thể hiện một tình huống có thể xảy ra trong hệ thống Nhưng nó tập trung vào việc thể hiện việc trao đổi qua lại các thông điệp giữa các đối tượng chứ không quan tâm đến thứ tự của các thông điệp đó Điều đó có nghĩa rằng qua biểu đồ cộng tác chúng ta biểu được nhanh chóng giữa hai đối tượng cụ thể nào đó có trao đổi những thông điệp gì với nhau Biểu đồ cộng tác và biểu đồ trình tự thuộc loại biểu đồ tương tác và chúng có thể biến đổi qua lại với nhau Trong biểu đồ cộng tác, đối tượng đặt trong chữ nhật và tác nhân là người hình cây như trong biểu đồ trình tự, các đối tượng giao tiếp trực tiếp với nhau được thể hiện bằng đường gạch nối

Tuy rằng biểu đồ cộng tác cũng chỉ ra các thông tin như biểu đồ trình tự, nhưng biểu đồ cộng tác được sử dụng vì mục đích khác Thông qua biểu đồ này, kỹ sư kiểm tra chất lượn và kiến trúc sư hệ thống thấy được việc phân bổ tiến trình giữa các đối tượng Chẳng hạn, nếu biểu đồ cộng tác có hình dạng phức tạp như ngôi sao, với nhiều đối tượng giao tiếp với đối tượng trung tâm thì kiến trúc sư có thể kết luận rằng hệ thống quá phụ thuộc vào một đối tượng và họ sẽ đi thiết kế lại phân bổ tiến trình để nâng cao hiệu suất hệ thống

d Biểu đồ lớp (Class diagram)

Biểu đồ lớp chỉ ra tương tác giữa các lớp trong hệ thống, bao gồm một tập hợp các lớp, các giao diện, các thành phần cộng tác và mối quan hệ giữa chúng Các lớp được xem như kế hoạch chi tiết của các đối tượng Người phát triển sử dụng biểu đồ lớp để xây dựng các lớp Các công cụ phần mềm phát sinh mã trình xương sống cho các lớp, sau đó người phát triển phải chi tiết hóa bằng ngôn ngữ lập trình Kiến trúc sư quan sát thiết kế

hệ thống thông qua biểu đồ lớp Nếu trên biểu đồ thấy một lớp chứa quá nhiều chức năng thì phải chia chúng ra nhiều lớp khác nhau Kiến trúc sư cũng dễ phát hiện ra nếu giữa các lớp thiếu giao tiếp

e Biểu đồ chuyển trạng thái (State transition)

Biểu đồ trạng thái mô tả vòng đời của đối tượng, từ khi nó được sinh ra cho đến khi bị phá hủy, nó chỉ ra một máy chuyển trạng thái bao gồm các trạng thái, các bước chuyển trạng thái và các hoạt động Biểu đồ chuyển trạng thái cung cấp cách thức mô hình hóa các trạng thái khác nhau của đối tượng Trong khi biểu đồ lớp cung cấp bức tranh tĩnh về các lớp và quan hệ của chúng thì biểu đồ chuyển trạng thái đươc sử dụng để

mô hình hóa các hành vi động của hệ thống Biểu đồ chuyển trạng thái đặc biệt quan trọng trong việc mô hình hóa hành vi của một lớp giao diện (interface class) hay thành phần cộng tác (collaboration) và nó nhấn mạnh vào các đáp ứng theo sự kiện của một đối tượng, điều này rất hữu ích khi mô hình hóa một hệ thống phản ứng (reactive) Thông thường, không tạo lập biểu đồ chuyển trạng thái cho mọi lớp mà chỉ sử dụng cho các lớp phức tạp Nếu đối tượng của lớp tồn tại trong nhiều trạng thái và có ứng xử khác nhau trong mỗi trạng thái thì nên xây dựng biểu đồ chuyển trạng thái cho chúng Nhiều dự án không quan tâm đến loại biểu đồ này, thường nó dùng cho việc làm tài liệu

f Biểu đồ hoạt động (Activity)

Biểu đồ hoạt động là một dạng đặc biệt của biểu đồ chuyển trạng thái Nó chỉ ra luồng đi từ hoạt động này sang hoạt động khác trong hệ thống Nó đặc biệt quan trọng trong việc xây dựng mô hình chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi quyền kiểm soát giữa các đối tượng

g Biểu đồ thành phần (Component)

Biểu đồ thành phần cho ta cái nhìn vật lý của mô hình, chỉ ra cách tổ chức và sự phụ thuộc của các thành phần (component) Biểu đồ thành phần cho thấy các thành phần phần mềm trong hệ thống và quan hệ giữa chúng Nó liên quan tới biểu đồ lớp, trong đó một thành phần thường ánh xạ tới một hay nhiều lớp, giao diện và thành phần cộng tác Biểu đồ lớp thích hợp cho những ai quan tâm đến việc dịch chương trình Nó cho thấy trình tự dịch của các modun trong hệ thống Đồng thời nó cũng cho biết rõ thành phần nào được tạo ra trong quá trình chạy chương trình

h Biểu đồ triển khai (Deployment)

Biểu đồ triển khai chỉ ra cấu hình hệ thống khi thực thi, những bố trí vật lý của hệ thống mạng và các thành phần thiết bị khác Thông qua biểu đồ triển khai mà người quản

lý dự án, người sử dụng, kiến trúc sư và đội ngũ triển khai hiểu phân bổ vật lý của hệ thống và các hệ thống con sẽ được đặt ở đâu

1.3 Quy trình phân tích thiết kế hệ thống hướng đối tượng

1.3.1 Xây dựng mô hình nghiệp vụ

Việc đi tới nắm bắt rành mạch, rõ ràng về hệ thống cần tin học hóa cần xuất phát

từ việc tìm hiểu và nghiên cứu về hệ thống thực Công việc tìm hiểu này được tiến hành bằng cách tìm hiểu hoạt động nghiệp vụ và xây dựng các mô hình miền và mô hình nghiệp vụ để nắm bắt được toàn bộ các vấn đề liên quan đến nghiệp vụ của hệ thống

Việc tìm hiểu quy trình nghiệp vụ của hệ thống được tiến hành qua các bước sau: Tìm hiểu bối cảnh hệ thống

Nắm bắt những yêu cầu bổ sung, các yêu cầu phi chức năng

a Tìm hiểu bối cảnh hệ thống

Mô tả bối cảnh hệ thống bằng cách xây dựng mô hình miền và mô hình nghiệp vụ của nó Tùy theo yêu cầu của từng loại bài toán cụ thể mà ta có thể xây dựng mô hình miền, mô hình nghiệp vụ đầy đủ hay cả hai mô hình trên, có đôi khi lại không cần mô hình nào cả

Xây dựng mô hình miền (domain model)

Mục đích của mô hình hóa miền là để hiểu và mô tả các lớp quan trọng nhất trong bối cảnh của miền Có thể lập một từ điển giải thích để định nghĩa các lớp miền Thông qua từ điển giải thích và mô hình miền giúp khách hàng và những người phát triển hệ thống chia sẻ những thuật ngữ và khái niệm chung Đối với những miền nghiệp vụ nhỏ thì có thể chỉ sử dụng từ điển thuật ngữ là đủ mà không cần xây dựng mô hình miền Mô hình miền có thể mô tả bằng nhiều biểu đồ lớp của UML

Xây dựng mô hình nghiệp vụ

Một mô hình nghiệp vụ có thể được phát triển qua hai bước: Thứ nhất, Xây dựng mô hình ca sử dụng nghiệp vụ bao gồm việc xác định các tác nhân nghiệp vụ

và các ca sử dụng mà các tác nhân sử dụng Thông qua mô hình này người phát triển hiểu rõ hơn về giá trị mà nghiệp vụ đem lại cho các tác nhân sử dụng nó Thứ hai, Phát triển một mô hình đối tượng nghiệp vụ bao gồm những người tham gia nghiệp vụ, các thực thể nghiệp vụ và các đơn vị công việc cùng nhau thực hiện các

ca sử dụng nghiệp vụ Các quy tắc nghiệp vụ và các điều chỉnh khác trong nghiệp

vụ được liên kết với các đối tượng khác

b Nắm bắt những yêu cầu bổ sung

Các yêu cầu bổ sung là những yêu cầu phi chức năng mà không thể liên kết với bất

kỳ ca sử dụng nghiệp vụ cụ thể nào Chúng có thể ảnh hưởng đồng thời đến nhiều ca sử dụng nhưng cũng có thể không ảnh hưởng đến bất kỳ ca sử dụng nào Chẳng hạn, các giao diện, các yêu cầu thiết kế vật lý và kiến trúc, các rang buộc về thiết kế và cài đặt…

1.3.2 Xác định yêu cầu

Từ những yêu cầu của khách hàng, chúng ta xác định được mục tiêu của hệ thống cần thực hiện Thường đó là các yêu cầu chức năng về những gì mà hệ thống phải thực hiện, nhưng chưa cần chỉ ra các chức năng đó thực hiện như thế nào Việc xác định đúng

và đầy đủ yêu cầu bài toán là nhiệm vự hết sức quan trọng, nó làm cơ sở cho tất cả các bước tiếp theo trong dự án phát triển phần mềm Muốn vậy, thì phải thực hiện đặc tả chi tiết các yêu cầu của hệ thống UML cung cấp biểu đồ ca sử dụng để đặc tả các yêu cầu của hệ thống [1]

Các bước trong luồng công việc xác định yêu cầu được mô tả chi tiết như sau:

Tìm các ca sử dụng

Mỗi cách thức mà tác nhân sử dụng hệ thống được gọi là một ca sử dụng

Có thể coi một ca sử dụng đặc tả một chuỗi các hành động, kể cả một chuỗi các hành động thay thế mà hệ thống có thể thực hiện khi tương tác với tác nhân của

nó Một thể hiện ca sử dụng là sự thực hiện hoặc xử lý của ca sử dụng đó

Mô tả ngắn gọn mỗi ca sủ dụng

Sau khi tìm được các ca sử dụng, trước hết mô tả ngắn gọn để tóm tắt các hành động của ca sử dụng Sau này sẽ mô tả chi tiết dần

Các bước mô tả trên đây không bắt buộc phải thực hiện theo thứ tự mà thường được thực hiện đồng thời Kết quả của hoạt động này là một phiên bản của mô hình ca sử dụng với các tác nhân và các ca sử dụng

1.3.2.2 Sắp xếp thứ tự ưu tiên các ca sử dụng

Mục đích của hoạt động này là nhằm lập thứ tự ưu tiên các ca sử dụng để quyết định những ca sử dụng nào cần được triển khai ngay trong những lần lặp đầu và chúng đòng vai trò gì trong kiến trúc hệ thống

1.3.2.3 Mô tả chi tiết một ca sử dụng

Mục đích chính của việc mô tả chi tiết ca sử dụng là mô tả luồng các sự kiện của

ca sử dụng một cách chi tiết, xuất phát điểm từ khi khởi động, tương tác với các tác nhân thế nào đến khi kết thúc Để mô tả chi tiết ca sử dụng có thể mô tả bằng văn bản, bằng bảng hay các biểu đồ ca sử dụng kèm theo Với chú ý rằng, những tương tác trong luồng

sự kiện ở đây chỉ mô tả hoạt động bề ngoài của hệ thống mà một tác nhân có thể nhận biết được từ hệ thống, còn việc làm thế nào để hệ thống đáp ứng lại các tương tác đó cho đến lúc này vẫn hoàn toàn chưa biết

a Cấu trúc của một mô tả ca sử dụng

Cấu trúc của một mô tả ca sử dụng thường được tổ chức sao cho cả người phát triển, khách hàng và người dùng có thể hiểu được Một ca sử dụng cần có cấu trúc như sau:

 Trạng thái xuất phát (tiền điều kiện)

 Làm thế nào và khi nào thì ca sử dụng khởi động (tức hành động thứ nhất được thực hiện như thế nào?)

 Các chuỗi hành động phải được thực hiện theo thứ tự được xác định bởi chuỗi hành động đã đánh số

 Ca sử dụng kết thúc khi nào và như thế nào

 Trạng thái kết thúc (hậu điều kiện)

 Các con đường không được phép thực hiện

 Mô tả các con đường cơ bản mà dãy hành động xảy ra

 Mô tả các con đường ngoại lệ

Một nhiệm vụ quan trọng nữa là đặc tả những yêu cầu phi chức năng Đa số những yêu cầu phi chức năng đều liên quan đến một ca sử dụng cụ thể nào đó, ví dụ các yêu cầu

về tốc độ thực hiện, độ chính xác, tính khả dụng… Các yêu cầu như vậy được coi như là các yêu cầu đặc biệt của ca sử dụng đang xem xét Ta có thể chuẩn bị chúng như một phần của tài liệu mô tả ca sử dụng

b Hình thức hóa các mô tả ca sử dụng

Đối với những ca sử dụng phức tạp, có nhiều trạng thái và sự chuyển tiếp, thì hình thức mô tả bằng văn bản hay dùng bảng thường không đảm bảo được tính nhất quán và làm cho người phát triển khó hình dung Do vậy, có thể hình thức hóa các mô tả ca sử dụng bằng các biểu đồ có tính trực quan hơn, chẳng hạn biểu đồ trạng thái UML, biểu đồ hoạt động hay các biểu đồ tương tác

1.3.2.4 Tạo bản mẫu Giao diện người dùng

Việc phác thảo các giao diện người dùng giúp cho người dùng thực hiện các ca sử dụng một cách hiệu quả Với mỗi ca sử dụng, ta cố gắng nhận biết xem cái gì là cần đối với giao diện người dùng để tạo khả năng cho mỗi tác nhân dùng các ca sử dụng Công việc này gọi là thiết kế giao diện người dùng logic Sau đó ta tạo thiết kế giao diện người dùng thực và phát triển các bản mẫu để minh họa cách thức mà các người dùng có thể dùng hệ thống để thực hiện các ca sử dụng

1.3.2.5 Tái cấu trúc mô hình ca sử dụng

Mục đích của việc tái cấu trúc mô hình ca sử dụng là: Thứ nhất, tìm ra các mô tả chức năng có đặc tính chung được chia sẻ trong nhiều ca sử dụng để tách ra mô tả riêng Thứ hai, tìm ra các chức năng phụ hoặc tùy chọn để mở rộng mô tả chức năng thành các chức năng mới nhằm làm phong phú thêm các yêu cầu của hệ thống

Kết quả chính của pha phân tích hệ thống hướng đối tượng là biểu đồ lớp (sơ lược), biểu đồ trạng thái, biểu đồ trình tự, biểu đồ hành động [1]

Khi nắm bắt các yêu cầu ta đã nắm bắt các yêu cầu chức năng dưới dạng các ca sử dụng và các yêu cầu phi chức năng dưới dạng các tài liệu bổ sung cho các tài liệu mô tả

ca sử dụng Tuy nhiên, do các yêu cầu đã được diễn đạt bằng các ngôn ngữ không chính xác của khách hàng nên vẫn còn nhiều vấn đề tồn tại chưa giải quyết được về yêu cầu của

hệ thống Chính vì điều đó ta cần phân tích những yêu cầu bằng cách sử dụng các ngôn ngữ của nhà phát triển để mô tả kết quả thực nhận được và ta sẽ nhận được mô hình phân tích

Phân tích hướng đối tượng là giai đoạn phát triển một mô hình chính xác và súc tích của vấn đề, có thành phần là các đối tượng và khái niệm thực tế, dễ hiểu với người sử dụng Trong giai đoạn này, vấn đề được trình bày bằng thuật ngữ tương ứng với các đối tượng có thực Dựa trên những vấn đề có sẵn, nhà phân tích ánh xạ các đối tượng hay thực thể có thực như khách hàng, nhân viên bán hàng, … vào thiết kế để tạo ra được bản thiết kế gần cận với tình huống thực tế Mô hình thiết kế sẽ chứa các thực thể trong một vấn đề có thực và giữ nguyên các mẫu hình về cấu trúc, quan hệ cũng như hàng vi của chúng Nói cách khác, sử dụng phương pháp hướng đối tượng chúng ta có thể mô hình hóa các thực thể thuộc một vấn đề có thực mà vẫn giữ được cấu trúc, quan hệ cũng như hành vi của chúng Như vậy, ta chú ý đến cả hai khía cạnh là thông tin và cách hoạt động của hệ thống tức là những gì có thể xảy ra với những thông tin đó Kiểu phân tích bằng ánh xạ thực vào máy tính chính là một ưu điểm lớn của phương pháp hướng đối tượng

Mô hình phân tích là một mô hình đối tượng khái niệm Nó xác định các yêu cầu

và suy luận về cấu trúc nội tại của hệ thống Mô hình phân tích được thể hiện ở mức cao bằng hệ thống các gói phân tích Trong mô hình phân tích, các ca sử dụng được thực thi bởi các lớp và các đối tượng phân tích Trong mô hình phân tích ta tập trung vào mô tả hoạt dộng bên trong của hệ thống đã thực thi ca sử dụng như thế nào với sự cộng tác của các đối tượng logic

Để tạo ra mô hình phân tích cần tiến hành:

1.3.3.1 Phân tích kiến trúc

Mục đích của phân tích kiến trúc là phác họa những nét lớn của mô hình phân tích thông qua việc xác định các gói phân tích, các lớp phân tích hiển nhiên và các yêu cầu chuyên biệt chung

Lớp điều khiển là các lớp thể hiện sự phối hợp, sắp trình tự, các giao dịch, sự điều khiển của các đối tượng và thường được sử dụng để bao gói điều khiển liên quan đến một

ca sử dụng cụ thể Các khía cạnh động của hệ thống được mô hình hóa qua các lớp điều khiển

Lớp thực thể được dùng để mô hình hoác các thông tin tồn tại lâu dài và có thể được lưu trữ Các lớp thực thể thường được thể hiện các cấu trúc logic và góp phần làm

rõ về các thông tin mà hệ thống cần dựa vào

Lớp biên thường được sử dụng để mô hình hóa tương tác của hệ thống với các tác nhân của nó Tương tác này gồm việc nhập và hiển thị thông tin từ các yêu cầu của người dùng và các hệ thống ngoài Mỗi lớp biên liên quan đến ít nhất một tác nhân và ngược lại

Chúng ta sẽ xác định các lớp điều khiển, lớp thực thể và lớp biên cần thiết cho việc thực thi ca sử dụng và phác thảo các tên gọi, các trách nhiệm, các thuộc tính và các mối quan hệ của chúng

b Mô tả các tương tác giữa các đối tượng phân tích

Khi đã có những phác thảo về các lớp phân tích cần thiết để thực thi các ca sử dụng, chúng ta cần phải mô tả cách thức mà các đối tượng phân tích tương tác với nhau như thế nào Việc này được thực hiện bằng các biểu đồ cộng tác, chúng chứa các thể hiện của tác nhân tham gia, các đối tượng phân tích và các mối liên kết giữa chúng

Một biểu đồ cộng tác xuất phát từ một điểm khởi đầu của luồng sự kiện ca sử dụng, sau đó đi theo luồng từng bước và xác định xem đối tượng phân tích nào và các tương tác của các thể hiện tác nhân nào là cần thiết để thực thi ca sử đụng đó Trong một vài trường hợp, có thể bổ sung các mô tả bằng văn bản cho các biểu đồ cộng tác, đặc biệt nếu có nhiều biểu đồ thực thi cùng một ca sử dụng hoặc nếu các biểu đồ trình bày các luồng phức tạp

c Nắm bắt các yêu cầu đặc biệt

Ta cần nắm bắt các yêu cầu phi chức năng cần cho việc thực thi một ca sử dụng

mà đã được xác định trong phân tích nhưng phải được xử lý trong thiết kế và thực thi

1.3.3.3 Phân tích một lớp

Mục đích của việc phân tích một lớp là:

Xác định và duy trì các trách nhiệm của một lớp phân tích dựa trên vai trò của nó trong các thực thi ca sử dụng

Xác định và duy trì các thuộc tính và các mối quan hệ của lớp phân tích

Nắm bắt các yêu cầu đặc biệt về việc thực thi của lớp phân tích

1.3.3.4 Phân tích một gói

Mục đích của việc phân tích một gói nhằm:

Đảm bảo các gói phân tích càng độc lập với nhau càng tốt

Đảm bảo các gói phân tích hoàn thành mục đích của nó là thực thi những lớp miền hay ca sử dụng nào đó

Mô tả các mối quan hệ phụ thuộc sao cho hiệu ứng của các thay đổi sau này có thể ước tính được chính xác nhất

Một số nguyên tắc chung đối với hoạt động phân tích gói như sau:

Xác định và duy trì các mối quan hệ phụ thuộc của gói này với các gói khác mà các lớp được chứa trong các gói khác đó được liên kết với gói này

Gói chứa các lớp đúng, tức là chỉ đưa các đối tượng có liên quan về mặt chức năng vào gói

Hạn chế các quan hệ phụ thuộc vào các gói khác, bố trí lại các lớp chứa trong một gói sang một gói khác nếu nó quá phụ thuộc vào gói khác đó

1.3.4 Thiết kế

Dựa vào các đặc tả yêu cầu và các kết quả phân tích thể hiện ở các biểu đồ để thực hiện thiết kế hệ thống Thiết kế hướng đối tượng là một giai đoạn trong quá trình phát triển phần mềm, trong đó hệ thống được tổ chức thành tập các đối tượng tương tác với nhau và mô tả được cách hệ thống thực thi nhiệm vụ của bài toán ứng dụng

Nhiệm vụ chính của giai đoạn này là xây dựng các thiết kế chi tiết mô tả các thành phần của hệ thống ở mức cao hơn khâu phân tích để phục vụ cho việc cài đặt Nghĩa là các lớp đối tượng được định nghĩa chi tiết gồm đầy đủ các thuộc tính, các thao tác phục

vụ cho việc cài đặt Đồng thời đưa ra được kiến trúc hệ thống để đảm bảo cho hệ thống

có thể thay đổi, có tính mở, dễ bảo trì, thân thiện với người sử dụng,… Nghĩa là tổ chức các lớp thành các hệ thống con theo một kiến trúc phù hợp với nhu cầu phát triển công nghệ và xu hướng phát triển của lĩnh vực ứng dụng

Những kết quả thiết kế được thể hiện trong các biểu đồ: biểu đồ lớp (chi tiết), biểu

đồ cộng tác, biểu đồ thành phần và biểu đồ triển khai [1]

Trong thiết kế, chúng ta định hình hệ thống và tìm hình thức biểu diễn của nó để thực hiện được mọi yêu cầu bao gồm cả những yêu cầu chức năng, các yêu cầu phi chức năng và những ràng buộc khác được đặt ra cho hệ thống Đầu vào của giai đoạn thiết kế

là mô hình phân tích Khi thiết kế ta sẽ cố gắng bảo tồn được càng nhiều càng tốt cấu trúc

hệ thống đã được định hình từ mô hình phân tích Kết quả của giai đoạn thiết kế là mô hình thiết kế Nó là một bản vẽ thiết kế của việc thực thi mô hình phân tích

Mô hình thiết kế là một mô hình đối tượng mô tả sự thực thi các ca sử dụng về mặt vật lý bằng cách tập trung vào việc xác định các yêu cầu chức năng và phi chức năng, cũng như các ràng buộc liên quan đến môi trường triển khai và ảnh hưởng của chúng lên

hệ thống

Mô hình thiết kế bao gồm các lớp thiết kế, các thực thi ca sử dụng thiết kế và khung nhìn kiến trúc Các lớp thiết kế bao gồm các lớp hoạt động, các tác vụ, các thuộc tính, các mối quan hệ và các yêu cầu thực thi của chúng Các thực thi ca sử dụng thiết kế

mô tả cách thức mà các ca sử dụng được thiết kế dưới dạng những cộng tác bên tỏng mô hình thiết kế Khung nhìn kiến trúc của mô hình thiết kế bao gồm các yếu tố quan trọng

Các hệ thống con và các giao diện của chúng

Các lớp thiết kế quan trọng về mặt kiến trúc

Các cơ chế thiết kế chung để xử lý các yêu cầu chung

Các hệ thống con, các giao diện hoặc các yếu tố thiết kế khác nhận được sẽ được tích hợp trong mô hình thiết kế Sau đó, bảo trì, thẩm định lại và cập nhật mô tả kiến trúc của các mô hình thiết kế và mô hình bố trí

a Xác định các nút và cấu hình mạng của hệ thống

Các cấu hình mạng chung thường dùng một dạng mẫu ba tầng là tầng ứng dụng, tầng chức năng cơ sở dữ liệu và tầng logic nghiệp vụ ứng dụng Dạng đơn giản của kiến trúc máy khách – máy chủ (client/server) là một trường hợp đặc biệt của dạng mẫu ba tầng, trong đó logix nghiệp vụ ứng dụng được bố trí vào cùng một tầng

b Xác định các hệ thống con và giao diện của chúng

Các hệ thống con thiết kế cung cấp cách thức để tổ chức mô hình thiết kế thành các cụm có thể quản lý được Chúng có thể được xác định ngay từ đầu như là một cách phân chia công việc thiết kế hoặc được xác định khi mô hình thiết kế tiến hóa và một cấu trúc lớn cần phân rã ra Việc đưa các hệ thống con vào trong mô hình thiết kế cho phép

có thể lập luận và đánh giá các cơ hội tái sử dụng của chúng

Một hệ thống con có thể bao gồm các lớp thiết kế, các thực thi ca sử dụng, các giao diện của các hệ thống con khác Ngoài ra, một hệ thống con có thể còn cung cấp các giao diện thể hiện các chức năng xuất ra dưới dạng các tác vụ

Xác định các lớp hoạt động

Để phác thảo các lớp hoạt động ban đầu có thể sử dụng các kết quả của sự phân tích và mô hình bố trí làm đầu vào rối sau đó bố trí các thiết kế tương ứng

của các lớp phân tích hoặc các bộ phận của chúng cho các nút thông qua các lớp hoạt động

Một khả năng khác để phác thảo các lớp hoạt động là sử dụng các hệ thống con đã được xác định trước đó và phân toàn bộ hệ thống con cho một nút riêng bằng cách xác định một lớp hoạt động bên trong của hệ thống con

d Xác định các cơ chế thiết kế chung để xử lý các yêu cầu chung

Ta cần đưa ra một bộ các cơ chế thiết kế chung, các cơ chế này có thể biểu thị là các lớp thiết kế, các cộng tác hay ngay ca hệ thống con Các yêu cầu cần phải xử lý thường liên quan tới các vấn đề như tính lâu bền, phân bố đối tượng trong suốt, các đặc trưng an toàn, phát hiện lỗi và phục hồi, quản lý giao dịch Trong một số trường hợp không thể tìm thấy cơ chế ngay nhưng thay vào đó lại tìm thấy các thực thi ca sử dụng và các thiết kế được khảo sát Người phát triển cũng phải xác định các cộng tác chung mà chúng có thể làm việc như các dạng mẫu và được sử dụng bởi nhiều thực thi ca sử dụng

bên trong mô hình thiết kế

1.3.4.2 Thiết kế một ca sử dụng

Mục tiêu của việc thiết kế một ca sử dụng là:

Xác định các lớp thiết kế hay các hệ thống con mà các thể hiện của chúng là cần thiết để thực hiện luông các sự kiện của ca sử dụng đó

Phân phối hành vi của ca sử dụng cho các đối tượng thiết kế tương tác hay cho các

hệ thống con tham gia

Xác định các yêu cầu về tác vụ của các lớp thiết kế hay các hệ thống con và các giao diện của chúng

Nắm bắt các yêu cầu triển khai cho ca sử dụng đó

a Xác định các lớp thiết kế tham gia

Việc xác định các lớp thiết kế cần thiết để thực thi ca sử dụng thiết kế như sau: Nghiên cứu các lớp phân tích tham gia vào việc thực thi ca sử dụng phân tích Xác định các lớp thiết kế bằng cách lần vết tới các lớp phân tích đó

Nghiên cứu các yêu cầu đặc biệt của việc thực thi ca sử dụng phân tích tương ứng Xác định các lớp thiết kế cần để thực thi các yêu cầu đặc biệt đó

Nếu vẫn còn thiếu một lớp thiết kế nào đó để thiết kế một ca sử dụng thì lớp được yêu cầu đó phải được xác định

Sau đó tập hợp các lớp thiết kế tham gia thực thi ca sử dụng vào một biểu

đồ lớp Sử dụng biểu đồ lớp này để chỉ ra các mối quan hệ đã được dùng trong việc thực thi ca sử dụng này

b Mô tả các tương tác giữa các đối tượng thiết kế

Khi đã có phác thảo về lớp thiết kế cần thiết để thực thi ca sử dụng ta cần mô tả cách thức mà các đối tượng thiết kế tương ứng tương tác với nhau Điều này được thực hiện bằng cách sử dụng các biểu đồ tuần tự chứa các thể hiện của tác nhân tham gia, các đối tượng thiết kế và sự truyền thông báo giữa chúng Nếu các ca sử dụng các luồng hoặc các luồng con khác nhau và tách biệt thì thường phải tạo ra từng biểu đồ tuần tự cho mỗi luồng tách biệt đó

Trước hết, nghiên cứu việc thực thi ca sử dụng phân tích tương ứng để tìm ra các phác thảo về chuỗi các thông báo cần thiết giữa các đối tượng thiết kế Trong một số trường hợp, có thể chuyển trực tiếp một biểu đồ cộng tác thực thi ca sử dụng phân tích thành những phác thảo ban đầu của một biểu đồ thiết kế tuần tự tương ứng

Khi chi tiết hóa các biểu đồ tương tác, phần lớn các trường hợp ta tìm ra các con đường – phương án mới mà các ca sử dụng đó có thể chọn Những con đường như thế

có thể được mô tả bằng các nhãn của các biểu đồ hoặc trong chính các biểu đồ tương tác của chúng Khi đưa thêm thông tin mới vào, người phát triển thường phát hiện ra các vấn đề mới đã bị bỏ qua trong quá trình xác định và nắm bắt yêu cầu

c Xác định các hệ thống con và các giao diện tham gia

Chúng ta đã thiết kế một ca sử dụng dưới dạng cộng tác của các lớp và các đối tượng của chúng Tuy nhiên, đôi khi ta nên thiết kế một ca sử dụng dưới dạng các hệ thống con tham gia cùng các giao diện của chúng Chẳng hạn, trong quá trình phát triển từ trên xuống, cần phải nắm bắt các yêu cầu về các hệ thống con và các giao diện của chúng trước khi thiết kế phần bên trong Trong những trường hợp như thế, một thực thi ca sử dụng thiết kế có thể được mô tả ở nhiều mức trong hệ phân cấp các hệ thống con

Việc tìm ra các hệ thống con cần có để thực thi ca sử dụng có thể thực hiện bằng cách lần vết tới các lớp phân tích tham gia vào thực thi ca sử dụng phân tích tương

ứng Xác định các gói phân tích mà chúng chứa các lớp phân tích đó nếu có Sau đó xác định các hệ thống con thiết kế mà chúng lần vết tới các gói phân tích đó

Các hệ thống con có tham gia vào việc thực thi ca sử dụng được đưa vào một biểu

đồ lớp Ta sẽ dùng biểu đồ lớp này để đưa ra các mối quan hệ phụ thuộc giữa các hệ thống con đó và các giao diện bất kè mà được dùng trong việc thực thi ca sử dụng

d Mô tả các tương tác giữa các hệ thống con

Khi đã có phác thảo về các hệ thống con cần thiết để thực thi ca sử dụng, chúng ta cần phải mô tả cách thức mà các đối tượng của các lớp trong chúng tương tác trên một cấp độ của hệ thống Việc này được tiến hành bằng cách sử dụng các biểu đồ tuần tự chứa các thể hiện của tác nhân tham gia, các hệ thống con và những sự truyền thông điệp giữa chúng

e Nắm bắt các yêu cầu triển khai

Bước này thực hiện việc nắm bắt mọi yêu cầu về thực thi một ca sử dụng, chẳng hạn các yêu cầu phi chức năng đã được xác định trong thiết kế những sẽ phải được xử

lý trong triển khai

và điều cần làm chỉ là gán một lớp thiết kế để cung cấp giao diện đó

Khi sử dụng các lớp phân tích được cho làm đầu vào thì phương pháp được sử dụng phụ thuộc vào khuôn mẫu của lớp phân tích

b Xác định các thao tác

Chúng ta xác định các tác vụ cần được cung cấp bởi lớp thiết kế và mô tả các tác

vụ đó bằng cách sử dụng cú pháp của ngôn ngữ lập trình Các đầu vào quan trọng của bước này:

Các trách nhiệm của một lớp phân tích bất kỳ mà lớp thiết kế lần vết tới đó Mỗi trách nhiệm thường chứa một hay nhiều tác vụ Hơn nữa, nếu đã có mô tả về các đầu vào và đầu ra cho các trách nhiệm, ta có thể dùng chúng như là một phác thảo thứ nhất của các tham số hình thức và của các giá trị kết quả của các tác vụ

Các yêu cầu đặc biệt của một lớp phân tích bất kỳ mà lớp thiết kế lần vết tới nó Các giao diện mà lớp thiết kế cần phải cung cấp Các tác vụ của giao diện này cũng cần được cung cấp bởi lớp thiết kế

Các thực thi ca sử dụng thiết kế mà lớp tham gia vào đó

Các thao tác của một lớp thiết kế cần phải hỗ trợ mọi vai trò mà lớp này giữ trong các thực thi ca sử dụng khác nhau Đối với một số lớp thì hành vi của các đối tượng của chúng phụ thuộc nhiều vào trạng thái của đối tượng Tốt nhất đối với các lớp này là được

mô tả bằng cách sử dụng các biểu đồ trạng thái

c Xác định các thuộc tính

Chúng ta xác định các thuộc tính do lớp thiết kế đòi hỏi và mô tả chúng bằng cú pháp của ngôn ngữ lập trình Mỗi thuộc tính quy định một tính chất của một lớp thiết kế, thường được ngầm định và yêu cầu bởi các tác vụ của lớp đó

d Xác định các liên kết và các kết hợp

Các đối tượng thiết kế tương tác với nhau trong các biểu đồ tuần tự Các tương tác này thường được đòi hỏi các liên kết giữa các lớp tương ứng của chúng nên cần nghiên cứu sự truyền thông điệp trong các biểu đồ tuần tự để xác định các liên kết nào cần có

e Xác định các tổng quát hóa

Các tổng quát hóa phải được dùng cùng với các ngữ nghĩa như đã xác định bởi ngôn ngữ lập trình Nếu ngôn ngữ lập trình không hỗ trợ sự tổng quát hóa hay sự thừa kế thì các kết hợp và các kết hợp phải được dùng thay thế để cung cấp sự ủy quyền từ các đối tượng của lớp có tính cụ thể hơn tới các đối tượng của lớp có tính chung hơn

f Mô tả các phương thức

Các phương thức có thể được dùng trong quá trình thiết kế để chỉ ra các tác vụ được thực thi như thế nào Chẳng hạn, một phương thức có thể quy định một thuật toán phải được sử dụng để thực thi một tác vụ Phương thức có thể được chỉ ra bằng cách sử dụng ngôn ngữ tự nhiên hoặc dùng các giả mã nếu thấy thích hợp

g Mô tả các trạng thái

Một số đối tượng thiết kế được kiểm soát về trạng thái nghĩa là trạng thái của chúng xác định hành vi của chúng khi nhận được một thông điệp Trong những trường hợp như vậy, ta nên sử dụng biểu đồ trạng thái để mô tả sự dịch chuyển trạng thái khác nhau của một đối tượng thiết kế Một biểu đồ trạng thái như vậy sau đó sẽ là một đầu vào

có giá trị cho việc triển khai lớp thiết kế tương ứng

h Xử lý các yêu cầu đặc biệt

Bất kỳ một yêu cầu nào còn chưa được xem xét trong các bước trước thì đều được

xử lý ở đây

2.3.4.4 Thiết kế một hệ thống con

Mục tiêu của thiết kế một hệ thống con:

Đảm bảo cho hệ thống con là độc lập đối với các hệ thống con khác hay các giao diện của chúng đến mức tối đa có thể được

Đảm bảo cho hệ thống con cung cấp các giao diện đúng

Đảm bảo cho hệ thống con thực thi đúng các tác vụ đã được xác định bởi các giao diện mà nó cung cấp

a Duy trì các mối quan hệ phụ thuộc của hệ thống con

Các mối quan hệ phụ thuộc phải được xác định và duy trì từ hệ thống con này tới các hệ thống con khác có chứa các phần tử được liên kết với nó Tuy nhiên, nếu các hệ thống con khác đó cung cấp các giao diện thì các mối quan hệ phụ thuộc cần được khai báo về các giao diện đó Một phụ thuộc tốt là phụ thuộc vào một giao diện mà không phụ thuộc vào hệ thống con Nên tối thiểu hóa các phụ thuộc vào các hệ thống con hay giao diện bằng việc bố trí lại các lớp được chứa mà không phụ thuộc vào hệ thống con khác

b Duy trì các giao diện được cung cấp bởi hệ thống con

Các thao tác được xác định qua các giao diện được cung cấp bởi một hệ thống con cần phải hỗ trợ mọi vai trò mà hệ thống con này đóng góp trong thực thi các ca sử dụng khác nhau Ngay cả khi các giao diện đã được phác thảo, các giao diện này có thể phải tinh chế khi mô hình thiết kế phát triển Một hệ thống con và các giao diện của nó có thể được sử dụng bên trong nhiều thực thi ca sử dụng, do đó sẽ cung cấp nhiều yêu cầu mới nữa trên các giao diện

c Duy trì các nôi dung của hệ thống con

Một hệ thống con hoàn thành mục tiêu của nó nếu nó cung cấp một thực thi đúng các thao tác đã được xác định bởi các giao diện nó cung cấp Một số vấn đề liên quan tới vấn đề này bao gồm:

Một giao diện do một hệ thống con cung cấp, thì nó phải được các lớp thiết kế hoặc các hệ thống con khác bên trong hệ thống con đó cung cấp phương tiện thực thi

Để làm sang tỏ cách thức mà các thiết kế bên trong của một hệ thống con thực thi bất kỳ một giao dịch nào hoặc các ca sử dụng của nó, ta có thể tạo ra các cộng tác dưới dạng các yếu tố được chứa trong hệ thống con đó Như vậy, thực hiện phân tích và thiết kế hướng đối tượng bằng UML là xây dựng các biểu đồ mô tả các yêu cầu, khái niệm và kiến trúc của hệ thống Quá trình xây dựng các biểu đồ đó có thể thực hiện như hình sau:

Hình 1 Quy trình xây dựng các biểu đồ UML trong phân tích và thiết kế hệ thống

hướng đối tượng

1.3.5 Lập trình và kiểm tra chương trình

Giai đoạn xây dựng phần mềm có thể được thực hiện sử dụng kỹ thuật lập trình hướng đối tượng Đó là phương thức thực hiện thiết kế hướng đối tượng qua việc sử dụng một ngôn ngữ lập trình có hỗ trợ các tính năng hướng đối tượng Một vài ngôn ngữ hướng đối tượng thường được nhắc tới như C++, Java… Kết quả chung của giai đoạn này là một loạt các code chạy được, nó chỉ được đưa vào sử dụng sau khi đã trải qua nhiều vòng qua của nhiều vòng quay của nhiều bước thử nghiệm khác nhau

Trong giai đoạn này, mỗi thành phần đã được thiết kế sẽ được lập trình thành những mô đun chương trình (các chương trình con) Mỗi mô đun này sẽ được kiểm chứng hoặc thử nghiệm theo các tài liệu đặc tả của giai đoạn thiết kế Sau đó, các mô đun chương trình đã được kiểm tra sẽ được tích hợp với nhau thành hệ thống tổng thể và được kiểm tra xem có đáp ứng các yêu cầu của khách hàng Kết quả của giai đoạn này là phần mềm cần được xây dựng [1]

1.3.6 Vận hành và bảo trì hệ thống

Tại giai đoạn này thực hiện việc cài đặt hệ thống phần mềm trong môi trường sử dụng của khách hàng sau khi sản phẩm đã được bàn giao cho khách hàng Hệ thống sẽ hoạt động, cung cấp các thông tin, xử lý các yêu cầu và thực hiện những gì đã được thiết kế

Việc bảo trì phần mềm là đảm bảo cho hệ thống hoạt động đáp ứng được các yêu cầu của người sử dụng và khách hàng Trên thực tế các yêu cầu này thường hay thay đổi,

do vậy, công tác bảo trì phần mềm bao gồm cả những thay đổi hệ thống sao cho nó phù hợp với yêu cầu hiện tại của họ, thậm chí có những thay đổi chưa được phát hiện ở giai đoạn phân tích và thiết kế Điều này đồng nghĩa với việc phần mềm phải được nâng cấp hoàn thiện liên tục và chi phí cho công tác bảo trì thường khá tốn kém

Chương 2 – Khái quát về hệ thống quản lý quan hệ

khách hàng CRM

Ngày nay, khi các hình thức cạnh tranh về giá cả, chất lượng hay công nghệ đã trở nên một điều hiển nhiên thì các công ty đã hướng tới một hình thức cạnh tranh khác không kém phần khốc liệt và hiệu quả: Cạnh tranh bằng cách tạo sự thân thiết với khách hàng

2.1 Khách hàng quyết định sự thành bại của doanh nghiệp

2.1.1 Cạnh tranh bằng sự thân thiết với khách hàng

Trong kinh doanh, hiểu rõ khách hàng là một yếu tố vô cùng quan trọng dẫn tới thành công Để thu hút và níu giữ chân khách hàng trong thị trường cạnh tranh ngày nay, bạn phải làm họ hài lòng, làm tốt hơn cả sự mong đợi của họ và phải phán đoán, tìm hiểu

và đáp ứng những nhu cầu tiềm tàng của họ Những công ty có uy tín cao chính là những công ty có dịch vụ chăm sóc khách hàng hoàn hảo nhất Đặc biệt trong môi trường lạm phát thấp, không thể đơn thuần đặt tăng trưởng doanh thu thực tế thông qua việc tăng giá Hơn hết là sự thừa nhận tầm quan trọng của việc phán đoán và phục vụ nhu cầu khách hàng [13]

Phần lớn các công ty thực hiện công việc này một cách có hiệu quả Một hoặc hai lần trong năm, bộ phận tiếp thị cần kiểm tra lại xem thị trường khách hàng đã phân khúc

ra sao, đâu là những phân khúc mới nổi lên, quy mô và lợi nhuận từng phân khúc này đang thay đổi thế nào và làm sao để các sản phẩm và dịch vụ công ty có thể đáp ứng nhu cầu mỗi phân khúc Nếu sau đó công ty bạn không nhận được câu trả lời ngắn gọn cho câu hỏi “Nhu cầu khách hàng đang thay đổi như thế nào?” tức là bộ phận tiếp thị chưa hoàn thiện nhiệm vụ của mình

Mặt khác bộ phận tiếp thị phải xác định cho được các nhược điểm đặc thù đối với

mô hình kinh doanh thuộc ngành nghề của mình Đó là những bực tức, khó chịu ẩn chứa khi khách hàng không có được sự lựa chọn của riêng mình Những nhược điểm đó có thể khiến bạn mất đi những khách hàng trung thành một khi đối thủ cạnh tranh tìm ra được

và biết cách loại bỏ chúng Loại bỏ những nhược điểm cũng chính là cách tạo động lực quan trong cho sự tăng trưởng

Dù tiếp thị là khâu thiết yếu để nâng cao hiểu biểt thấu đáo về khách hàng nhưng những người trong ban điều hành hay những nhà quản lý cấp cao khác (CEO) cũng chính

là phương tiện thúc đẩy mối quan hệ mật thiết với khách hàng – nhân tố định hướng cho

sự tăng trưởng CEO cần nhiệt huyết với khách hàng, đánh giá cho đúng những khách hàng cần hướng tới để có thể làm lợi cho họ và những khách hàng khác nữa Sau đó đưa

ra những dịch vụ và sản phẩm mới, khác biệt nhằm mang lại những giá trị thực sự cho số khách hàng mục tiêu

CEO dù không có chuyên môn tiếp thị nhưng cũng cần sẵn sàng cho vai trò cổ vũ khách hàng Thay vì việc ngồi lỳ một chỗ để giải quyết các công việc giấy tờ, kiểm tra các số liệu trên màn hình thì hãy dành thêm thời gian cho việc tiếp xúc khách hàng Để

có được những hiểu biết sâu sắc về khách hàng thì việc đầu tư thời gian để trực tiếp gặp

gỡ họ và việc rất quan trọng và không gì có thể thay thế được Bởi vì biện pháp khoan ngoan nhất cho sự thành công là luôn giữ sợi dây liên kết chặt chẽ với khách hàng Lợi ích mà khách hàng thu được chính là cảm giác được coi như đối tác chiến lược

Hiển nhiên là các doanh nghiệp khắp mọi nơi cần phải duy trì sản phẩm và dịch vụ hiệu quả hơn, đáng tin cậy hơn, có đủ khả năng đáp ứng nhu cầu của khách hàng Nhưng đòn bẩy thực sự là ở chỗ phải tạo cho mình nhiều ấn tượng tốt Ấn tượng đó được tạo bởi cách thức kinh doanh đúng đắn Nếu chỉ kinh doanh theo hướng thực dụng thì đến một lúc nào đó sẽ không còn phù hợp nữa Mỗi thành viên ban điều hành và các nhà doanh nhân phải chú trọng nhiều hơn khía cạnh tinh thần của công việc kinh doanh

Có sự khác biệt lớn trong hình vi cư xử giữa một bên là các khách hàng thỏa mãn theo kiểu lý tính và một bên là những khách hàng thỏa mãn về phương diện cảm xúc Sự khác biệt về hành vi chuyển hóa thành sự khác biệt lớn ở lòng trung thành và lợi nhuận

Quả thực đối với các thành viên ban điều hành, việc cắt giảm chi phí và hạ thấp chất lượng dễ thực hiện hơn nhiều khi so sánh với việc tìm và đưa ra phương pháp mới phù hợp với tâm lý khách hàng Nhưng các nhà lãnh đạo đang nhận ra một dấu hiệu cho thấy khách hàng không chỉ muốn một thỏa thuận tốt trong kinh doanh Những gì mà khách hàng mong muốn còn là cảm giác thực sự về mối liên hệ với các công ty Dịch vụ chu đáo sẽ làm khách hàng cảm thấy có mối quan hệ ràng buộc với công ty

Vai trò của kênh phân phối là cầu nối tới người tiêu thụ cuối cũng, chứ không đơn thuần là cách thức chuyển giao hàng hóa Lực lượng bán hàng có lợi thế đặc biệt trong thu thập thông tin liên quan hoặc trực tiếp từ khách hàng và có thể tham gia các cuộc đối thoại liên quan đến mong muốn và nhu cầu thực sự của họ Đó chính là mạng lưới tương tác giữa doanh nghiệp và khách hàng Một khi nhân viên bán hàng hay phụ trách công nghệ không cung cấp cho nhân viên tiếp thị thông tin cạnh tranh và nhận thức của khách

hàng, tức là công ty bạn đã bỏ qua những thông tin giúp thâu hiểu khách hàng có thể đưa

ra những ý tưởng sáng tạo cho sự tăng trưởng

Một phương châm mà hầu như tổ chức nào cũng đặt ra là “khách hàng là thượng đế” Nhưng để thực hiện được điều này thì quả thực không dễ dàng Để có được sự thành công thì trên hết phải tôn trọng khách hàng của mình mà thể nghiệm đầu tiên là những nhân viên thị trường và nhân viên bán hàng cần phải tôn trọng khách hàng của mình Một khi bạn tỏ ra coi thường khách hàng của mình tức là bạn không thể phục vụ họ tốt được Việc tôn trọng khách hàng xuất phát từ việc bạn biết lắng nghe, thực sự lắng nghe và thấu hiểu những nhu cầu, mong muốn hay đòi hỏi của khách hàng Trong khi đó, phải luôn giữ được tính khách quan với khách hàng mà không để cho những định kiến thường xuất phát

từ ý niệm hay phán đoán chi phối, chẳng hạn khách hàng này thật ngớ ngẩn, khách hàng kia thiếu văn hóa… Từ việc nghe cặn kẽ cho bạn khả năng và thiện ý cảm nhận những gì

mà khách hàng đang suy nghĩ, đặt mình vào hoàn cảnh của họ để suy xét thì hiểu thấu đáo khách hàng hơn Những đòi hỏi trên từ nhân viên bán hàng cũng chính là những đòi hỏi cho những nhà quản lý Sự tôn trọng cho khách hàng chỉ có được khi nhà quản lý biết tôn trọng nhân viên của mình Cả hai sự tôn trọng đó có quan hệ chặt chẽ Hãy kính trọng những nhân viên rồi họ sẽ thể hiện sự kính trọng đối với khách hàng của mình [11]

2.1.2 Vai trò của CRM trong giai đoạn khủng hoảng hiện nay

Xét nghiệm trong giai đoạn khủng hoảng toàn cầu hiện nay, mọi doanh nghiệp đều nằm trong lòng nhận định “khủng hoảng kinh tế không có chỗ cho sự lãng phí” Khắp nơi các nhà lãnh đạo chạy đôn đáo chống đỡ với khủng hoảng kinh tế, mau chóng đúc rút kinh nghiệm và tìm phương cách giúp doanh nghiệp cũng như chính mình vượt qua khó khăn Nhưng liệu rằng con đường họ đi liệu có đúng đắn?

Khi khủng hoảng và khó khăn ập đến thì việc cắt giảm chi phí là điều đầu tiên doanh nghiệp nghĩ tới Nhưng nếu tâm nhìn và suy nghĩ của họ chỉ dừng ở đây thôi thì họ đang bước vào một sai lầm nghiêm trọng, thực hiện một giải pháp nửa vời Dường như khó khăn làm con người rối trí và chỉ biết soi xét các yếu tố đầu vào như lao động, vốn và ngân sách cho việc marketing mà quên mất yêu tố đầu ra – quan hệ khách hàng Hãy nhớ rằng quan hệ khách hàng chính là nhân tố sống còn với các doanh nghiệp trong bất kỳ thời điểm nào, đặc biệt trong khủng hoảng thì thứ tài sản vô hình này ngày càng trở nên quý giá

Khi môi trường kinh doanh ngày một cạnh tranh khốc liệt và không còn chỗ cho

sự khoan nhượng, khách hàng ngày càng kén chọn hơn với các nhà cung cấp dịch vụ, sản phẩm Trong khi nhu cầu ngày càng thu hẹp, lợi nhuận cận biên giảm, nguồn lực khan

hiếm thì điều gì còn có thể quan trọng hơn mối quan hệ khăng khít và mật thiết với khách hàng

Hơn bao giờ hết, các công ty mà đi đầu là các nhà lãnh đạo phải tìm ra cách bứt phá, tạo dấu ấn khác biệt và luôn đem lại cho khách hàng những giải pháp thay thế Khách hàng chỉ muốn hợp tác với những công ty chia sẻ giá trị của họ - thời điểm hó khăn đen tối hiện nay cũng chính là cơ hội ngàn vàng để bạn chứng minh giá trị của mình trong mắt họ

Việc cắt giảm đầu tư, chi tiêu ngân sách hay sa thải công nhân là việc làm trước mắt trong giai đoạn khó khăn nhung cũng đừng vì những chủ trương sàng lọc cắt giảm tối

đa mà nói không với những khoản đầu tư chính đáng Để làm được điều này, mỗi công ty cần đặt ra cơ chế ràng buộc với mọi nhãn hàng, phòng ban hay các chi nhánh công ty Mỗi quyết định thu hẹp quy mô và cắt giảm chi phí luôn phải đi kèm biện pháp củng cố lợi thế cạnh tranh và quan hệ khách hàng Mọi sự cắt giảm hữu hình đều phải song hành với bù đắp các giá trị vô hình, như vậy doanh nghiệp mới giữ được niềm tin của khách hang và khẳng định giá trị của mình

Điều may mắn là đầu tư cho những giá tri vô hình thì không mấy tốn kém Nhờ vậy doanh nghiệp hoàn toàn có thể cân đối ngân sách mà vẫn chiều lòng khách hàng, một điều tưởng chừng không mấy dễ dàng Trong thời buổi khủng hoảng, một vài cử chỉ than thiện, nụ cười trìu mến, sự niềm nở tiếp đón hay sự bất ngờ và thỏa mãn nhiều khi mang lại những cái nhìn ấn tượng và sự khác biệt lớn về mặt dịch vụ [10]

2.2 Cơ sở lý luận về quản lý quan hệ khách hàng CRM

Định nghĩa 1:

CRM là triết lý kinh doanh lấy khách hàng làm trung tâm, trong đó lấy cơ chế hợp tác với khách hàng bao trùm toàn bộ quy trình hoạt động kinh doanh của doanh nghiệp

CRM được xác định là cả một hệ thống những quy trình hỗ trợ mối quan hệ khách hàng trong suốt vòng đời kinh doanh, nhằm đạt được mục tiêu chính: tạo ra dòng thu hút những khách hàng mới và phát triển những khách hàng sẵn có Giải pháp CRM bao gồm bốn yếu tố: cấu trúc tổ chức lấy khách hàng làm trung tâm, những quy trình kinh doanh, những quy luật về dịch vụ khách hàng, và phần mềm hỗ trợ

Những quy luật và nguyên tắc trong quá trình phục vụ khách hàng phải được thấm nhuần trong toàn bộ doanh nghiệp: kinh doanh, tiếp thị, dịch vụ, hậu cần, sản phẩm, tài chính và các phòng ban khác Quản lý mối quan hệ có nghĩa là thu hút những khách hàng mới, biến khách hàng trung lập thành khách hàng chung thuỷ, biến những khách hàng tận tuỵ thành các đối tác kinh doanh Chiến lược này thích hợp với mọi loại thị trường, bắt đầu bằng việc thu hút những khách hàng mới, sau đó tạo mối quan hệ với

họ, củng cố niềm tin đối với họ Kết quả là, chính những khách hàng này sẽ tạo nên mạng lưới đại lý cho doanh nghiệp

Định nghĩa 2:

CRM là một chiến lược kinh doanh được thiết kế để nâng cao lợi nhuận, doanh thu và sự hài lòng của khách hàng Nó bao gồm phần mềm, các dịch vụ và một phương thức kinh doanh mới nhằm gia tăng lợi nhuận, doanh thu, đồng thời làm hài lòng khách hàng hơn để giữ chân khách hàng lâu hơn

Bằng cách trợ giúp các doanh nghiệp có quy mô khác nhau xác định được các khách hàng thực sự, nhanh chóng có được khách hàng phù hợp và duy trì mối quan hệ với họ lâu dài hơn

CRM về cơ bản có liên quan đến việc tập trung tất cả dữ liệu khách hàng và tự động hóa nhiều công việc buồn tẻ trong công tác tiếp thị, quản lý bán hàng, và dịch vụ khách hàng để những người chuyên trách có thể sử dụng nhiều thời gian hơn vào các công việc trợ giúp các khách hàng của họ thành công hơn và tốn ít thời gian hơn

Định nghĩa 3:

CRM là một chiến lược kinh doanh quy mô toàn công ty được thiết kế nhằm làm giảm chi phí và tăng lợi nhuận bằng cách củng cố lòng trung thành của khách hàng CRM thực sự sẽ mang lại lợi ích từ tất cả các nguồn thông tin trong và ngoài doanh nghiệp để đem đến cái nhìn toàn diện về từng khách hàng tại từng thời điểm cụ thể Điều này cho phép các nhân viên làm việc với khách hàng trong các lĩnh vực như tiếp thị, bán hàng, và