Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 6: Kiến trúc hệ thống và phát sinh mã trình

PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 
OBJECT ORIENTED ANALYSIS AND DESIGN 
DR. DAO NAM ANH 
Bài giảng 6: 
KIẾN TRÚC HỆ THỐNG VÀ PHÁT SINH MÃ TRÌNH 
1 
RESOURCE - REFERENCE 
1. Ian Sommerville, Software Engineering, Ninth Edition, 2011 
2. Bernd Bruegge & Allen H. Dutoit. Object-Oriented 
Software Engineering: Using UML, Patterns, and Java, 
Third Edition, Prentice Hall, 2010 
3. Russell C. Bjork, ATM Simulation Links, Gordon College 
4. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David 
Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003 
5. Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế 
Hệ thống thông tin với UML, 2006 
6. Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng 
Đối Tượng, Đại học Điện lực, 2013 
2 
CONTENT – NỘI DUNG 
Kiến trúc hệ thống và phát sinh mã trình 
6.1 Kiến trúc của hệ thống 
6.2 Biểu đồ thành phần 
6.3 Biểu đồ triển khai 
6.4 Chuyển đổi các thiết kế sang mã chương trình 
3 
1 Kiến trúc của hệ thống 
 Kiến ​​trúc hệ thống một tả chi tiết hệ thống về cấu trúc, 
giao diện, và các cơ chế cộng tác. Kiến ​​trúc giúp dễ 
dàng điều hướng, tìm kiếm các hàm chức năng, xác định 
vị trí để đặt chức năng mới. Kiến trúc cũng phải đủ chi 
tiết để có ánh xạ tới mã. Như vậy kiến ​​trúc có thể được 
xem từ các góc độ khác nhau. 
4 
1 Kiến trúc của hệ thống 
 Một kiến ​​trúc tốt cho phép chèn các chức năng và các 
khái niệm mới mà khôngcó vấn đề với phần còn lại của 
hệ thống. Điều này không giống như một hệ thống 
nguyên khối cũ, khi những thay đổi nhỏ trong một phần 
của hệ thống có thể làm ngừng hoạt động vì mối quan hệ 
phức tạp trên toàn hệ thống. 
 Kiến trúc như là một bản đồ cho các nhà phát triển, mô 
tả cách hệ thống được xây dựng và các chức năng cụ thể 
hoặc các khái niệm. Theo thời gian, bản đồ này có thể 
phải thay đổi vì những khám phá quan trọng và kinh 
nghiệm trên đường đi. Kiến trúc phải "sống" với hệ 
thống khi hệ thống đang được phát triển và liên tục phản 
ánh việc xây dựng hệ thống trong tất cả các giai đoạn và 
các thế hệ. 
5 
1 Kiến trúc của hệ thống 
 Grady Booch, một trong những người phát triển UML, 
đã nói, "Một nhóm phát triển thiếu kinh nghiệm có thể 
thành công trong một kiến ​​trúc có cấu trúc tốt, nhưng 
một nhóm chuyên gia phát triển giỏi sẽ khó thể thành 
công trong một lộ trình tồi” 
6 
1 Kiến trúc của hệ thống 
Kiến trúc được mô tả trong một số hướng nhìn, và mỗi 
hướng nhìn xét tập trung vào một khía cạnh cụ thể của hệ 
thống. Bức tranh hoàn chỉnh của hệ thống có thể chỉ được 
thực hiện bằng cách xác định tất cả các hướng nhìn. Trong 
UML, những hướng nhìn này thường được định nghĩa như 
sau: 
 Hướng nhìn Use case 
 Hướng nhìn Logic 
 Hướng nhìn Đồng thời (concurrent) 
 Hướng nhìn Hợp phần (component) 
 Hướng nhìn Triển khai (deployment) 
 Ngoài ra kiến ​​trúc còn được chia thành Logic và Vật lý. 
 7 
