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

Môn học sẽ được tóm tắt trong 8 bài học để cho các bạn nắm được các kỹ thuật cơ bản khi học với môn học này.

Bài 1 - TỔNG QUAN VỀ OOAD VÀ UML:

Giới thiệu về phân tích  thiết kế hướng đối tượng  (OOAD) và ngôn ngữ mô hình hợp nhất 

(UML), các tiến trình OOAD, tiến trình Objectory.
Mục tiêu:
-  Phân biệt giữa phân tích và thiết kế.
-  Giải thích tầm quan trọng quá trình chu trình cuộc sống phần mềm.
-  Liệt kê được các ưu thế của việc sử dụng hướng đối tượng. 
-  Mô tả vai trò của UML trong phân tích và thiết kế. 
-  Liệt kê các giai đoạn và thành phần tiến trình của tiến trình Objectory.
Nội dung:
I.  Giới thiệu về OOAD và UML 
1. Phân tích và thiết kế hướng đối tượng
Hướng đối tượng  là thuật  ngữ  thông dụng hiện thời của ngành công nghiệp phần mềm. Các 
công ty đang nhanh chóng tìm cách áp dụng và tích hợp công nghệ mới này vào các ứng dụng 
của họ. Thật sự  là đa phần các  ứng dụng hiện thời đều mang tính hướng đối tượng. Nhưng 
hướng đối tượng có nghĩa là gì?
Lối tiếp cận hướng đối tượng là một lối tư duy về vấn đề theo lối ánh xạ các thành phần trong 
bài toán vào các đối tượng ngoài đời thực. Với lối tiếp cận này, chúng ta chia ứng dụng thành 
các thành phần nhỏ, gọi là các đối tượng, chúng tương đối độc lập với nhau. Sau đó ta có thể
xây dựng ứng dụng bằng cách chắp các đối tượng đó lại với nhau. Hãy nghĩ đến trò chơi xây 
lâu đài bằng các mẫu gỗ. Bước đầu tiên là tạo hay mua một vài loại mẫu gỗ căn bản, từ đó tạo 
nên các khối xây dựng căn bản của mình. Một khi đã có các khối xây dựng đó, bạn có thể
chắp ráp chúng lại với nhau để tạo lâu đài. Tương tự như vậy một khi đã xây dựng một số đối 
tượng căn bản trong thế  giới máy tính, bạn có thể  chắp chúng lại với nhau để  tạo  ứng dụng 
của mình.
Xin lấy một  ví dụ  đơn giản: vấn đề  rút tiền mặt tại nhà băng. Các “mẫu gỗ“ thành phần ở  đây 
sẽ là ánh xạ của các đối tượng ngoài đời thực như tài khoản, nhân viên, khách hàng, …Và ứng 
dụng sẽ được sẽ được nhận diện cũng như giải đáp xoay quanh các đối tượng đó.
Phương pháp phân tích và thiết kế hướng đối tượng thực hiện theo các thuật ngữ và khái niệm 
của phạm vi lĩnh vực ứng dụng (tức là của doanh nghiệp hay đơn vị mà hệ thống tương lai cần 
phục vụ), nên nó tạo sự  tiếp cận tương ứng giữa hệ  thống và vấn đề  thực ngoài  đời. Trong ví 



