Công nghệ phần mềm ôn tập chương 6

Software Architecture : là kế hoạch chi tiết cho một xây dựng và phát triển hệ thống phần mềm , là các tổ chức cơ bản của một hệ thống , thể hiện trong các thành phần của nó , các mối qu

Software Architecture Design

Chủ đề bao gồm :

o Các quyết định thiết kế kiến trúc ( Architecture Design Decisions )

o Các mô hình kiến trúc ( Architecture patterns )

o Kiến trúc ứng dụng ( Application architectures)

1 Software Architecture : là kế hoạch chi tiết cho một xây dựng và phát triển hệ thống phần mềm , là các tổ chức cơ bản của một hệ thống , thể hiện trong các thành phần của nó , các mối quan hệ của các tổ chức với nhau và môi trường , và các nguyên tắc điều chỉnh thiết kế và phát triển tổ chức và là những gì kiến trúc sư phần mềm phải làm

a Architecture Design : là quá trình thiết kế cho việc xác định các sub-systems tạo nên 1 hệ thống ( system ) và framwork cho việc điều khiển và truyền các thông tin liên lạc giữa các sub-systems( hệ thống con )

Kết quả đạt được của quá trình thiết kế ( design proccess ) là 1 bản mô tả cho Software Architecture

b Tính chất của Architecture Design :

Là giai đoạn đầu của thiết kế hệ thống ( the system design proccess ) Đại diện cho mối liên hệ giữa đặc tả kỹ thuật và quá trình thiết kế Thường thì tiến hành song song với 1 vài hoạt động đặc tả kỹ thuật Bao gồm ( liên quan ) đến việc xác định thành phần hệ thống quan trọng và thông tin liên lạc giữ các thành phần đó

c Cần phải có Software Architecture vì :

Giống như bất kỳ cấu trúc phức tạp khác, phần mềm phải được xây dựng trên một nền tảng vững chắc

Hệ thống cần được thiết kế với việc xem xét cho người sử dụng, hệ thống (cơ sở hạ tầng CNTT), và các mục tiêu kinh doanh Đối với mỗi lĩnh vực, chúng ta cần có bản phác thảo chính và xác định các thuộc tính quan trọng

Kiến trúc tập trung vào cách các yếu tố chính và các thành phần trong một ứng dụng được sử dụng , hoặc tương tác với các yếu tố lớn khác

và các thành phần bên trong ứng dụng chúng ta có thể xây dựng các giải pháp kiến trúc nhằm giải quyết tất cả các vấn đề có liên quan, có thể được triển khai trên cơ sở hạ tầng của bạn lựa chọn, và cung cấp kết quả đáp ứng các mục tiêu và mục tiêu ban đầu

2 Architectural abstraction (trừu tượng hóa kiến trúc ): Kiến trúc cho các phần mềm

sử dụng trừu tượng hóa phong phú để mô tả các thành phần hệ thống, bản chất của

sự tương tác giữa các thành phần, và các mô hình để hướng dẫn các thành phần của các thành phần vào hệ thống Các khái niệm trừu tượng cao cấp hơn so với các yếu tố thường được hỗ trợ bởi ngôn ngữ lập trình và các công cụ Các khái niệm

trừu tượng được sử dụng trong thực hành bởi nhà thiết kế phần mềm Nó phân biệt khác nhau giữa các loại thành phần và cách thức khác nhau các thành phần này có thể tương tác Hỗ trợ thực hiện các khía cạnh cao cấp như khía cạnh cao cấp của

hệ thống như tổ chức tổng thể, phân hủy thành các thành phần , phân công chức năng cho các thành phần, và cách các thành phần tương tác

a Đối với các kiến trúc nhỏ : có liên quan với kiến trúc của các chương trình cá nhân Ở cấp độ này, chúng tôi quan tâm với cách mà một chương trình cá nhân bị phân hủy thành các thành phần

b Đối với các kiến trúc lớn : là quan tâm đến kiến trúc của hệ thống doanh nghiệp phức tạp bao gồm các hệ thống khác, các chương trình, và các thành phần chương trình Các hệ thống doanh nghiệp được phân phối trên các máy tính khác nhau, có thể được sở hữu và các công ty khác nhau quản lý

3 Decomposition ( Phân hủy ) OR Modularizing: Đề cập đến quá trình hệ thống được chia thành các phần từ đó dễ dàng hơn để hiểu chương trình, và duy trì hoặc

hệ thống ( độ phức tạp cao ) = tập hợp các chương trình nhỏ ( ít phức tạp )

a Mục tiêu :

Tối đa hóa sự gắn kết Hạn chế tối đa khớp nối ( coupling )

4 Begin Selecting a Basic Architecture :

Cohesion : mức độ thông tin liên lạc giữa các yếu tố đưa