1 Kiến trúc của hệ thống 
Như vậy, với tất cả những định nghĩa này,điều gì tạo nên 
một kiến ​​trúc tốt? Dưới đây là một số hướng dẫn để trả lời 
câu hỏi đó: 
 Mô tả chính xác các bộ phận để xác định hệ thống, cả về 
kiến ​​trúc hợp lý và kiến ​​trúc vật lý. 
 Một bản đồ của hệ thống mà trong đó một nhà phát triển 
có thể dễ dàng xác định vị trí nơi một chức năng cụ thể 
hay khái niệm được thực hiện. Chức năng và khái niệm 
có thể là ứng dụng theo định hướng (một mô hình của 
một cái gì đó trong lĩnh vực ứng dụng) hoặc thiết kế 
theo định hướng (một số giải pháp thực hiện kỹ thuật). 
Điều này cũng có nghĩa rằng yêu cầu mã của hệ thống 
nên được theo dõi. 
8 
1 Kiến trúc của hệ thống 
 Những thay đổi và mở rộng cần được thực hiện dễ dàng 
cho một địa điểm cụ thể, mà không ảnh hưởng tiêu cực 
đến các phần khác. 
 Giao diện đơn giản, cũng như các quy định và phụ thuộc 
giữa các bộ phận khác nhau là rõ ràng để một kỹ sư có 
thể phát triển một phần cụ thể cả khi không có một sự 
hiểu biết đầy đủ của tất cả các chi tiết trong hệ thống 
tổng thể. 
 Tái sử dụng được áp dụng cho các thành phần thiết kế 
để có thể sử dụng trong các hệ thống khác. 
9 
1 Kiến trúc của hệ thống 
 Thiết kế kiến ​​trúc bao gồm tất cả những phẩm chất này 
không phải là dễ dàng, và đôi khi phải thỏa hiệp. Tuy 
nhiên, định nghĩa một kiến ​​trúc cơ bản tốt là một trong 
những bước quan trọng nhất trong sự phát triển của một 
hệ thống thành công. 
 Nếu nó không được thực hiện chu đáo, kiến ​​trúc đi kèm 
phải được xác định từ dưới lên bởi các mã, kết quả trong 
một hệ thống đó là khó khăn để thay đổi, gia hạn, duy 
trì, và hiểu. 
10 
1 Kiến trúc của hệ thống 
 Kiến trúc Logic 
 Kiến trúc logic chứa các ứng dụng logic, không phải là 
phân phối vật lý của logic đó vào các môi trường khác 
nhau trên các máy tính khác nhau. Kiến trúc logic cho 
một sự hiểu biết rõ ràng về việc xây dựng các hệ thống, 
làm cho quản trị hệ thống logic và phối hợp hiệu quả các 
công việc (sử dụng các nguồn lực một cách hiệu quả 
nhất). Không phải tất cả các bộ phận của kiến trúc logic 
phải được phát triển trong dự án: các thư viện lớp, thành 
phần nhị phân, và các mô hình thường có thể được mua. 
11 
1 Kiến trúc của hệ thống 
 Kiến trúc Logic 
Kiến trúc logic trả lời các câu hỏi như: 
 Cấu trúc tổng thể của hệ thống là gì? 
 Chức năng hệ thống cung cấp? 
 Các lớp chính là gì, và làm thế nào là những lớp này liên 
quan đến các lớp khác? 
 Các lớp và các đối tượng của chúng cộng tác để cung 
cấp các chức năng như thế nào? 
 Cơ chế chung áp dụng nhất quán trong thiết kế? 
 Kế hoạch phù hợp của nhà phát triển để phát triển hệ 
thống này? 
12 
1 Kiến trúc của hệ thống 
 Kiến trúc Logic 
 Kiến trúc được mô tả trong các biểu đồ cung cấp là trả 