dụ  bán xe ô tô, mọi giai đoạn phân tích thiết kế  và thực hiện đều xoay quanh các khái niệm 
như khách hàng, nhân viên bán hàng, xe ô tô, … Vì quá trình phát triển phần mềm đồng thời là quá trình cộng tác của khách hàng/người dùng, nhà phân tích, nhà thiết kế, nhà phát triển, 
chuyên gia lĩnh vực, chuyên gia kỹ  thuật,... nên lối tiếp cận này khiến cho việc giao tiếp giữa 
họ với nhau được dễ dàng hơn.
Một trong những ưu điểm quan trọng bậc nhất của phương pháp phân tích và thiết kế  hướng 
đối  tượng  là  tính  tái  sử  dụng:  bạn  có  thể  tạo  các  thành  phần  (đối  tượng)  một  lần  và  dùng 
chúng nhiều lần sau đó. Giống như việc bạn có thể  tái sử  dụng các khối xây dựng (hay bản 
sao của nó ) trong một toà lâu đài, một ngôi nhà  ở, một con tàu vũ trụ, bạn cũng có thể  tái sử
dụng các thành phần (đối tượng) căn bản trong các thiết kế  hướng đối tượng cũng như code 
của một hệ thống kế toán, hệ thống kiểm kê, hoặc một hệ thống đặt hàng. 
Vì các đối tượng đã được thử  nghiệm kỹ  càng trong lần dùng trước đó, nên khả  năng tái  sử
dụng đối tượng có tác dụng giảm thiểu lỗi và các khó khăn trong việc bảo trì, giúp tăng tốc độ
thiết kế và phát triển phần mềm. 
Phương pháp hướng đối tượng giúp chúng ta xử  lý các vấn đề  phức tạp trong phát triển phần 
mềm và tạo ra các thế hệ phần mềm có khả năng thích ứng và bền chắc. 
2. Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML)
Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ để
biểu diễn mô hình theo hướng đối tượng với chủ đích là:
-  Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng.
-  Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần mô hình hoá.
-  Giải quyết vấn đề  về  mức độ  thừa kế  trong các hệ  thống phức tạp, có nhiều ràng 
buộc khác nhau.
-  Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy.
II.  Các quá trình OOAD 
1. Phân tích hướng đối tượng (Object Oriented Analysis - OOA): 
Là giai đọan 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 đời thực, dễ hiểu đối với người sử dụng. 
Trong giai đoạn OOA, vấn đề được trình bày bằng các thuật ngữ tương ứng với các đối tượng 
có thực. Thêm vào đó, hệ  thống cần phải được định nghĩa sao cho người không chuyên Tin 
học có thể dễ dàng hiểu được.
Dựa trên một vấn đề có sẵn, nhà phân tích cần ánh xạ các đối tượng hay thực thể có thực như 
khách hàng, ô tô, người 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. 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ành  vi  của  chúng.  Nói  một  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. 
Đối với ví dụ một phòng bán ô tô, giai đoạn OOA sẽ nhận biết được các thực thể như: 
  • Khách hàng 
  • Người bán hàng 
  • Phiếu đặt hàng
  • Phiếu (hoá đơn) thanh toán 
  • Xe ô tô
Tương tác và quan hệ giữa các đối tượng trên là: 
  • Người bán hàng dẫn khách hàng tham quan phòng trưng bày xe.
  • Khách hàng chọn một chiếc xe 
  • Khách hàng viết phiếu đặt xe 
  • Khách hàng trả tiền xe 
  • Xe ô tô được giao đến cho khách hàng
Đối với ví dụ nhà băng lẻ, giai đoạn OOA sẽ nhận biết được các thực thể như: 
Loại tài khoản: ATM (rút tiền tự  động), Savings (tiết kiệm), Current (bình 
thường), Fixed (đầu tư),...
  • Khách hàng 
  • Nhân viên 
  • Phòng máy tính.
Tương tác và quan hệ giữa các đối tượng trên: 
  • Một khách hàng mới mở một tài khoản tiết kiệm 
  • Chuyển tiền từ tài khoản tiết kiệm sang tài khoản đầu tư 
  • Chuyển tiền từ tài khoản tiết kiệm sang tài khoản ATM
