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...
Trang 1PHÂ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
Trang 2RESOURCE - 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
Trang 3CONTENT – 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
Trang 41 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
Trang 51 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à
Trang 61 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
Trang 71 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
Trang 81 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
Trang 91 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
Trang 10trì, và hiểu
10
Trang 111 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
Trang 12 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
Trang 1313
Trang 14thuộ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
Trang 151 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
Trang 1616
Trang 171 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
Trang 18thà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
Trang 19là 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
Trang 202 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 <<component>> 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 <<artifact>> 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ư <<executable>>
20
Trang 213 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
Trang 223 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
Trang 233 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 <<device>> 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
<<execution environment>>, xem hình dưới đây:
23
Trang 243 Biểu đồ triển khai
Nút
24
Trang 252 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
Trang 262 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 <<deployment spec>>
26
Trang 272 Biểu đồ thành phần
Triển khai vật phẩm
27
Trang 282 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
Trang 292 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
Trang 302 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
Trang 312 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à
Trang 322 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
Trang 334 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
Trang 344 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
Trang 354 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
Trang 364 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
Trang 374 Chuyển đổi các thiết kế sang mã chương trình
37
Trang 384 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