lời cho các câu hỏi bên trên. Kiến trúc còn mô tả tổ 
chức, các hạn chế, và các công cụ phổ biến để thiết kế. 
Trong UML, các biểu đồ được sử dụng để mô tả kiến 
trúc logic là biểu đồ lớp, biểu đồ trạng thái, biểu đồ hoạt 
động, và biểu đồ trình tự. Các biểu đồ này đã được mô tả 
trong các chương trước. 
13 
1 Kiến trúc của hệ thống 
 Kiến trúc vật lý 
 Kiến trúc vật lý là mô tả chi tiết của hệ thống về phương 
thức các vật phẩm phần mềm được gán cho các nút vật 
lý như thế nào. Nó cho thấy cấu trúc của phần cứng, bao 
gồm các nút khác nhau và các nút được kết nối với nhau 
như thế nào. Nó cũng minh họa cấu trúc vật lý và phụ 
thuộc của các vật phẩm phần mềm. Kiến trúc vật lý tiến 
tới sự sử dụng hiệu quả tài nguyên của phần cứng và 
phần mềm. 
14 
1 Kiến trúc của hệ thống 
 Kiến trúc vật lý 
 Các kiến ​​trúc vật lý câu trả lời các câu hỏi như: 
 Hệ thống có máy tính và các thiết bị phần cứng gì, và 
làm thế nào kết nốichúng với nhau? 
 Môi trường thực thi của các bộ phận khác nhau của hệ 
thống chạy là gì? 
 Các vật phẩm thực thi được triển khai trên máy tính 
nào? 
 Sự phụ thuộc giữa các tập mã là gì? Nếu một tập tin cụ 
thể được thay đổi, các tập tin khác có phải biên dịch lại? 
 15 
1 Kiến trúc của hệ thống 
 Kiến trúc vật lý 
 Kiến trúc vật lý mô tả sự phân rã của phần mềm và phần 
cứng. Lập ánh xạ từ các kiến ​​trúc logic vào kiến ​​trúc vật 
lý, theo đó các lớp, các thành phần, và các cơ chế trong 
kiến ​​trúc logic được ánh xạ lên vật phẩm, quy trình, và 
các máy tính trong kiến ​​trúc vật lý. 
16 
1 Kiến trúc của hệ thống 
 Kiến trúc vật lý 
 Bản đồ ánh xạ này cho phép các nhà phát triển theo dõi 
các lớp của kiến ​​trúc logic được thực hiện vật lý như thế 
nào, hoặc ngược lại. Kiến ​​trúc vật lý có liên quan với 
việc thực hiện và, do đó, cũng được mô phỏng trong 
biểu đồ thực hiện. Các biểu đồ thực hiện trong UML là 
thành phần và biểu đồ triển khai. 
 Biểu đồ thành phần cho thấy làm thế nào các đồ tạo tác 
vật lý thực hiện các thành phần. Biểu đồtriển khai cho 
thấy kiến ​​trúc thời gian chạy của hệ thống, bao gồm cả 
các thiết bị vật lý và các phần mềm giao cho họ. 
17 
2 Biểu đồ thành phần 
 Biểu đồ thành phần (component diagram) cho thấy các 
tổ chức và sự phụ thuộc giữa các thành phần và vật 
phẩm. Các phần tử trong kiến trúc logic được nhóm lại 
và đóng gói thành các thành phần (component). Các 
thành phần thường được thực hiện trong các tập tin 
trong môi trường phát triển và được mô hình bằng các 
vật phẩm (artifact). 
18 
2 Biểu đồ thành phần 
Vật phẩm có thể là: 
 Mã nguồn (source): là một tập tin mã nguồn có một hoặc 
nhiều lớp. 
 Mã thực thi được: là tập tin chương trình thực thi, là kết 
quả của việc kết nối tất cả các thành phần nhị phân (hoặc 
là tĩnh tại thời gian liên kết, hoặc động tại thời gian 
chạy). Một thành phần thực thi đại diện cho các đơn vị 
thực thi được điều hành bởi một bộ xử lý (máy tính). 
19 
2 Biểu đồ thành phần 
 Thành phần được thể hiện trong UML là một hình chữ 