Xin chú ý là ở đây, như đã nói, ta chú ý đến cả hai khía cạnh: 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 đó). 
Lối phân tích bằng kiểu ánh xạ  "đời thực” vào máy tính  như thế  thật sự  là ưu điểm lớn của 
phương pháp hướng đối tượng. 
2. Thiết kế hướng đối tượng (Object Oriented Design - OOD):
Là giai đoạn tổ  chức chương trình thành các tập hợp đối tượng cộng tác, mỗi đối tượng trong 
đó là thực thể  của một lớp. Các lớp là thành viên của một cây cấu trúc với mối quan hệ  thừa 
kế. 
Mục đích của giai đoạn OOD là tạo thiết kế  dựa trên kết quả  của giai đoạn OOA, dựa trên 
những quy định phi chức năng, những  yêu cầu về  môi trường, những  yêu cầu về  khả  năng 
thực thi,.... OOD tập trung vào việc cải thiện kết quả  của OOA, tối ưu hóa giải pháp đã được 
cung cấp trong khi vẫn đảm bảo thoả mãn tất cả các yêu cầu đã được xác lập. 
Trong giai đoạn OOD, nhà thiết kế  định nghĩa các chức năng, thủ  tục (operations), thuộc tính 
(attributes) cũng như mối quan hệ của một hay nhiều lớp (class) và quyết định chúng cần phải 
được điều chỉnh sao cho phù hợp với môi trường phát triển. Đây cũng là giai đoạn để  thiết kế
ngân hàng dữ liệu và áp dụng các kỹ thuật tiêu chuẩn hóa. 
Về  cuối giai đoạn OOD, nhà  thiết kế  đưa ra một loạt các biểu đồ  (diagram) khác nhau. Các 
biểu đồ này có thể được chia thành hai nhóm chính là Tĩnh và động. Các biểu đồ tĩnh biểu thị
các lớp và đối tượng, trong khi biểu đồ  động biểu thị  tương tác giữa các lớp và phương thức 
hoạt  động  chính  xác  của  chúng.  Các  lớp  đó  sau  này  có  thể  được  nhóm  thành  các  gói 
(Packages) tức là các đơn vị thành phần nhỏ hơn của ứng dụng. 
3. Lập trình hướng đối tượng (Object Oriented Programming - OOP): 
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 là C++ và Java. Kết quả  chung cuộc 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 quay của nhiều bước 
thử nghiệm khác nhau. 
III.  Tiến trình Objectory
Chu trình của một phần mềm có thể được chia thành các giai đoạn như sau: 
Nghiên cứu sơ bộ (Preliminary Investigation hay còn gọi là Feasibility Study) 
  • Phân tích yêu cầu (Analysis)
  • Thiết kế hệ thống (Design of the System) 
  • Xây dựng phần mềm (Software Construction)
  • Thử nghiệm hệ thống (System Testing)
  • Thực hiện, triển khai (System Implementation)
  • Bảo trì, nâng cấp (System Maintenance)
a - Nghiên cứu sơ bộ:
     Câu hỏi quan trọng nhất khi phát triển một hệ  thống hoàn toàn không phải câu hỏi mang tính 
phương pháp luận. Mà cũng chẳng phải câu hỏi về  kỹ  thuật. Nó là một câu hỏi dường như  có 
vẻ  đơn giản, nhưng thật ra đặc biệt khó trả  lời: “Đây có đúng là một hệ  thống để  thực hiện 
không?” Đáng buồn là chính câu hỏi này trong thực tế  thường chẳng hề  được đặt ra và lại 
càng không được trả  lời. Mặc dù việc lầm lẫn về  phương pháp hay quyết định sai lầm về  kỹ
thuật cũng có thể  dẫn tới thất bại, nhưng thường thì dự  án có thể  được cứu vãn nếu có đầy đủ
tài nguyên cùng sự  cố  gắng quên mình của các nhân viên tài giỏi. Nhưng sẽ  chẳng một ai và 
một điều gì cứu vãn cho một hệ  thống phần mềm hoàn toàn chẳng được cần tới hoặc cố  gắng 
tự động hóa một quy trình lầm lạc. 
    Trước khi bắt tay vào một dự  án, bạn phải có một ý tưởng cho nó. Ý tưởng này đi song song 
với việc nắm bắt các  yêu cầu và xuất hiện trong giai đoạn khởi đầu. Nó hoàn tất một phát 
biểu: "Hệ thống mà chúng ta mong muốn sẽ làm được những việc như sau....". Trong suốt giai 
đoạn này, chúng ta tạo nên một bức tranh về  ý tưởng đó, rất nhiều giả  thuyết sẽ  được công 
nhận hay loại bỏ. Các hoạt động trong thời gian này thường bao gồm thu thập các ý tưởng, 
nhận biết rủi ro, nhận biết các giao diện bên ngoài, nhận biết các các chức năng chính mà hệ
thống cần cung cấp, và có thể  tạo một vài nguyên mẫu dùng để  “minh chứng các khái niệm 
của hệ  thống”. Ý tưởng có thể  đến từ  nhiều nguồn khác nhau: khách hàng,  chuyên gia lĩnh 
vực, các nhà phát triển khác, chuyên gia về kỹ nghệ, các bản nghiên cứu tính khả thi cũng như 
việc xem xét các hệ  thống khác đang tồn tại. Một khía cạnh cần nhắc tới là code viết trong 
thời kỳ  này thường sẽ  bị  "bỏ  đi”, bởi chúng được viết nhằm mục đích thẩm tra hay trợ  giúp 
các giả  thuyết khác nhau, chứ  chưa phải thứ  code được viết theo kết quả  phân tích và thiết kế
thấu đáo. 
     Trong  giai đọan nghiên  cứu sơ bộ, nhóm phát triển hệ  thống cần xem xét các  yêu cầu  của 
