Kiến Trúc Phần Mềm Thực Hành - Phiên Bản Thứ Ba

Khám phá những cuốn sách kiến trúc phần mềm nổi bật, cung cấp kiến thức và kỹ năng cần thiết cho lập trình viên và kiến trúc sư phần mềm.

Trường đại học

Carnegie Mellon University

Chuyên ngành

Software Engineering

Tác giả

Ẩn danh

Người đăng

Ẩn danh

Thể loại

book

2011

620
3
0

Phí lưu trữ

135 Point

Mục lục chi tiết

LỜI NÓI ĐẦU

HƯỚNG DẪN NGƯỜI ĐỌC

LỜI CẢM ƠN

1. CHƯƠNG 1: Kiến trúc phần mềm là gì?

1.1. Kiến trúc phần mềm là gì và không phải là gì

1.2. Các cấu trúc và khung nhìn kiến trúc

1.4. Điều gì tạo nên một kiến trúc "tốt"?

1.6. Tài liệu đọc thêm

1.7. Câu hỏi thảo luận

2. CHƯƠNG 2: Tại sao kiến trúc phần mềm lại quan trọng?

2.1. Ngăn cản hoặc hỗ trợ các thuộc tính chất lượng của hệ thống

2.2. Lập luận và quản lý sự thay đổi

2.3. Dự đoán chất lượng hệ thống

2.4. Tăng cường giao tiếp giữa các bên liên quan

2.5. Chuyển tải các quyết định thiết kế sớm

2.6. Xác định các ràng buộc đối với việc triển khai

2.7. Ảnh hưởng đến cấu trúc tổ chức

2.8. Cho phép tạo mẫu tiến hóa

2.9. Cải thiện ước tính chi phí và tiến độ

2.10. Cung cấp mô hình có thể chuyển giao và tái sử dụng

2.11. Cho phép kết hợp các thành phần được phát triển độc lập

2.12. Hạn chế vốn từ vựng của các phương án thiết kế

2.13. Cung cấp cơ sở cho việc đào tạo

2.15. Tài liệu đọc thêm

2.16. Câu hỏi thảo luận

3. CHƯƠNG 3: Các bối cảnh của kiến trúc phần mềm

3.1. Kiến trúc trong bối cảnh kỹ thuật

3.2. Kiến trúc trong bối cảnh vòng đời dự án

3.3. Kiến trúc trong bối cảnh kinh doanh

3.4. Kiến trúc trong bối cảnh nghề nghiệp

3.6. Kiến trúc bị ảnh hưởng như thế nào?

3.7. Kiến trúc ảnh hưởng đến những gì?

3.9. Tài liệu đọc thêm

3.10. Câu hỏi thảo luận

4. CHƯƠNG 4: Tìm hiểu về các thuộc tính chất lượng

4.1. Kiến trúc và các yêu cầu

4.3. Các cân nhắc về thuộc tính chất lượng

4.4. Đặc tả các yêu cầu thuộc tính chất lượng

4.5. Đạt được các thuộc tính chất lượng thông qua chiến thuật

4.6. Định hướng các quyết định thiết kế chất lượng

4.7. Tóm tắt

4.8. Tài liệu đọc thêm

4.9. Câu hỏi thảo luận

5. CHƯƠNG 5: Tính sẵn sàng

5.1. Kịch bản tổng quát về tính sẵn sàng

5.2. Chiến thuật cho tính sẵn sàng

5.3. Danh sách kiểm tra thiết kế cho tính sẵn sàng

5.5. Tài liệu đọc thêm

5.6. Câu hỏi thảo luận

6. CHƯƠNG 6: Khả năng tương tác

6.1. Kịch bản tổng quát về khả năng tương tác

6.2. Chiến thuật cho khả năng tương tác

6.3. Danh sách kiểm tra thiết kế cho khả năng tương tác

6.5. Tài liệu đọc thêm

6.6. Câu hỏi thảo luận

7. CHƯƠNG 7: Khả năng sửa đổi

7.1. Kịch bản tổng quát về khả năng sửa đổi

7.2. Chiến thuật cho khả năng sửa đổi