nhật với stereotype > và có thể thêm một 
biểu tượng nhỏ. Vật phẩm được thể hiện như là một hình 
chữ nhật với stereotype > và / hoặc một biểu 
tượng tập tin trong góc. Thành phần có thể có các 
stereotype khác như >. 
20 
3 Biểu đồ triển khai 
 Biểu đồ triển khai (deployment diagram) mô tả kiến ​​trúc 
thời gian chạy của các thiết bị, môi trường thực hiện, và 
các vật phẩm thuộc kiến ​​trúc này. Đây là mô tả vật lý cuối 
cùng của cấu trúc liên kết hệ thống, mô tả cấu trúc của các 
đơn vị phần cứng và phần mềm, được thực hiện trên từng 
đơn vị. 
 Trong kiến ​​trúc như vậy, chúng ta có thể nhìn vào một 
nút cụ thể trong topo, xem các thành phần được thực hiện 
trong nút đó và các yếu tố logic (lớp, đối tượng, hợp tác, 
và vv) được thực hiện trong thành phần, và cuối cùng theo 
dõi các yếu tố để phân tích yêu cầu ban đầu của hệ thống 
(có thể đã được thực hiện thông qua phân tích Use Case). 
21 
3 Biểu đồ triển khai 
 Nút 
 Nút (node) là các tài nguyên tính toán mà các vật phẩm 
có thể được triển khai để thực hiện. Những tài nguyên 
này bao gồm các thiết bị như máy tính với bộ vi xử lý, 
cũng như đầu đọc thẻ, thiết bị di động, thiết bị thông tin 
liên lạc, vv. Chúng cũng bao gồm nút con trong những 
thiết bị phản ánh môi trường thực thi khác như J2EE 
container, workflow engine, hoặc cơ sở dữ liệu. Một nút 
có thể là một phân loại, mô tả các đặc điểm của một loại 
vi xử lý hoặc thiết bị và , và cũng có thể là một thực thể 
của loại. Trong hình dưới đây, MidrangeServer là kiểu 
nút, còn SystemTestServer4 là một đối tượng dạng nút 
này. 
22 
3 Biểu đồ triển khai 
 Nút 
 Định nghĩa chi tiết về khả năng của hệ thống có thể 
được định nghĩa như là thuộc tính, như là giá trị được 
quy định cho các nút. Một nút được vẽ bằng một khối 
lập phương 3 chiều với tên gọi. Cũng giống như các ký 
hiệu của các lớp và các đối tượng, tên được gạch dưới 
nếu nút là thực thể. Khi các nút được sử dụng để đại 
diện cho các tài nguyên vật lý tính toán, họ được thể 
hiện với stereotype >. Môi trường thực hiện 
riêng biệt trong các nút này được hiển thị với stereotype 
>, xem hình dưới đây: 
23 
3 Biểu đồ triển khai 
 Nút 
24 
2 Biểu đồ thành phần 
 Đường dẫn 
 Các nút được kết nối với nhau bởi các đường dẫn, như 
thể hiện trong hình dưới đây. Đường dẫn ký hiệu bằng 
các đoạn thẳng liền, đề trao đổi các đối tượng và các 
thông điệp giữa các nút. Các loại giao tiếp có thể được 
đặc tả bằng stereotype chỉ ra giao thức protocol hay 
mạng được sử dụng. 
25 
2 Biểu đồ thành phần 
 Triển khai vật phẩm 
 Vật phẩm có thể được triển khai trên các nút, được thể 
hiện với tên gọi có gạch chân. Một vật phẩm được triển 
khai vào một nút có thể được trình bày với các thuộc 
tính mô tả các thông số thực hiện cho vật phẩm trên nút 
cụ thể. Các thuộc tính có thể được mô hình hóa một cách 
trực tiếp trong vật phẩm được triển khai như đặc điểm 
kỹ thuật triển khai. Khi đặc điểm kỹ thuật triển khai 
được hiển thị, nó được thể hiện bằng hình chữ nhật phân 
loại đơn giản với stereotype >. 
26 
2 Biểu đồ thành phần 
 Triển khai vật phẩm 
