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

Nội dung text: 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

1. 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
2. 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
3. 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
4. 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
5. 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
6. 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
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 3 Biểu đồ triển khai  Nút 24
25. 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
26. 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
27. 2 Biểu đồ thành phần  Triển khai vật phẩm 27
28. 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
29. 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
30. 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
31. 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
32. 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
33. 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
34. 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
35. 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
36. 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
37. 4 Chuyển đổi các thiết kế sang mã chương trình 37
38. 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
39. 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
40. 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
41. 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
42. 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
43. 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
44. 4 Chuyển đổi các thiết kế sang mã chương trình 44
45. 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
46. DISCUSSION – CÂU HỎI hing/objectorientedanalysisanddesign 46