7.3. Danh sách kiểm tra thiết kế cho khả năng sửa đổi

7.5. Tài liệu đọc thêm

7.6. Câu hỏi thảo luận

8. CHƯƠNG 8: Hiệu năng

8.1. Kịch bản tổng quát về hiệu năng

8.2. Chiến thuật cho hiệu năng

8.3. Danh sách kiểm tra thiết kế cho hiệu năng

8.5. Tài liệu đọc thêm

8.6. Câu hỏi thảo luận

9. CHƯƠNG 9: Tính an toàn và bảo mật

9.1. Kịch bản tổng quát về bảo mật

9.2. Chiến thuật cho bảo mật

9.3. Danh sách kiểm tra thiết kế cho bảo mật

9.5. Tài liệu đọc thêm

9.6. Câu hỏi thảo luận

10. CHƯƠNG 10: Khả năng kiểm thử

10.1. Kịch bản tổng quát về khả năng kiểm thử

10.2. Chiến thuật cho khả năng kiểm thử

10.3. Danh sách kiểm tra thiết kế cho khả năng kiểm thử

10.5. Tài liệu đọc thêm

10.6. Câu hỏi thảo luận

11. CHƯƠNG 11: Khả năng sử dụng

11.1. Kịch bản tổng quát về khả năng sử dụng

11.2. Chiến thuật cho khả năng sử dụng

11.3. Danh sách kiểm tra thiết kế cho khả năng sử dụng

11.5. Tài liệu đọc thêm

11.6. Câu hỏi thảo luận

12. CHƯƠNG 12: Các thuộc tính chất lượng khác

12.1. Các thuộc tính chất lượng quan trọng khác

12.2. Các danh mục thuộc tính chất lượng khác

12.3. Thuộc tính chất lượng phần mềm và thuộc tính chất lượng hệ thống

12.4. Sử dụng danh sách tiêu chuẩn các thuộc tính chất lượng—hoặc không

12.5. Xử lý "khả năng X": Đưa một thuộc tính chất lượng mới vào hệ thống

12.6. Tài liệu đọc thêm

12.7. Câu hỏi thảo luận

13. CHƯƠNG 13: Các chiến thuật và mẫu kiến trúc

13.2. Tổng quan về danh mục mẫu

13.3. Mối quan hệ giữa các chiến thuật và mẫu

13.4. Sử dụng kết hợp các chiến thuật

13.6. Tài liệu đọc thêm

13.7. Câu hỏi thảo luận

14. CHƯƠNG 14: Mô hình hóa và phân tích thuộc tính chất lượng

14.1. Mô hình hóa kiến trúc để hỗ trợ phân tích thuộc tính chất lượng

14.2. Danh sách kiểm tra thuộc tính chất lượng

14.3. Thí nghiệm tư duy và phân tích sơ bộ

14.4. Thí nghiệm, mô phỏng và nguyên mẫu

14.5. Phân tích tại các giai đoạn khác nhau của vòng đời

14.7. Tài liệu đọc thêm

14.8. Câu hỏi thảo luận

15. CHƯƠNG 15: Kiến trúc trong các dự án Agile

15.1. Cần bao nhiêu kiến trúc?

15.2. Tính linh hoạt và các phương pháp kiến trúc

15.3. Ví dụ ngắn gọn về xây dựng kiến trúc Agile

15.4. Hướng dẫn dành cho kiến trúc sư Agile

15.6. Tài liệu đọc thêm

15.7. Câu hỏi thảo luận

16. CHƯƠNG 16: Kiến trúc và các yêu cầu

16.1. Thu thập ASR từ tài liệu yêu cầu

16.2. Thu thập ASR bằng cách phỏng vấn các bên liên quan

16.3. Thu thập ASR bằng cách tìm hiểu mục tiêu kinh doanh

16.4. Nắm bắt ASR trong cây tiện ích

16.5. Liên kết các phương pháp với nhau

16.7. Tài liệu đọc thêm

16.8. Câu hỏi thảo luận

17. CHƯƠNG 17: Thiết kế kiến trúc

17.2. Phương pháp thiết kế dựa trên thuộc tính (ADD)