27 
2 Biểu đồ thành phần 
 Quan hệ phụ thuộc có thể được mô hình hóa giữa các 
vật phẩm triển khai. Đặc tả triển khai có liên quan đến 
một vật phẩm triển khai được thể hiện bằng liên kết một 
chiều. Đặc tả triển khai cũng có thể có bên trong vật 
phẩm, hoặc lồng bên trong vật phẩm khác. 
28 
2 Biểu đồ thành phần 
 Phân bổ vật phẩm vào các nút 
 Các lớp và các hợp tác, như được định nghĩa trong các 
thiết kế hợp lý, được phân bổ đặt vào các thành phần. 
Việc phân bổ tùy theo ngôn ngữ lập trình được sử dụng. 
Ví dụ, Java thực hiện một lớp trong tập tin mã nguồn vật 
phẩm (java). Sau đó, một nhóm các lớp, trong một gói 
hoặc một thành phần, có các tập tin mã nguồn đã biện 
dịch được đưa vào file jar (.Jar). 
 Vì vậy, các thành phần nằm trong kiến ​​trúc thực thi được 
thực hiện bởi các vật phẩm, và vật phẩm được triển khai 
trên các nút. 
 Một vật phẩm triển khai thực hiện trên ít nhất một nút, 
và có thể trên một số nút. 
29 
2 Biểu đồ thành phần 
 Sử dụng tài nguyên. Một trong những mục tiêu chính khi 
xác định kiến ​​trúc vật lý và phân bổ của các thành phần 
là sử dụng tài nguyên của phần cứng. Phần cứng nên 
được sử dụng một cách hiệu quả, sử dụng hết công suất 
trong mỗi nút (không sử dụng quá mức, tốc độ sẽ chậm 
kém hiệu quả). 
 Vị trí địa lý. Các quyết định phải dựa vào các chức năng 
cho mỗi vị trí địa phương (Phải có sẵn đủ chức năng cho 
các nút hoạt động). 
 Truy cập đến các thiết bị. Yêu cầu cho một thiết bị cụ 
thể trên một nút là gì? Máy in có thể được kết nối đến 
máy chủ, hoặc mỗi khách hàng cần một máy in tại chỗ? 
30 
2 Biểu đồ thành phần 
 An ninh. Kiến trúc xử lý quyền truy cập và bảo vệ thông 
tin một cách tối ưu và hiệu quả? Kiểm soát truy cập có 
thể quan tâm cả vị trí địa lý (có máy chủ ở một nơi an 
toàn) và các giải pháp thông tin (bằng cách sử dụng 
phần cứng và phần mềm an toàn để giao tiếp). 
 Performance. Sự cần thiết cho hiệu suất cao đôi khi ảnh 
hưởng đến vị trí của một thành phần. Nó có thể cải thiện 
hiệu suất bằng cách tạo bản copy trên một nút địa 
phương, thay thế cho các thành phần ở một nút khác. 
 Khả năng mở rộng và tính di động. Khi các nút khác 
nhau có hệ điều hành hoặc cấu trúc máy tính khác nhau, 
có thể thành phần phụ thuộc vào một hệ điều hành cụ 
thể. Điều này ảnh hưởng đến vị trí của các thành phần và 
có lẽ cả ngôn ngữ lập trình. 31 
2 Biểu đồ thành phần 
 Thiết kế quay vòng là cần thiết để có biểu đồ triển khai. 
Các giải pháp pahir được thử nghiệm, trước hết là trong 
trong giai đoạn mô hình hóa và sau đó trong các nguyên 
mẫu thực hiện. Lý tưởng nhất là hệ thống được linh hoạt 
để một thành phần cụ thể có thể di chuyển giữa các nút 
khác nhau. Một hệ thống đối tượng như J2EE hoặc .NET 
cho phép việc tạo ra các hệ thống như vậy. 
32 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Nếu các mẫu thiết kế và đặc điểm kỹ thuật của giao diện 
lớp đã được thực hiện một cách cẩn thận, phần lớn các 
vấn đề thiết kế đã được giải quyết. bây giờ cần hiện thực 
hóa các Use Case, các yêu cầu, và thiết kế hệ thống 
thành hệ thống phần mềm. Tuy nhiên, khi các lập trình 
viên bắt đầu sắp các hệ thống con phát triển cá nhân theo 
cách này, có nhiều vấn đề về liên kết. 
 Các lập trình viên có các xử lý khác nhau với cùng vấn 