ra của module

Coupling : mức độ giao tiếp giữa các module

a B1: Xây dựng mô hình mental của các ứng dụng cấp cao như thể nó là ứng dụng nhỏ

Ví dụ : ứng dụng tài chính cá nhân : hoạt động bằng cách nhận các khoản tiền hoặc trả bằng tiền mặt , theo thứ tự , kiểm soát thông qua một giao diện người dùng

Metal model : có thể hiểu là mô hình đại diện của thực tế mà mọi người sử dụng để hiểu các hiện tượng cụ thể , ở đây là mô hình đại diện cho các ứng dụng cấp cao để có thể hiểu rõ các về các ứng dụng này

b B2: Phân hủy thành các thành phần cần thiết : tìm sự liên kết cao ( high

cohesion ) và low coupling

Ví dụ : ứng dụng tài chính cá nhân : phân hủy ( phân chia ) thành tài sản , nhà cung cấp và giao diện

c B3: lặp lại quá trình này cho các thành phần

5 Advantages of explicit architecture ( ưu điểm của kiến trúc rõ ràng ) :

a Stakeholder communication ( thông tin liên lạc giữa các bên liên quan ) : Kiến trúc có thể được sử dụng như là tiêu điểm của cuộc thảo luận của các bên liên quan đến hệ thống

b System analysis ( phân tích hệ thống ) : phân tích xem liệu hệ thống có thể đáp ứng yêu cầu phi chức năng của nó hay không ?

c Large – scale reuse ( tái sử dụng quy mô lớn ) : Các kiến trúc có thể được tái

Như vậy, rõ ràng, đầy đủ, và độ chính xác của các đại diện kiến trúc có tầm quan trọng then chốt

Nói 1 cách đơn giản : sơ đồ khối không chính thức cho thấy các thực thể và các mối quan hệ là phương pháp thường được sử dụng cho tài liệu kiến trúc phần mềm Tuy nhiên, những điều này đã bị chỉ trích vì thiếu ngữ nghĩa, không hiển thị các loại mối quan hệ giữa các thực thể cũng không nhìn thấy được của các đơn vị trong kiến trúc Phụ thuộc vào việc sử dụng mô hình kiến trúc Các yêu cầu đối với ngữ nghĩa mô hình phụ thuộc vào các mô hình được sử dụng

Cần phải có Kiến trúc đại diện cho kiến trúc phần mềm

7 Box and line diagrams : Rất là trừu tượng , sơ đồ này không hiển thị bản chất của mối quan hệ thành phần cũng như các thuộc tính bên ngoài có thể nhìn thấy của các Sub – Systems Tuy nhiên, sơ đồ này khá hữu ích cho việc giao tiếp với các bên liên quan và lập kế hoạch cho dự án

8 Use of architectural models ( Sử dụng các mô hình kiến trúc ) vì :

a Như một cách để tạo điều kiện thảo luận về thiết kế hệ thống

b Một quan điểm kiến trúc cấp cao của một hệ thống rất hữu ích cho việc giao tiếp với các bên liên quan hệ thống và lập kế hoạch dự án bởi vì các chi tiết được thể hiện rõ ràng không lộn xộn , rối rắm Các bên liên quan hiểu một cái nhìn trừu tượng của hệ thống Sau đó họ có thể thảo luận về các hệ thống như một toàn thể mà không bị nhầm lẫn bởi các chi tiết cụ thể

c Như một cách để ghi lại một kiến trúc đã được thiết kế

d Mục đích ở đây là để tạo ra một mô hình hệ thống hoàn chỉnh cho thấy các thành phần khác nhau trong một hệ thống, giao diện và kết nối của các thành phần đó

9 Architectural design decisions ( các quyết định thiết kế kiến trúc ) : Thiết kế kiến trúc là một quá trình sáng tạo nên quá trình này khác nhau tùy thuộc vào loại hệ

thống được phát triển.Tuy nhiên, một số quyết định chung rộng ra tất cả các quá trình thiết kế và những quyết định ảnh hưởng đến những đặc tính phi chức năng của hệ thống

a Lý do có các quyết định kiến trúc này : Một kiến trúc phần mềm có thể được coi là tập hợp các quyết định quan trọng liên quan đến việc thiết kế các phần mềm của một hệ thống Kiến thức về thiết kế này, tức là kiến thức kiến trúc,

là chìa khóa cho sự hiểu biết một kiến trúc phần mềm và do đó bản thân phần mềm Kiến thức kiến trúc chủ yếu chỉ tồn tại trong đầu của những

người sáng tạo Một vấn đề là loại kiến thức có thể dễ dàng bị mất Để giải quyết vần đề này cần tập trung vào một hình thức quan trọng của kiến trúc:

các quyết định thiết kế kiến trúc ( Architectural design decisions ) Hình

thức này rất là quan trọng, là quá trình kiến trúc , là tất cả về việc đưa ra những quyết định quan trọng

b Một khi đã hệ thống hóa, một kiến trúc phần mềm có thể được xem như là tập hợp các quyết định kiến trúc (thiết kế) Đặt một kiến trúc phần mềm vào một viễn cảnh mới và làm sâu sắc thêm sự hiểu biết của các bên liên quan Như công việc tương lai, chúng ta sẽ có kế hoạch để điều tra các loại kiến thức cần cho kiến trúc và mối quan hệ của các kiến thức để quyết định thiết

kế kiến trúc

c Khi đưa ra các quyết định kiến trúc ta có thể xem xét các câu hỏi sau :

Làm thế nào hệ thống sẽ được phân phối?

Những phong cách kiến trúc nào là phù hợp?

Phương pháp gì sẽ được sử dụng để cấu trúc hệ thống?

Làm thế nào hệ thống sẽ được chia ra thành các mô-đun?

Chiến lược kiểm soát gì nên được sử dụng?

Làm thế nào để đánh giá thiết kế kiến trúc?

Nên tạo document cho kiến trúc như thế nào ?

a Hệ thống trong cùng một tên miền thường có kiến trúc tương tự như phản chiếu bản chất của tên miền đó ( tạo nét đặc trưng riêng )

b Những dòng sản phẩm ứng dụng được xây dựng dựa trên một kiến trúc cốt lõi với các biến thể ( biến thể ở đây là các thứ bên cạnh có khả năng tiện dụng , dễ dàng thay đổi ) đáp ứng yêu cầu của khách hàng cụ thể

c Các kiến trúc của một hệ thống có thể được thiết kế theo một trong những

mô hình kiến trúc hoặc phong cách kiến trúc khác

Những phải nắm được bản chất của kiến trúc và có thể được khởi tạo trong cách khác nhau

13 Architectural views ( Quan điểm kiến trúc ) : Để có thể đưa ra các quan điểm kiến trúc hợp lý ta cần trả lời được các câu hỏi sau :

a Những quan điểm nào hay các quan điểm rất hữu ích khi thiết kế và lập tài liệu kiến trúc của hệ thống?

b Những ký hiệu nên được sử dụng để mô tả mô hình kiến trúc?

c Mỗi mô hình kiến trúc chỉ cho thấy một cái nhìn hay quan điểm của hệ

thống

Nó có thể hiển thị như thế nào một hệ thống được phân rã thành các mô-đun, làm thế nào các quá trình thời gian chạy tương tác hoặc những cách khác nhau, trong đó các thành phần hệ thống được phân phối qua mạng Đối với cả hai thiết kế và tài liệu hướng dẫn, bạn thường cần phải trình bày nhiều quan điểm của kiến trúc phần mềm

 4+1 view model of software architecture gồm Bốn điểm là hợp lý ( logical view ) , phát triển( development view ), quá trình( process view ) và vật lý( physical view ) Ngoài ra lựa chọn use cases or scenarios được sử dụng để minh họa cho kiến trúc như là “+1” view :

Chọn kiến trúc 1 vì tổng điểm cao nhất

o A logical view : Quan điểm hợp lý liên quan đến các chức năng mà hệ thống cung cấp cho người dùng cuối và cho thấy các khái niệm trừu tượng quan trọng trong hệ thống như các đối tượng hoặc các lớp đối tượng Biểu đồ UML được sử dụng để đại diện cho quan điểm hợp lý bao gồm Class diagram , Communication diagrams , Sequence diagram

thống, bao gồm các quá trình tương tác, giải thích các quy trình hệ thống

và cách nó giao tiếp, và tập trung vào các hành vi thời gian chạy của hệ thống Quan điểm quá trình giải quyết đồng thời, phân phối, tích hợp, hiệu suất và khả năng mở rộng, ,v.v… Biểu đồ UML để đại diện cho quan

điểm quá trình bao gồm các Activity diagram

quan điểm của một lập trình viên và liên quan đến phần mềm quản lý hay nói cách khác là tách ra để phát triển Nó sử dụng UML Component

diagram để mô tả các thành phần hệ thống Biểu đồ UML được sử dụng

để đại diện cho quan điểm phát triển bao gồm các Package diagram

thống , cho thấy các hệ thống phần cứng và làm thế nào các thành phần phần mềm được phân phối trên các bộ vi xử lý trong hệ thống Nó liên quan với các cấu trúc liên kết của các thành phần phần mềm trên lớp vật