17.3. Các bước thực hiện ADD

17.5. Tài liệu đọc thêm

17.6. Câu hỏi thảo luận

18. CHƯƠNG 18: Tài liệu hóa kiến trúc phần mềm

18.1. Mục đích sử dụng và đối tượng của tài liệu kiến trúc

18.2. Ký hiệu dùng trong tài liệu kiến trúc

18.4. Lựa chọn các khung nhìn

18.6. Xây dựng gói tài liệu

18.8. Tài liệu kiến trúc và các thuộc tính chất lượng

18.9. Tài liệu hóa kiến trúc thay đổi nhanh hơn tốc độ viết tài liệu

18.10. Tài liệu hóa kiến trúc trong dự án phát triển Agile

18.12. Tài liệu đọc thêm

18.13. Câu hỏi thảo luận

19. CHƯƠNG 19: Kiến trúc, triển khai và kiểm thử

19.1. Kiến trúc và triển khai

19.2. Kiến trúc và kiểm thử

19.4. Tài liệu đọc thêm

19.5. Câu hỏi thảo luận

20. CHƯƠNG 20: Tái cấu trúc kiến trúc và sự phù hợp

20.1. Quy trình tái cấu trúc kiến trúc

20.2. Trích xuất khung nhìn thô

20.5. Phân tích kiến trúc: Tìm kiếm các vi phạm

20.8. Tài liệu đọc thêm

20.9. Câu hỏi thảo luận

21. CHƯƠNG 21: Đánh giá kiến trúc

21.2. Phương pháp phân tích đánh đổi kiến trúc (ATAM)

21.3. Đánh giá kiến trúc tinh gọn

21.5. Tài liệu đọc thêm

21.6. Câu hỏi thảo luận

22. CHƯƠNG 22: Quản lý và quản trị

22.7. Tài liệu đọc thêm

22.8. Câu hỏi thảo luận

23. CHƯƠNG 23: Phân tích kinh tế của kiến trúc

23.1. Bối cảnh ra quyết định

23.2. Cơ sở cho các phân tích kinh tế

23.3. Đưa lý thuyết vào thực tiễn: CBAM

23.4. Nghiên cứu tình huống: Dự án NASA ECS

23.6. Tài liệu đọc thêm

23.7. Câu hỏi thảo luận

24. CHƯƠNG 24: Năng lực kiến trúc

24.1. Năng lực cá nhân: Nhiệm vụ, kỹ năng và kiến thức của kiến trúc sư

24.2. Năng lực của một tổ chức kiến trúc phần mềm

24.4. Tài liệu đọc thêm

24.5. Câu hỏi thảo luận

25. CHƯƠNG 25: Kiến trúc và dòng sản phẩm phần mềm

25.1. Ví dụ về tính khả biến của dòng sản phẩm

25.2. Điều gì làm cho dòng sản phẩm phần mềm hoạt động hiệu quả?

25.3. Phạm vi dòng sản phẩm

25.4. Thuộc tính chất lượng của tính khả biến

25.5. Vai trò của kiến trúc dòng sản phẩm

25.7. Đánh giá kiến trúc dòng sản phẩm

25.8. Các vấn đề then chốt trong dòng sản phẩm phần mềm

25.10. Tài liệu đọc thêm

25.11. Câu hỏi thảo luận

26. CHƯƠNG 26: Kiến trúc trên nền tảng đám mây

26.1. Các định nghĩa cơ bản về đám mây

26.2. Các mô hình dịch vụ và tùy chọn triển khai

26.6. Xây dựng kiến trúc trong môi trường đám mây

26.8. Tài liệu đọc thêm

26.9. Câu hỏi thảo luận

27. CHƯƠNG 27: Kiến trúc cho điện toán biên

27.1. Tổng quan

Tóm tắt

I. Tổng quan về Kiến Trúc Phần Mềm Thực Hành Phiên Bản Thứ Ba