đề. Vì yêu cầu thay đổi, một số thông số đã được thêm 
vào các API nhưng chưa có mô tả trong tài liệu. Một 
thuộc tính được bổ sung vào mô hình đối tượng, nhưng 
không được báo cho hệ thống quản lý cấu hình, có thể 
gây ra hiểu nhầm. Kết quả là mã sẽ ít có sự tương đồng 
với thiết kế ban đầu và khó hiểu. 33 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Chương này mô tả một một cách tiếp cận có tổ chức cho 
việc chuyển các thiết kế thành mã chương trình, tránh 
gây hỏng hệ thống như trên. 
Giải pháp bao gồm: 
 Tối ưu hóa mô hình lớp, 
 Lập bản đồ các liên kết, 
 Chuyển các hoạt động sang các ngoại lệ, 
 Chuyển mô hình lớp sang mô hình lưu trữ. 
 Công nghệ Java và dựa trên Java được sử dụng trong 
chương này. Các kỹ thuật mô tả, tuy nhiên, cũng áp 
dụng đối với các ngôn ngữ lập trình hướng đối tượng 
khác. 
34 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Khái niệm chuyển đổi 
Bốn loại biến đổi được phân biệt , xem hình vé dưới đây : 
 Chuyển đổi mô hình (Model transformations) hoạt động 
trên các mô hình đối tượng. Một ví dụ là chuyển đổi một 
thuộc tính đơn giản (ví dụ, một địa chỉ viết bằng chuỗi) 
thành một lớp (ví dụ, một lớpc với địa chỉ đường phố, 
mã zip, thành phố, tỉnh, và quốc gia). 
 Chuyển đổi mã (Refactorings) là những biến đổi hoạt 
động trên mã nguồn. ương tự như chuyển đổi mô hình, 
trong đó cải thiện một khía cạnh duy nhất của hệ thống 
mà không làm thay đổi chức năng của. Phép chuyển mã 
thao tác trên mã nguồn. 
35 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Kỹ thuật chuyển tiếp (Forward engineering) sinh một mã 
nguồn tương ứng với một mô hình đối tượng. Nhiều 
thành phần của mô hình, như thuộc tính và liên kết có 
thể được ánh xạ vào mã nguồn cho một số ngôn ngữ lập 
trình (ví dụ, lớp và khai báo trong Java), trong khi phần 
thân và các biến private được lập trình viên viết thêm. 
 Kỹ thuật đảo ngược (Reverse engineering) tạo ra một 
mô hình tương ứng với mã nguồn. Chuyển đổi này được 
sử dụng khi thiết kế của hệ thống đã bị mất và phải được 
tái lập từ mã nguồn. Mặc dù một số công cụ CASE hỗ 
trợ kỹ thuật đảo ngược, cần có sự tham gia nhiều của 
người phát triển để tái tạo một mô hình chính xác, bởi 
như các mã không có thông tin cần thiết để phục hồi các 
mô hình một cách rõ ràng. 
36 
4 Chuyển đổi các thiết kế sang mã chương trình 
37 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Chuyển đổi mô hình 
 Một chuyển đổi mô hình được áp dụng cho một mô hình 