doanh nghiệp (cần dùng hệ  thống), những nguồn tài nguyên có thể  sử  dụng, công nghệ  cũng 
như cộng đồng người dùng cùng các ý tưởng của họ  đối với hệ  thống mới. Có thể  thực hiện 
thảo luận, nghiên cứu, xem xét khía cạnh thương mại, phân tích khả năng lời-lỗ, phân tích các 
trường hợp sử dụng và tạo các nguyên mẫu để xây dựng nên một khái niệm cho hệ thống đích 
cùng với các mục đích, quyền ưu tiên và phạm vi của nó. 
Thường trong giai đoạn này người ta cũng tiến hành tạo một phiên bản thô của lịch trình và kế
hoạch sử dụng tài nguyên. 
     Một  giai đoạn nghiên cứu sơ bộ  thích đáng sẽ  lập nên tập hợp các yêu cầu (dù ở  mức độ  khái 
quát cao) đối với một hệ  thống khả  thi và được mong muốn, kể  cả  về  phương diện kỹ  thuật 
lẫn xã hội. Một giai đoạn nghiên cứu sơ bộ  không được thực hiện thoả  đáng sẽ  dẫn tới các hệ
thống không được mong muốn, đắt tiền, bất khả  thi và được định nghĩa lầm lạc  –  những hệ
thống thừơng chẳng được hoàn tất hay sử dụng.
     Kết quả  của giai đoạn nghiên cứu sơ bộ  là Báo Cáo Kết Quả  Nghiên Cứu Tính Khả  Thi. Khi 
hệ  thống tương lai được  chấp nhận dựa trên bản báo cáo này cũng là lúc giai đoạn Phân tích 
bắt đầu. 
b- Phân tích yêu cầu
     Sau khi đã xem xét về  tính khả  thi của hệ  thống cũng như tạo lập một bức tranh sơ bộ  của dự
án, chúng ta bước sang giai đoạn thường được coi là quan trọng nhất trong các công việc lập 
trình: hiểu hệ thống cần xây dựng. Người thực hiện công việc này là nhà phân tích. 
Quá trình phân tích nhìn chung là hệ quả của việc trả lời câu hỏi "Hệ thống cần phải làm gì?". 
Quá trình phân tích bao gồm việc nghiên cứu chi tiết hệ  thống doanh nghiệp hiện thời, tìm 
cho ra nguyên lý hoạt động của nó và những vị  trí có thể  được nâng cao, cải thiện. Bên cạnh 
đó là việc nghiên cứu xem xét các chức năng mà hệ  thống cần cung cấp và các mối quan hệ
của chúng, bên trong cũng như với phía ngoài hệ  thống. Trong toàn bộ  giai đoạn này, nhà 
phân tích và người dùng cần cộng tác mật thiết với nhau để  xác định các yêu cầu đối với hệ
thống, tức là các tính năng mới cần phải được đưa vào hệ thống
Những mục tiêu cụ thể của giai đoạn phân tích là: 
Xác định hệ thống cần phải làm gì.
  • Nghiên cứu thấu đáo tất cả  các chức năng cần cung cấp và những yếu tố  liên 
  • quan 
  • Xây dựng một mô hình nêu bật bản chất vấn đề  từ  một hướng nhìn có thực 
  • (trong đời sống thực).
  • Trao định nghĩa vấn đề cho chuyên gia lĩnh vực để nhận sự đánh giá, góp ý. 
  • Kết  quả  của  giai  đoạn  phân  tích  là  bản  Đặc  Tả  Yêu  Cầu  (Requirements 
  • Specifications).
c - Thiết kế hệ thống 





     Sau giai đoạn phân tích, khi các yêu cầu cụ  thể  đối với hệ  thống đã được xác định, giai đoạn 
tiếp theo là thiết kế  cho các  yêu cầu mới. Công tác thiết kế  xoay quanh câu hỏi chính: Hệ
thống làm cách nào để thỏa mãn các yêu cầu đã được nêu trong Đặc Tả Yêu Cầu?
Một số các công việc thường được thực hiện trong giai đoạn thiết kế: 
  • Nhận biết form nhập liệu tùy theo các thành phần dữ liệu cần nhập.
  • Nhận biết reports và những output mà hệ thống mới phải sản sinh 
  • Thiết kế forms (vẽ trên giấy hay máy tính, sử dụng công cụ thiết kế) 
  • Nhận biết các thành phần dữ liệu và bảng để tạo database
  • Ước tính các thủ tục giải thích quá trình xử lý từ input đến output.