Kiến trúc phần mềm là một lĩnh vực quan trọng trong phát triển phần mềm, giúp định hình cấu trúc và tổ chức của hệ thống. Phiên bản thứ ba của tài liệu này cung cấp cái nhìn sâu sắc về các nguyên tắc và phương pháp thiết kế kiến trúc phần mềm. Nó không chỉ giúp các nhà phát triển hiểu rõ hơn về kiến trúc mà còn cung cấp các công cụ và kỹ thuật cần thiết để xây dựng phần mềm chất lượng cao.

1.1. Định nghĩa Kiến Trúc Phần Mềm

Kiến trúc phần mềm là sự tổ chức và cấu trúc của hệ thống phần mềm, bao gồm các thành phần và mối quan hệ giữa chúng. Nó đóng vai trò quan trọng trong việc đảm bảo rằng phần mềm đáp ứng được các yêu cầu về hiệu suất, bảo mật và khả năng mở rộng.

1.2. Tầm quan trọng của Kiến Trúc Phần Mềm

Kiến trúc phần mềm không chỉ ảnh hưởng đến chất lượng sản phẩm cuối cùng mà còn quyết định đến quy trình phát triển. Một kiến trúc tốt giúp giảm thiểu rủi ro và chi phí, đồng thời tăng cường khả năng bảo trì và phát triển trong tương lai.

II. Các Thách Thức trong Kiến Trúc Phần Mềm Hiện Nay

Trong bối cảnh phát triển phần mềm ngày càng phức tạp, các thách thức trong kiến trúc phần mềm cũng ngày càng gia tăng. Các vấn đề như khả năng mở rộng, bảo mật và tích hợp hệ thống là những yếu tố cần được xem xét kỹ lưỡng.

2.1. Khả năng Mở Rộng và Tính Linh Hoạt

Khả năng mở rộng là một trong những thách thức lớn nhất trong kiến trúc phần mềm. Hệ thống cần có khả năng mở rộng để đáp ứng nhu cầu ngày càng tăng của người dùng mà không làm giảm hiệu suất.

2.2. Bảo Mật và Quản Lý Rủi Ro

Bảo mật là một yếu tố quan trọng trong kiến trúc phần mềm. Các nhà phát triển cần phải đảm bảo rằng hệ thống được thiết kế để chống lại các mối đe dọa và rủi ro bảo mật.

III. Phương Pháp Phát Triển Kiến Trúc Phần Mềm Hiệu Quả

Để phát triển kiến trúc phần mềm hiệu quả, cần áp dụng các phương pháp và kỹ thuật phù hợp. Các phương pháp này giúp tối ưu hóa quy trình phát triển và đảm bảo chất lượng sản phẩm.

3.1. Mô Hình Kiến Trúc Phần Mềm

Mô hình kiến trúc phần mềm giúp định hình cấu trúc của hệ thống. Các mô hình này có thể bao gồm mô hình lớp, mô hình dịch vụ và mô hình microservices, mỗi mô hình có ưu điểm và nhược điểm riêng.

3.2. Quy Trình Phát Triển Kiến Trúc

Quy trình phát triển kiến trúc bao gồm các bước từ phân tích yêu cầu đến thiết kế và triển khai. Việc tuân thủ quy trình này giúp đảm bảo rằng kiến trúc được xây dựng một cách có hệ thống và hiệu quả.

IV. Ứng Dụng Thực Tiễn của Kiến Trúc Phần Mềm

Kiến trúc phần mềm không chỉ là lý thuyết mà còn có nhiều ứng dụng thực tiễn trong các dự án phát triển phần mềm. Việc áp dụng kiến trúc đúng cách có thể mang lại nhiều lợi ích cho tổ chức.

4.1. Cải Thiện Chất Lượng Phần Mềm

Một kiến trúc tốt giúp cải thiện chất lượng phần mềm bằng cách giảm thiểu lỗi và tăng cường khả năng bảo trì. Điều này đặc biệt quan trọng trong các dự án lớn và phức tạp.

4.2. Tăng Cường Khả Năng Tương Tác

Kiến trúc phần mềm cũng giúp tăng cường khả năng tương tác giữa các thành phần trong hệ thống. Điều này giúp cải thiện hiệu suất và khả năng mở rộng của hệ thống.

V. Kết Luận và Tương Lai của Kiến Trúc Phần Mềm