đối tượng và kết quả trong một mô hình đối tượng. Mục 
đích của việc chuyển đổi mô hình đối tượng là để đơn 
giản hóa hoặc tối ưu hóa mô hình ban đầu, đưa nó tuân 
thủ chặt chẽ hơn với tất cả các yêu cầu trong các đặc 
điểm kỹ thuật. Một chuyển đổi có thể thêm, loại bỏ, 
hoặc đổi tên các lớp, các hoạt động, các liên hệ, hoặc các 
thuộc tính. Một chuyển đổi cũng có thể thêm thông tin 
vào mô hình hoặc loại bỏ thông tin từ nó. Trong phân 
tích, sử dụng biến đổi để tổ chức các đối tượng vào mô 
hình kế thừa và loại bỏ dư thừa từ các mô hình phân 
tích. 
38 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Ví dụ, việc chuyển đổi trong hình dưới đây tạo 
nên một lớp mới chứa các thuộc tính chung 
(email) của ba lớp ban ban đầu 
39 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Chuyển đổi mã 
 Chuyển đổi mã (refactoring) là một biến đổi của mã 
nguồn để cải thiện khả năng đọc hoặc khả năng cập nhật 
của nó mà không thay đổi hành vi của hệ thống. Chuyển 
đổi mã nhằm mục đích cải thiện thiết kế của một hệ 
thống làm việc bằng cách tập trung vào một lĩnh vực cụ 
thể hoặc phương pháp của một lớp. Để đảm bảo rằng 
việc chuyển đổi mã không thay đổi hành vi của hệ 
thống, chuyển đổi mã được thực hiện theo từng bước 
nhỏ, gia tăng được xen kẽ với các kiểm thử. Với các bộ 
kiểm thử, lập trình viên có thể tự tin thay đổi mã và thay 
đổi giao diện ít một trong quá trình chuyển đổi mã. 
40 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Chuyển đổi mã 
 Ví dụ, mô hình đối tượng của hình 7-6 tương ứng với ba 
lớp trong đoạn code hình dưới đây. Sau khi chuyển đổi 
mã ta có thêm lớp User, còn các lớp kia trở thành lớp 
con của lớp User. 
41 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Kỹ thuật chuyển tiếp 
 Kỹ thuật chuyển tiếp (Forward Engineering) được áp 
dụng cho một các yếu tố mô hình và kết quả là tập hợp 
mã nguồn tương ứng, chẳng hạn như một khai báo lớp, 
một biểu thức Java, hoặc lược đồ một cơ sở dữ liệu. Mục 
đích của kỹ thuật chuyển tiếp là duy trì một sự tương 
ứng chặt chẽ giữa mô hình thiết kế đối tượng và mã, và 
để giảm số lượng các lỗi sinh ra trong quá trình thực 
hiện, từ đó giảm công sức thực hiện. 
42 
4 Chuyển đổi các thiết kế sang mã chương trình 
 Kỹ thuật chuyển tiếp 
 hình dưới đây [30] mô tả một kỹ thuật chuyển tiếp áp 
dụng cho lớp User (người dùng) và lớp LeagueOwner 
(chủ giải thi đấu). Đầu tiên, mỗi lớp UML được ánh xạ 
tới một lớp Java. Tiếp theo, các mối quan hệ UML được 
ánh xạ tới sự mở rộng trong lớp LeagueOwner. Cuối 
cùng, mỗi thuộc tính trong mô hình UML được ánh xạ 
tới một biến private trong các lớp Java và hai phương 
pháp public để thiết lập và nhận được giá trị. Nhà phát 
triển có thể tinh chỉnh kết quả của việc chuyển đổi, ví 
dụ, để kiểm tra các giá trị mới của maxNumLeagues là 
một số nguyên dương. 
43 
4 Chuyển đổi các thiết kế sang mã chương trình 
44 
Tóm tắt 
Kiến trúc hệ thống và phát sinh mã trình 
 6.1 Kiến trúc của hệ thống 
 6.2 Biểu đồ thành phần 
 6.3 Biểu đồ triển khai 
 6.4 Chuyển đổi các thiết kế sang mã chương trình 
45 
DISCUSSION – CÂU HỎI 
https://sites.google.com/site/daonamanhedu/teac
hing/objectorientedanalysisanddesign 
46