1
ĐẠ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Ĩ
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
4
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
6
DANH MỤC CÁC CHỮ VIẾT TẮT
CRM
Customer Relationship Management - Quản lý Quan Hệ Khách Hàng
CSDL
Cơ sở dữ liệu
UML
Unified Modeling Language – Ngôn ngữ mô hình hóa thống nhất
đặ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.
8
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:
Mở đầu
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
Chương này trình bày những điểm khái quát hóa về phương pháp mô hình hóa,
công nghệ hướng đối tượng và ngôn ngữ mô hình hóa thống nhất trong việc xây dựng các
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
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
10
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:
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.
12
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.
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].
14
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
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
triển hệ thống.
Nút (Nodes)
Nút là thể hiện thành phần vật lý, tồn tại khi chương trình chạy và biểu diễn các tài
nguyên tính toán. Nó có thể là máy tính hay các thiết bị phần cứng. Có thể đặt tập
các thành phần trên nút và chuyển từ nút này sang nút khác.
b. Phần tử hành vi
Các phần tử thể hiện hành vi là bộ phận động của mô hình UML. Chúng là các
động từ trong mô hình, biểu diễn các hành vi theo thời gian và không gian. Có hai loại
chính là tương tác (Interaction) và máy trạng thái (States machine).
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
16
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.
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
18
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;
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
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
21
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:
1.3.2.1. Tìm các tác nhân và các ca sử dụng
Việc xác định các tác nhân và các ca sử dụng gồm bốn bước:
Tìm các tác nhân
Tác nhân thể hiện cho những phần ngoài của hệ thống mà tương tác với hệ
thống. Tác nhân có thể là các kiểu người dùng hay các hệ thống ngoài. Mỗi tác
nhân đóng vai trò nào đó đối với mỗi ca sử dụng mà nó tương tác. Mỗi khi một
người dùng hay hệ thống ngoài có sự tương tác với hệ thống, thể hiện của tác nhân
tương ứng sẽ đóng một vai trò mà tác nhân thực hiện.
Tìm các ca sử dụ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)
23
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.
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.
25
Để tạo ra mô hình phân tích cần tiến hành:
Phân tích kiến trúc
Phân tích một ca sử dụng
Phân tích một lớp
Phân tích một gói
Trong quá trình phân tích, ta sẽ liên tục tìm các gói, các lớp phân tích mới và các
yêu cầu chung khi mô hình phân tích được tiếp tục làm mịn bằng cách phân rã các gói
phân tích và duy trì các gói đó.
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
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.
Copyright: Tài liệu đại học ©