Kiến trúc phần mềm sẽ tiếp tục phát triển và thay đổi theo thời gian. Các công nghệ mới và phương pháp phát triển sẽ ảnh hưởng đến cách thức thiết kế và triển khai kiến trúc phần mềm.

5.1. Xu Hướng Mới trong Kiến Trúc Phần Mềm

Các xu hướng như kiến trúc microservices và DevOps đang trở thành tiêu chuẩn trong phát triển phần mềm. Những xu hướng này giúp tăng cường tính linh hoạt và khả năng mở rộng của hệ thống.

5.2. Tương Lai của Kiến Trúc Phần Mềm

Tương lai của kiến trúc phần mềm sẽ phụ thuộc vào sự phát triển của công nghệ và nhu cầu của thị trường. Các nhà phát triển cần phải luôn cập nhật kiến thức và kỹ năng để đáp ứng được những thay đổi này.

Tóm tắt và mô tả trên trang này được tạo với sự hỗ trợ của AI. Nếu bạn thấy nội dung không chính xác hoặc có vấn đề, vui lòng Báo lỗi nội dung.

10/07/2025
Sách kiến trúc phần mềm

Trích đoạn nội dung tài liệu

book Page i Thursday, March 20, 2003 7:21 PM Software Architecture in Practice Third Edition Second Edition i The SEI Series in Software Engineering Visit informit.com/sei for a complete list of available products. T he SEI Series in Software Engineering represents is a collaborative undertaking of the Carnegie Mellon Software Engineering Institute (SEI) and Addison-Wesley to develop and publish books on software engineering and related topics. The common goal of the SEI and Addison-Wesley is to provide the most current information on these topics in a form that is easily usable by practitioners and students. Books in the series describe frameworks, tools, methods, and technologies designed to help organizations, teams, and individuals improve their technical or management capabilities.

Some books describe processes and practices for developing higher-quality software, acquiring programs for complex systems, or delivering services more effectively. Other books focus on software and system architecture and product-line development. Still others, from the SEI’s CERT Program, describe technologies and practices needed to manage software and network security risk. These and all books in the series address critical problems in software engineering for which practical solutions are available.

Software Architecture in Practice Third Edition Len Bass Paul Clements Rick Kazman ▲ ▼▼ Addison-Wesley Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City The The The SEI SEIinSeries SEI Series Series ininSoftware SoftwareEngineering Software Engineering Engineering Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those Many Many of of the designations the designations appeardesignations used in this book, and by used bymanufacturers the manufacturers publisher and was awareandsellers of to distinguish asellers claim, thetheir to distinguish trademark products their arebeen products designations have claimed are printed claimedwith ini- tialas trademarks. ascapital letters orWhere trademarks. Where those thosedesignations in all capitals.

designationsappear appearin in this book, this andand book, thethe publisher publisherwaswas aware of a of aware trade- a trade- mark CMM, claim, markCMMI, claim, the thedesignations designations Capability have havebeen Maturity Model, beenprinted printed Capability with with Maturityinitial capital initial Modeling, letters capital Carnegie or in letters orall Mellon, in capitals. all and CERT, capitals. CERT Coordination Center areCMM, registered in the Capability CMMI, U. Patent and Trademark Maturity Office Model, by Carnegie Capability Mellon University.

Maturity Modeling, Carnegie Mellon, CERT, CMM, CMMI, Capability Maturity Model, Capability Maturity Modeling, Carnegie Mellon, CERT, ATAM; and Architecture Tradeoff Analysis Method; CMM Integration; COTS Usage-Risk Evaluation;Office CURE;byEPIC; Evolutionary and CERT Process CERT Coordination CoordinationCenter forUniversity. Centerare areregistered registeredin in thethe U. andand Patent Trademark Trademark Office Carnegie by Carnegie Integrating COTS Based Systems; Framework for Software Product Line Practice; IDEAL; Interim Profile; OAR; Mellon MellonOperationally University. Critical Threat, Asset, and Vulnerability Evaluation; Options Analysis for Reengineering; Personal Soft- OCTAVE; ATAM; ATAM; ware Architecture Architecture Process; Tradeoff PLTP; ProductTradeoff Analysis Analysis Line Technical Method; Probe; Method; CMM PSP; SCAMPI;CMM Integration; COTS Integration; SCAMPI COTS Usage-Risk Lead Appraiser; Usage-Risk SCAMPI Evaluation; Lead Evaluation; Assessor; SCE; SEI; CURE; SEPG; TeamEPIC; Evolutionary Software Process; and Process TSP for Integrating are service COTS Mellon marks of Carnegie Based University.

