CHƯƠNG 1 - KIẾN TRÚC PHẦN MỀM 1. Kiến trúc phần mềm Hệ thống phần mềm ngày một lớn và phức tạp. Điều này trở nên nhiều khó khăn đối với các nhà phát triển phần mềm trong việc đảm bảo chất lượng, kiểm soát các thay đổi, bảo trì phần mềm. Để giải quyết hiệu quả vấn đề này, hệ thống phần mềm cần có một kiến trúc tốt, đủ để cho phần mềm có thể đứng vững trước các thay đổi, bổ sung liên tục mà vẫn giảm thiểu được các chi phí.
Đây là mục đầu tiên, mang tính chất khái niệm, trước khi đi vào một số kiến trúc cụ thể như SOA, REST trong các mục sau. Trong mục này cũng sẽ trình bày một số vấn đề về kiến trúc phần mềm, giúp người phát triển phần mềm hoặc kiến trúc sư phần mềm có thể hiểu rõ và áp dụng cho công việc của mình. Định nghĩa kiến trúc phần mềm Kiến trúc phần mềm là thuật ngữ khó định nghĩa. Thực tế là chưa có một định nghĩa nào về kiến trúc phần mềm được chấp nhận một cách rộng rãi.
Để hiểu một cách đa dạng, nhiều khía cạnh, chúng ta sẽ đi qua một số định nghĩa tiêu biểu được tập hợp bởi Viện Kỹ nghệ phần mềm (Software Engineering Institute) [27]. Sau đây là định nghĩa đầu tiên của ANSI/IEEE [4]: Về mặt thực tế, kiến trúc được định nghĩa như là tổ chức cơ bản của một hệ thống, được biểu diễn bởi các thành phần, các quan hệ của chúng với nhau và với môi trường, cùng với các nguyên tắc bao trùm thiết kế và tiến hoá của nó. Định nghĩa thứ hai của L. Kazman [2]: Kiến trúc phần mềm của một chương trình hoăc hệ thống tính toán là cấu trúc hoặc các cấu trúc của hệ thống, nó bao gồm các phần tử phần mềm, các thuộc tính nhìn thấy bên ngoài của các phần tử đó, và các mối quan hệ giữa chúng.
Định nghĩa này có phần gần giống như định nghĩa của ANSI/IEEE. Định nghĩa thứ ba của D. Shaw [6]: Kiến trúc phần mềm vượt ra ngoài các giải thuật và các cấu trúc dữ liệu tính toán; việc thiết kế và xác định ra cấu trúc toàn bộ hệ thống trở nên như một dạng vấn đề mới. Các đề xuất cấu trúc bao gồm tổ chức toàn bộ và cấu trúc điều khiển toàn cục; các giao thức truyền thông, đồng bộ hoá, và truy nhập dữ liệu; gán chức năng cho các phần tử thiết kế; phân tán về vật lý; sự kết hợp của các phần tử thiết kế; mở rộng và hiệu năng; và sự lựa chọn giữa các cách thiết kế.
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 13 z Kiến trúc và chuẩn phần mềm trên nền web, ứng dụng xây dựng Hệ thống thi trắc nghiệm Phân tích các định nghĩa, chúng ta có thể rút ra được một số đặc tính cơ bản của các kiến trúc phần mềm. Trong phần tiếp theo sẽ mô tả một số cách tiếp cận chính để hiểu rõ hơn về kiến trúc phần mềm. Các đặc tính cơ bản của kiến trúc phần mềm Từ các định nghĩa về kiến trúc, chúng ta sẽ rút ra một số đặc tính cốt lõi của kiến trúc phần mềm như sau: 1. Kiến trúc định nghĩa cấu trúc Đa số các nhà kiến trúc sư đều đầu tư nhiều thời gian và công sức vào việc phân rã hệ thống ứng dụng thành các thành phần có quan hệ, các mô đun, ứng dụng.
Trong khi đó, một hệ thống ứng dụng có rất nhiều các yêu cầu và ràng buộc cần đáp ứng. Vì vậy, kiến trúc phần mềm đầu tiên là đưa ra được cấu trúc của hệ thống gồm các thành phần nào để đáp ứng được tất cả các yêu cầu và ràng buộc đó một cách tốt nhất. Trong quá trình phân rã một ứng dụng, kiến trúc sư gán các trách nhiệm cho mỗi thành phần. Các tránh nhiệm này định nghĩa tác vụ mà thành phần đó đảm nhận trong ứng dụng [7].
Kiến trúc xác định truyền thông giữa các thành phần Hệ thống phần mềm được phân rã thành các thành phần. Việc liên kết giữa các thành phần tạo nên những hoạt động của hệ thống. Vì vậy, kiến trúc cần xác định truyền thông giữa các thành phần này thông qua việc trao đổi dữ liệu, các thông tin điều khiển. Các thành phần này có thể được thực hiện trong cùng một không gian địa chỉ, trên các luồng hoặc tiến trình khác nhau.
Hoặc nhiều thành phần có thể đồng thời được báo hiệu khi có một sự kiện nào đó xẩy ra [7]. Kiến trúc đề cập các yêu cầu phi chức năng Các yêu cầu phi chức năng không xuất hiện trong các ca sử dụng (Use-case). Nó được phân loại thành các dạng: • Các ràng buộc kỹ thuật: chúng ràng buộc các lựa chọn thiết kế hoặc công nghệ cần phải sử dụng. Ví dụ, “chúng ta chỉ có các lập trình viên Java, vì vậy chúng ta phải phát triển trên Java”.
• Các ràng buộc nghiệp vụ: là các ràng buộc phi kỹ thuật, gắn với các công tác nghiệp vụ. • Các thuộc tính chất lượng: định nghĩa các ràng buộc ứng dụng về tính mềm dẻo, dễ mở rộng, dễ thay đổi, tái sử dụng, hiệu năng, vân vân. Các yêu cầu này này cần phải được đề cập một cách rõ ràng trong thiết kế. Ngoài các yêu cầu chức năng, các nhà kiến trúc sư thì cũng đều phải tính tới tất cả các yêu cầu phi chức năng [7].
Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 14 z Kiến trúc và chuẩn phần mềm trên nền web, ứng dụng xây dựng Hệ thống thi trắc nghiệm 1. Kiến trúc là sự trừu tượng hoá Bằng cách tạo dựng lên các thành phần, quan hệ giữa các thành phần, bản thân kiến trúc chính là sự trừu tượng hoá cho ứng dụng sẽ xây dựng. Nó là phương tiện dễ đọc, dễ hiểu và dễ trao đổi nhất giữa đội dự án, với cả các nhà tài trợ dự án [7]. Các khung nhìn kiến trúc Các khung nhìn kiến trúc được đưa ra trong mô hình 4+1 khung nhìn của Philippe Krutchen, năm 1995 [14]: Khung nhìn lô gic Khung nhìn thực thi (Logical View) (Implementation View) Người dùng Lập trình viên ối năng Chức Quản lý phần mềm Khung nhìn ca sử dụng (Use Case View) Khung nhìn tiến trình Khung nhìn triển khai (Process View) (Deployment View) Kỹ sư hệ thống Người tích hợp hệ thống Mô hình hệ thống Hiệu năng Chuyển giao, cài đặt Mở rộng Truyền thông Khái niệm Vật lý Hình 1 - Mô hình 4+1 khung nhìn Bao gồm: • Khung nhìn logic (Logical View): mô tả các phần tử kiến trúc quan trọng và mối quan hệ giữa chúng.
Nó đưa ra cấu trúc ứng dụng bằng các sơ đồ dạng Class Diagram hoặc tương đương. • Khung nhìn tiến trình (Process View): Tập trung mô tả các phần tử truyền thông và tương tranh của một kiến trúc. • Khung nhìn vật lý/triển khai (Physical View/Deployment View): nó mô tả làm thế nào các tiến trình và thành phần được ánh xạ với hệ thống phần cứng. Ví dụ như các cơ sở dữ liệu, máy chủ web được đưa vào một số các máy chủ.
• Khung nhìn phát triển/thực thi (Development View/Implementation View): nó tập trung vào tổ chức bên trong của các thành phần phần mềm, thông thường là chúng sẽ được đưa vào môi trường phát triển hoặc công cụ quản lý cấu hình. Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 15 z Kiến trúc và chuẩn phần mềm trên nền web, ứng dụng xây dựng Hệ thống thi trắc nghiệm Các khung nhìn này được gắn với một khung nhìn trung tâm là khung nhìn ca sử dụng (Use-case View). Đây là khung nhìn biểu diễn các chức năng của hệ thống. Tại sao kiến trúc phần mềm quan trọng Các lý do khiến cho kiến trúc phần mềm trở nên quan trọng [2]: • Trao đổi với các nhà tài trợ: kiến trúc phần mềm biểu diễn sự trừu tượng hoá chung của hệ thống.
Trong khi đó, đa số các nhà tài trợ không phải tất cả đều có chung một cơ sở để có thể hiểu nhau, thương lượng, quyết tâm. • Các quyết định thiết kế sớm: kiến trúc phần mềm biểu thị các quyết định sớm về thiết kế hệ thống. Nó là bức tranh toàn cảnh về hệ thống cần xây dựng mà các bước tiếp theo cần cụ thể hoá và chi tiết các phần này. • Trừu tượng hoá của một hệ thống có thể chuyển giao: Kiến trúc phần mềm tạo ra mô hình dễ hiểu, có tri thức, đủ nhỏ để làm thế nào một hệ thống được cấu trúc và làm thế nào các phần tử của nó làm việc cùng với nhau.
Đặc biệt, nó có thể được áp dụng sang các hệ thống khác có thuộc tính chất lượng, yêu cầu chức năng tương tự và có thể đẩy lên tái sử dụng quy mô lớn. Kết luận về kiến trúc phần mềm Kiến trúc phần mềm là một trong các yếu tố quan trọng, quyết định lớn tới toàn bộ quá trình phát triển phần mềm. Qua các định nghĩa, chúng ta hiểu về tầm quan trọng của kiến trúc phần mềm. Chúng hướng tới giải quyết các yêu cầu phi chức năng như khả năng sẵn sàng, dễ thay đổi, hiệu năng, an ninh, khả năng kiểm thử, khả năng sử dụng.
Các mục tiếp theo sẽ trình bày về một dạng kiến trúc phần mềm tiên tiến hiện nay và thu hút được sự quan tâm của nhiều người - Kiến trúc hướng dịch vụ, đặc biệt là trong môi trường dựa trên web và các công nghệ thực hiện. Kiến trúc hướng dịch vụ (SOA) Kiến trúc hướng dịch vụ (SOA – Service Oriented Architecture) là một kiểu kiến trúc mà tất cả các khía cạnh của việc tạo và sử dụng các tiến trình nghiệp vụ được đóng gói như các dịch vụ. Trong suốt chu trình sống của nó, cũng như việc định nghĩa và cung cấp cơ sở hạ tầng CNTT, SOA cho phép các ứng dụng khác nhau trao đổi dữ liệu và kết nối các tiến trình nghiệp vụ một cách lỏng lẻo, không phân biệt hệ điều hành và các ngôn ngữ lập trình bên dưới các ứng dụng đó. SOA biểu diễn một mô hình mà các chức năng của nó được phân rã vào trong các đơn vị nhỏ, khác nhau, có thể được phân tán qua mạng và có thể được kết hợp lại với nhau hoặc tái sử dụng để tạo ra các ứng dụng nghiệp vụ mới.
Các dịch vụ này truyền thông với nhau thông qua việc truyền dữ liệu từ dịch vụ này tới dịch vụ khác, hoặc kết hợp các hoạt động bởi hai hoặc Luận văn Thạc sĩ - Đỗ Đức Thảo Trang 16 z Kiến trúc và chuẩn phần mềm trên nền web, ứng dụng xây dựng Hệ thống thi trắc nghiệm nhiều dịch vụ. Khái niệm SOA thường được xây dựng và là bước phát triển hơn của các khái niệm cũ như tính toán phân tán và lập trình mô đun.