lý, cũng như các kết nối vật lý giữa các thành phần này Quan điểm này cũng được biết đến như là điểm triển khai Biểu đồ UML được sử dụng để đại diện cho quan điểm vật lý bao gồm các Deployment diagram

 Use-case or Scenarios : Các mô tả của một kiến trúc được minh họa bằng một tập nhỏ các use-case , hoặc Scenarios mà trở thành một điểm thứ năm Các

Scenarios mô tả trình tự của các tương tác giữa các đối tượng, và giữa các quá trình Chúng được sử dụng để xác định các yếu tố kiến trúc và để minh họa và xác nhận thiết kế kiến trúc Nó cũng phục vụ như là một điểm khởi đầu cho các bài kiểm tra của một nguyên mẫu kiến trúc Quan điểm này cũng được biết đến

như sử dụng use-case

a Pattern ( Mô hình ) là một phương tiện đại diện, chia sẻ và tái sử dụng kiến thức

b Một mô hình kiến trúc là một mô tả cách điệu của thực hành thiết kế tốt, đã được thử và thử nghiệm trong môi trường khác nhau

c Các mô hình nên bao gồm thông tin về khi họ đang có và khi không hữu ích

d Các mô hình có thể được đại diện bằng cách sử dụng bảng và mô tả đồ họa

Ngăn cách trình bày và tương tác từ hệ thống dữ liệu Hệ thống này được kết cấu thành ba thành phần logic mà tương tác với nhau Các thành phần mô hình quản lý

hệ thống dữ liệu và các hoạt động liên quan đến dữ liệu đó Các thành phần View xác

đị nh và quản lý như thế nào dữ liệu được trình bày cho người dùng Các thành phần điều khiển quản lý tương tác người dùng (ví dụ, bấm phím, con chuột nhấp chuột, v v….) và vượt qua được những tương tác cho View và Model.

Ví dụ bên dưới cho thấy kiến trúc của một hệ thống ứng dụng web dựa trên tổ chức bằng cách sử dụng mô hình MVC

Được sử dụng khi có nhiều cách để xem và tương tác với dữ liệu Cũng được sử dụng khi các yêu cầu tương lai cho sự tương tác và trình bày các dữ liệu không rõ

Cho phép các dữ liệu để thay đổi một cách độc lập đại diện của mình và ngược lại Hỗ trợ trình bày của cùng một dữ liệu theo những cách khác nhau với những thay đổi được thực hiện trong một đại diện thể hiện trong tất cả chúng

Có thể liên quan đến việc bổ sung mã và mã phức tạp khi mà mô hình dữ liệu và tương tác rất đơn giản

16 MVC pattern : là một mô hình phần mềm để thực hiện các giao diện người dùng Nó chia một phần mềm ứng dụng cho thành ba phần liên kết với nhau, để phân biệt đại diện nội bộ của thông tin từ những cách mà thông tin được trình bày hoặc được chấp nhận từ người sử dụng Các thành phần trung tâm, mô hình, bao gồm các dữ liệu ứng dụng , quy tắc kinh doanh, logic, và các chức năng Một quan điểm có thể là đại diện đầu ra của thông tin, chẳng hạn như một biểu đồ hoặc một

sơ đồ Nhiều quan điểm của các thông tin tương tự có thể xảy ra, chẳng hạn như một biểu đồ thanh để quản lý và xem một bảng cho kế toán Phần thứ ba, bộ điều khiển, chấp nhận đầu vào và chuyển đổi nó để lệnh cho các mô hình hoặc xem

 Ngoài cách chia ứng dụng thành ba loại của các thành phần, các

Model-View-Controller (MVC) thiết kế xác định sự tương tác giữa chúng

o Một bộ điều khiển ( Controller ) có thể gửi các lệnh đến các mô hình

để cập nhật trạng thái của mô hình (ví dụ, chỉnh sửa tài liệu) Nó cũng

có thể gửi các lệnh để xem liên quan của nó để thay đổi trình bày của quan điểm của các mô hình (ví dụ, bằng cách di chuyển thông qua một tài liệu)

o Một mô hình ( Model ) thông báo quan liên quan và các bộ điều khiển của nó khi đã có một sự thay đổi trong trạng thái của nó Thông báo điều này cho phép các quan điểm để sản xuất ra được cập nhật, và các

bộ điều khiển để thay đổi các thiết lập có sẵn các lệnh Một thực hiện thụ động của MVC bỏ qua các thông báo, bởi vì các ứng dụng không đòi hỏi họ hoặc các nền tảng phần mềm không hỗ trợ họ

o Một quan điểm ( View ) yêu cầu thông tin từ các mô hình mà nó cần

để tạo ra một đại diện đầu ra cho người sử dụng

MVC là một trong những hiểu biết sâu sắc tinh của lĩnh vực đầu giao diện người dùng đồ họa

Một sự hợp tác điển hình của các thành phần MVC