Kết quả  giai đoạn thiết kế  là Đặc Tả  Thiết Kế  (Design Specifications). Bản Đặc Tả  Thiết Kế
Chi Tiết sẽ  được chuyển sang cho các lập trình viên để  thực hiện giai đoạn xây dựng phần 
mềm. 
d - Xây dựng phần mềm 
     Đây là giai đoạn viết lệnh (code) thực sự, tạo hệ thống. Từng người viết code thực hiện những 
yêu cầu đã được nhà thiết kế  định sẵn. Cũng chính người viết code chịu trách nhiệm viết tài 
liệu liên quan đến chương trình, giải thích thủ  tục (procedure) mà anh ta tạo nên được viết 
như thế nào và lý do cho việc này. 
     Để  đảm bảo chương trình được viết nên phải thoả  mãn mọi yêu cầu có ghi trước trong bản 
Đặc Tả  Thiết Kế  Chi Tiết, người viết code cũng đồng thời phải tiến hành thử  nghiệm phần 
chương trình của mình. Phần thử nghiệm trong giai đoạn này có thể được chia thành hai bước 
chính: 
Thử nghiệm đơn vị: 
     Người viết code chạy thử  các phần chương trình của mình với dữ  liệu giả  (test/dummy data). 
Việc này được thực hiện theo một kế  hoạch thử, cũng do chính người viết code soạn ra. Mục 
đích chính trong giai đoạn thử  này là xem chương trình có cho ra những kết quả  mong đợi. 
Giai đoạn thử nghiệm đơn vị nhiều khi được gọi là "Thử hộp trắng" (White Box Testing) 
Thử nghiệm đơn vị độc lập: 
    Công việc này do một thành viên khác trong nhóm đảm trách. Cần chọn người không có liên 
quan trực tiếp đến việc viết code của đơn vị  chương trình cần thử  nghiệm để  đảm bảo tính 
“độc lập”. Công việc thử  đợt này cũng được thực hiện dựa trên kế  hoạch thử  do người viết 
code soạn nên.
e- Thử nghiệm hệ thống 
    Sau khi các thủ tục đã được thử nghiệm riêng, cần phải thử nghiệm toàn bộ hệ thống. Mọi thủ
tục được tích hợp và chạy thử, kiểm tra xem mọi chi tiết ghi trong Đặc Tả  Yêu Cầu và những 
mong chờ của người dùng có được thoả mãn. Dữ  liệu thử cần được chọn lọc đặc biệt, kết quả
cần được phân tích để phát hiện mọi lệch lạc so với mong chờ.
f - Thực hiện, triển khai 
    Trong  giai  đoạn  này,  hệ  thống  vừa  phát  triển  sẽ  được  triển  khai  sao  cho  phía  người  dùng. 
Trước khi để  người dùng thật sự  bắt tay vào sử  dụng hệ  thống, nhóm các nhà phát triển cần 
tạo các file dữ liệu cần thiết cũng như huấn luyện cho người dùng, để đảm bảo hệ thống được 
sử dụng hữu hiệu nhất. 
g - Bảo trì, nâng cấp
     Tùy theo các biến đổi trong môi trường sử dụng, hệ thống có thể trở nên lỗi thời hay cần phải 
được sửa đổi nâng cấp để sử dụng có hiệu quả. Hoạt động bảo trì hệ thống có thể rất khác biệt 
tùy theo mức độ sửa đổi và nâng cấp cần thiết.
Sơ đồ tổng quát các giai đoạn của Chu Trình Phát Triển Phần Mềm:

Hình 1.3: Sơ đồ tổng quát các giai đoạn của Chu Trình Phát Triển Phần Mềm
Câu hỏi và bài tập
1.  Hỏi:  Một  số  tập  hợp  dữ  liệu  phức  tạp  nhất  định  khi  được  trình  bày  bằng  đồ  thị  sẽ
truyền tải đến người đọc nhiều thông tin hơn so với các dữ liệu thô?
2.  Hỏi: Mô hình giúp chúng ta tổ  chức, trình bày trực quan, thấu hiểu và tạo nên các hệ
thống phức tạp.
3.  Hỏi: Ưu điểm lớn nhất của mô hình hướng đối tượng là tính tái sử dụng (Reusable)?
Xem thêm

1 comments:

Post a Comment