Systems; Framework for Software CURE; EPIC; Evolutionary Process for Integrating COTS Based Systems; Framework for Software Product Special Line Practice; permission IDEAL; to reproduce Interim portions Profile; of CMMI OAR; OCTAVE; for Development Operationally Critical (CMU/SEI-2010-TR-035), Threat, Asset,Mellon Product Line Practice; IDEAL; Interim Profile; OAR; OCTAVE; Operationally ©Critical 2010 byThreat, Carnegie Asset, and Vulnerability University, has been Evaluation; granted by the OptionsEngineering Software Analysis for Reengineering; Personal Software Process; PLTP; Institute. and Vulnerability Evaluation; Options Analysis for Reengineering; Personal Software Process; PLTP; Product The authorsLine Technical and publisher Probe; have taken PSP; care inSCAMPI; the SCAMPI preparation of this Lead book, Appraiser; but make no SCAMPI expressed orLead Assessor; implied warranty of any Product SCE; Line Technical Probe; PSP; SCAMPI; SCAMPI Lead Appraiser; SCAMPI Lead Assessor; kind andSEI; SEPG; assume Team Software no responsibility Process; for errors and TSP or omissions. Noare service liability marks of is assumed forCarnegie incidentalMellon University. or consequential damages in SCE; SEI; SEPG; Team Software Process; and TSP are service marks of Carnegie Mellon University.

connection with or arising Special permission to out of the use reproduce of the information portions or programsbycontained of works copyright Carnegieherein. Mellon University, as listed Special on The permission page 588, publisher offers to reproduce is granted by excellent portions the Software discounts on ofwhen works this Engineering book copyright Institute. ordered by Carnegie in quantity Mellon University, for bulk purchases as which or special sales, listedmay on page include 588, is electronic granted versions by the and/or Software custom Engineering covers and Institute. content particular to your business, training goals, marketing focus, and Many of the designations used by manufacturers and sellers to distinguish their products are claimed branding interests.

For more information, please contact: Many as of the designations trademarks. Where thoseused by manufacturers designations and book, appear in this sellersand to the distinguish publishertheir was products aware of are claimed a trade- asU. mark Corporate and Government trademarks. claim, the Where designations Sales those have designations appear been printed withininitial this book, capitaland the publisher letters was aware of a trade- or in all capitals.

(800) 382-3419 mark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or corpsales@pearsontechgroup.com Thesalesauthors implied For and warranty outside publisher of any the United have kind States, andtaken please carenoinresponsibility assume contact: the preparationforoferrors this book, but make or omissions. Nonoliability expressedis or implied assumed warranty Sales of any for incidental International kind and assume or consequential no responsibility damages in connection for witherrors or omissions. or arising out of the No use liability of the is assumed information fororincidental programs or international@pearsoned.com consequential contained herein.

damages in connection with or arising out of the use of the For information about buying this titleherein. information Visit us on the or Web: programs contained informit.com/aw in bulk quantities, or for special sales opportunities (which may include electronic The publisher Library of Congress versions; offers custom excellent cover discounts Cataloging-in-Publication designs; Data on and when this book contentordered particular to your for in quantity business, training or bulk purchases goals, marketing specialMary Chrissis, sales, focus, which Beth. mayorinclude branding interests), electronic please and/or versions contactcustom our corporate salescontent covers and department at corp- particular to your sales@pearsoned.com business, CMMI for development :or training goals, (800) guidelines382-3419. marketing focus, integration for process and branding interests.

For more information, please contact: and product improvement / Mary Beth Chrissis, Mike Konrad, Sandy Shrum. For government sales inquiries, please contact governmentsales@pearsoned. Corporate and Government Sales For Includes (800) questions 382-3419 about sales bibliographical outsideand references theindex., please contact international@pearsoned. ISBN us Visit corpsales@pearsontechgroup.com 978-0-321-71150-2 (hardcover : alk.

paper) on the Web: informit. Capability maturity model (Computer software) 2. Software For sales outside engineering. the United States, please contact: Library of3.Congress Production engineering.

Manufacturing Cataloging-in-Publication processes. Shrum,Sales Sandy.com Software architecture in practice / Len Bass, Paul Clements, Rick Kazman.us on    the Web:series cm.com/aw in software engineering) 2010049515    Includes Copyright © 2011bibliographical references Pearson Education, Inc. Library    ISBNof 978-0-321-81573-6 Congress Cataloging-in-Publication Data 1. System (hardcover : alk.

paper) All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be design. Clements, from Paul, the publisher 1955– prior to anyII.prohibited Kazman,reproduction, Rick.

storage in a retrieval system, or transmission in any form or by   QA76.B37 any Software means, electronic, 2012 inphotocopying, architecture mechanical, practice / Len Bass, Paul recording, Clements, or likewise.—3rd For information ed. regarding permissions, write to:   005. Education, Pearson cm.series in software engineering) Includes Rights bibliographical and Contracts Department references and index. 2012023744 501 ISBN ©978-0-321-81573-6 Boylston Copyright Street,Pearson 2013 (hardcover Suite 900Education, Inc.

02116 Clements, Paul, 1955– All rights Fax: (617)reserved. 671-3447 Printed in the II. Kazman, United StatesRick.This publication is protected by copy- of America.B37 and permission 2012 must be obtained from the publisher prior to any prohibited reproduction, stor- ISBN-13:005.1—dc23 978-0-321-71150-2 age ISBN-10:in a retrieval system, 0-321-71150-5 or transmission in any form or by any means, electronic, mechanical, pho- tocopying, recording, or likewise. To obtain permission to use material from this work, 2012023744 please submit Text printed in the United States on recycled paper at Courier in Westford, Massachusetts.

aCopyright Firstwritten printing,request © 2013 March toPearson 2011PearsonEducation, Education,Inc., Permissions Department, 200 Old Tappan Road, Old Tappan, New Jersey 07657, or you may fax your request to (201) 236-3290. All rights reserved. Printed in the United States of America. This publication is protected by copy- ISBN-13: right, and 978-0-321-81573-6 permission must be obtained from the publisher prior to any prohibited reproduction, stor- ISBN-10: 0-321-81573-4 age in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photo- copying, Text printedrecording, or likewise.

in the United Torecycled States on obtain permission to useinmaterial paper at Courier from Westford, this work, please submit a Massachusetts. written Fifth requestSeptember printing, to Pearson Education, Inc., Permissions Department, One Lake Street, Upper Saddle 2015 River, New Jersey 07458, or you may fax your request to (201) 236-3290. ISBN-13: 978-0-321-81573-6 ISBN-10: 0-321-81573-4 Text printed in the United States on recycled paper at Courier in Westford, Massachusetts. Second printing, May 2013 Contents Preface  xv Reader’s Guide  xvii Acknowledgments  xix Part ONE Introduction  1 CHAPTER  1 What Is Software Architecture?   3 1.1 What Software Architecture Is and What It Isn’t    4 1.2 Architectural Structures and Views    9 1.4 What Makes a “Good” Architecture?    19 1.6 For Further Reading    22 1.7 Discussion Questions    23 CHAPTER  2 Why Is Software Architecture Important?   25 2.1 Inhibiting or Enabling a System’s Quality Attributes    26 2.2 Reasoning About and Managing Change    27 2.3 Predicting System Qualities     28 2.4 Enhancing Communication among Stakeholders    29 2.5 Carrying Early Design Decisions    31 2.6 Defining Constraints on an Implementation    32 2.7 Influencing the Organizational Structure     33 2.8 Enabling Evolutionary Prototyping    33 v vi Contents 2.9 Improving Cost and Schedule Estimates    34 2.10 Supplying a Transferable, Reusable Model    35 2.11 Allowing Incorporation of Independently Developed Components    35 2.12 Restricting the Vocabulary of Design Alternatives    36 2.13 Providing a Basis for Training    37 2.15 For Further Reading    38 2.16 Discussion Questions    38 CHAPTER  3 The Many Contexts of Software Architecture  39 3.1 Architecture in a Technical Context    40 3.2 Architecture in a Project Life-Cycle Context    44 3.3 Architecture in a Business Context    49 3.4 Architecture in a Professional Context    51 3.6 How Is Architecture Influenced?    56 3.7 What Do Architectures Influence?     57 3.9 For Further Reading    59 3.10 Discussion Questions    60 Part TWO Quality Attributes  61 CHAPTER  4 Understanding Quality Attributes   63 4.1 Architecture and Requirements    64 4.3 Quality Attribute Considerations     65 4.4 Specifying Quality Attribute Requirements    68 4.5 Achieving Quality Attributes through Tactics    70 4.6 Guiding Quality Design Decisions    72 4.7 Summary    76 Contents vii 4.8 For Further Reading    77 4.9 Discussion Questions    77 CHAPTER  5 Availability  79 5.1 Availability General Scenario    85 5.2 Tactics for Availability    87 5.3 A Design Checklist for Availability    96 5.5 For Further Reading    99 5.6 Discussion Questions    100 CHAPTER  6 Interoperability  103 6.1 Interoperability General Scenario    107 6.2 Tactics for Interoperability    110 6.3 A Design Checklist for Interoperability    114 6.5 For Further Reading    116 6.6 Discussion Questions    116 CHAPTER  7 Modifiability  117 7.1 Modifiability General Scenario    119 7.2 Tactics for Modifiability    121 7.3 A Design Checklist for Modifiability    125 7.5 For Further Reading    128 7.6 Discussion Questions    128 CHAPTER  8 Performance  131 8.1 Performance General Scenario    132 8.2 Tactics for Performance    135 8.3 A Design Checklist for Performance    142 8.5 For Further Reading    145 8.6 Discussion Questions    145 CHAPTER  9 Security  147 9.1 Security General Scenario    148 9.2 Tactics for Security    150 viii Contents 9.3 A Design Checklist for Security    154 9.5 For Further Reading    157 9.6 Discussion Questions    158 CHAPTER  10 Testability  159 10.1 Testability General Scenario    162 10.2 Tactics for Testability    164 10.3 A Design Checklist for Testability    169 10.5 For Further Reading    172 10.6 Discussion Questions    173 CHAPTER  11 Usability  175 11.1 Usability General Scenario    176 11.2 Tactics for Usability    177 11.3 A Design Checklist for Usability    181 11.5 For Further Reading    183 11.6 Discussion Questions    183 CHAPTER  12 Other Quality Attributes   185 12.1 Other Important Quality Attributes    185 12.2 Other Categories of Quality Attributes    189 12.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ

Tài liệu Kiến Trúc Phần Mềm Thực Hành - Phiên Bản Thứ Ba cung cấp một cái nhìn sâu sắc về các nguyên tắc và phương pháp thiết kế phần mềm hiệu quả. Nội dung của tài liệu không chỉ giúp người đọc hiểu rõ hơn về kiến trúc phần mềm mà còn trang bị cho họ những kỹ năng thực hành cần thiết để áp dụng vào các dự án thực tế. Một trong những điểm nổi bật của tài liệu là việc nhấn mạnh tầm quan trọng của việc lựa chọn kiến trúc phù hợp với yêu cầu của dự án, từ đó tối ưu hóa hiệu suất và khả năng bảo trì của phần mềm.

Để mở rộng thêm kiến thức về lĩnh vực này, bạn có thể tham khảo tài liệu Giáo trình kiến trúc và thiết kế phần mềm, nơi cung cấp hướng dẫn chi tiết về các phương pháp thiết kế và kiến trúc phần mềm hiệu quả. Đây là một cơ hội tuyệt vời để bạn khám phá thêm các khía cạnh khác nhau của kiến trúc phần mềm và nâng cao kỹ năng của mình trong lĩnh vực này.