# Phân tích thiết kế hướng đối tượng
## Bài 1: Các bài học thực tiễn trong CNPM
### 1. Các vấn đề phát triển phần mềm
- Triệu chứng của Vấn đề Phát triển Phần mềm
- Không đáp ứng được nhu cầu của người dùng hoặc doanh nghiệp
- Không giải quyết được yêu cầu
- Các module không tích hợp được với nhau
- Gặp khó khăn trong việc bảo trì
- Phát hiện lỗi muộn
- Chất lượng kém của trải nghiệm người dùng cuối cùng
- Hiệu suất kém khi tải
- Thiếu sự đồng bộ trong nỗ lực của đội ngũ
- Vấn đề liên quan đến quá trình xây dựng và phát hành
- Liên kết các triệu chứng đến nguyên nhân gốc:
- 
- Bằng cách điều trị những nguyên nhân gốc này, bạn sẽ loại bỏ những triệu chứng. Bằng cách loại bỏ những triệu chứng, bạn sẽ có một vị thế tốt hơn để phát triển phần mềm chất lượng cao một cách lặp lại và dự đoán được.
- Best Practices là một tập hợp các phương pháp được chứng minh trong phát triển phần mềm, khi kết hợp sử dụng, sẽ tác động vào nguyên nhân gốc của các vấn đề. Chúng được gọi là "Best Practices", không phải vì chúng ta có thể đo lường chính xác giá trị của chúng, mà vì đã quan sát thấy chúng thường được sử dụng trong ngành công nghiệp bởi các tổ chức thành công. Những Best Practices này đã được thu hoạch từ hàng nghìn khách hàng trên hàng nghìn dự án và từ các chuyên gia ngành.
### 2. 6 Best Practices
#### a. Practice 1: Phát triển theo phương pháp lặp lại
- Mô hình thác nước:
- Trì hoãn xác nhận giải quyết rủi ro quan trọng
- Đánh giá tiến triển bằng cách đánh giá các sản phẩm công việc không phải là dự báo tốt về thời gian hoàn thành
- Trì hoãn và tổng hợp quá trình tích hợp và kiểm thử
- Ngăn chặn triển khai sớm
- Thường dẫn đến các vòng lặp lớn không kế hoạch
- Phát triển theo phương pháp lặp lại tạo ra một chương trình thực thi:
- 
- 
- Rish Profile: 
#### b. Practice 2: Quản lý yêu cầu
- Đảm bảo rằng bạn:
- Giải quyết vấn đề đúng đắn
- Xây dựng hệ thống đúng đắn
- bằng cách tiếp cận hệ thống đối với:
- Trích xuất
- Tổ chức
- Ghi chú
- Quản lý
- những yêu cầu thay đổi của một ứng dụng phần mềm.
- Các khía cạnh của quản lý yêu cầu
- Phân tích vấn đề
- Hiểu rõ nhu cầu của người dùng
- Xác định hệ thống
- Quản lý phạm vi
- Hiện thực lại định nghĩa hệ thống
- Quản lý yêu cầu thay đổi
- Mô hình phân vùng vấn đề/ giải pháp: 
#### c. Practice 3: Sử dụng Kiến trúc thành phần
- Phát triển phần mềm tập trung vào kiến trúc:
- Kiến trúc Phần mềm đại diện cho bản thiết kế của một phần mềm dưới dạng cấu hình hình học của các thành phần tính toán và các kết nối cho phép các kết nối ở cấp độ thành phần. [Tiêu chuẩn ISO/IEC/IEEE 42010]
- Phát triển Phần mềm điều chỉnh một phần mềm để đáp ứng các yêu cầu thay đổi và môi trường hoạt động thông qua việc thêm, loại bỏ và sửa đổi các sản phẩm phần mềm. [Chương trình Đào tạo Kỹ sư Phần mềm của ACM/IEEE, 2004]
- 
- Kiến trúc dựa trên thành phần có tính linh hoạt
- Tính linh hoạt
- Đáp ứng yêu cầu hiện tại và tương lai
- Nâng cao khả năng mở rộng
- Khả năng tái sử dụng
- Bao gồm các phụ thuộc của hệ thống
- Dựa trên thành phần
- Tái sử dụng hoặc tùy chỉnh các thành phần
- Lựa chọn từ các thành phần có sẵn có thể mua được
- Phát triển phần mềm hiện tại theo cách gia tăng.
- 
- Mục đích của Một Kiến trúc Dựa trên Thành phần:
- Cơ sở cho việc tái sử dụng
- Tái sử dụng thành phần
- Tái sử dụng kiến trúc
- Cơ sở cho quản lý dự án
- Lập kế hoạch
- Phân công nhân sự
- Giao hàng
- Kiểm soát trí tuệ
- Quản lý sự phức tạp
- Bảo toàn tính toàn vẹn
- 
#### d. Practice 4: Mô hình trực quan (UML)
- Tại sao lại mô hình trực quan?
- Ghi lại cấu trúc và hành vi
- Cho thấy cách các phần của hệ thống liên kết với nhau
- Giữ cho thiết kế và thực tiễn nhất quán
- Ẩn hoặc hiển thị chi tiết khi cần thiết
- Thúc đẩy giao tiếp không mơ hồ
- UML cung cấp một ngôn ngữ chung cho tất cả các người thực hành
- 
- Mô hình trực quan với UML
- 
- 
- 
#### e. Practice 5: Kiểm định chất lượng liên tục
- 
- 
- Yếu tố chất lượng phần mềm
- Chức năng: Các chức năng yêu cầu có sẵn trong phần mềm không?
- Dễ sử dụng: Phần mềm có dễ sử dụng không?
- Bảo trì: Làm thế nào để dễ dàng sửa đổi phần mềm?
- Đáng tin cậy: Phần mềm có độ tin cậy như thế nào?
- Sự linh hoạt: Làm thế nào để dễ dàng chuyển phần mềm sang môi trường khác?
- Hiệu suất: Hiệu suất của phần mềm như thế nào?
- Kiểm thử đa chiều về mặt chất lượng
- **Kiểm thử chức năng (Functionality)** xác nhận rằng hệ thống thực hiện các kịch bản sử dụng được yêu cầu theo ý định. Kiểm thử chức năng có thể bao gồm kiểm thử các tính năng, các kịch bản sử dụng, và an ninh.
- **Kiểm thử tính sẵn có (Usability)** đánh giá ứng dụng từ góc độ của người dùng. Kiểm thử tính sẵn có tập trung vào yếu tố con người, vẻ đẹp, tính nhất quán trong giao diện người dùng, trợ giúp trực tuyến và ngữ cảnh, các bước hướng dẫn và tác nhân, tài liệu người dùng và tài liệu đào tạo.
- **Kiểm thử độ tin cậy (Reliability)** xác nhận rằng ứng dụng hoạt động đáng tin cậy và không dễ gặp lỗi trong quá trình thực thi (sự treo, đóng ứng dụng, và rò rỉ bộ nhớ). Kiểm thử độ tin cậy hiệu quả yêu cầu các công cụ chuyên biệt. Các kiểm thử độ tin cậy bao gồm kiểm thử tính toàn vẹn, cấu trúc, áp lực, tranh chấp, và dung lượng.
- **Kiểm thử hiệu suất (Performance)** kiểm tra xem hệ thống mục tiêu hoạt động chức năng và đáng tin cậy dưới tải sản xuất. Các kiểm thử hiệu suất bao gồm các kiểm thử đánh giá, kiểm thử tải, và kiểm thử hồ sơ hiệu suất.
- **Kiểm thử hỗ trợ (Supportability)** xác nhận rằng ứng dụng có thể triển khai như ý định. Kiểm thử hỗ trợ bao gồm kiểm thử cài đặt và cấu hình.
- Kiểm tra mỗi một chu kỳ: 
- Kiểm thử trong Chu kỳ Phát triển Sản phẩm: 
#### f. Practice 6: Quản lý sự thay đổi:
- Bạn muốn kiểm soát những gì?
- Không gian làm việc an toàn cho mỗi nhà phát triển
- Quản lý tích hợp/xây dựng tự động
- Phát triển song song
- Quản lý Cấu hình là nhiều hơn chỉ là việc đăng ký và trả lại (check-in và check-out).
- 
- 
- Các khía cạnh của Hệ thống Quản lý Cấu hình (CM):
* Quản lý Yêu cầu Thay đổi (CRM) (Change Request Management)
* Báo cáo Tình trạng Cấu hình
* Quản lý Cấu hình (CM) (Configuration Management)
* Theo dõi Thay đổi
* Lựa chọn Phiên bản
* Sản xuất Phần mềm
- Quản lý Thay đổi Thống nhất (UCM) (Unified Change Management) bao gồm:
- Quản lý qua toàn bộ vòng đời
- Hệ thống
- Quản lý Dự án
- Quản lý Dựa trên Hoạt động
- Công việc
- Lỗi
- Cải tiến
- Theo dõi Tiến độ
- Biểu đồ
- Báo cáo
- 
#### g. Các Phương pháp Tốt Nhất Hỗ trợ Lẫn nhau:
- 
- 
### 3. Mối quan hệ tương quan giữu RUP và 6 Best Practices
- RUP cài đặt Best Practices:
- Rational Unified Process Implements Best Practices
- 
- Đạt được Best Practices
- Tiếp cận lặp lại
- Hướng dẫn cho các hoạt động và tư liệu
- Quy trình tập trung vào kiến trúc
- Sử dụng các ca sử dụng để thúc đẩy thiết kế và triển khai
- Mô hình hóa trừu tượng hóa hệ thống
- 
- 
- Một quy trình định nghĩa dựa trên một đội ngũ:
- Một quy trình xác định Ai đang thực hiện Cái Gì, Khi nào, và Bằng cách nào, nhằm đạt được một mục tiêu cụ thể.
- 
- Cấu Trúc Quy trình - Các Giai Đoạn Trong Vòng Đời
* RUP có bốn giai đoạn:
* Inception – Xác định phạm vi của dự án
* Elaboration – Lập kế hoạch cho dự án; xác định các tính năng và kiến trúc cơ bản
* Construction – Xây dựng sản phẩm
* Transition – Chuyển giao sản phẩm vào cộng đồng người sử dụng cuối cùng
* 
* 
- Các cột mốc quan trọng:
- 
- Lifecycle Objective Milestone (LCO): Đây là mốc quan trọng trong vòng đời của sản phẩm hoặc dự án. Tại mốc này, mục tiêu vòng đời của sản phẩm được xác định và đặt ra. Nó có thể bao gồm việc xác định các yêu cầu chính, định hình chiến lược và kế hoạch tổng thể cho việc phát triển.
- Lifecycle Architecture Milestone (LCA): Mốc này liên quan đến việc xác định kiến trúc của sản phẩm trong toàn bộ vòng đời. Ở mức này, kiến trúc cơ bản của hệ thống hoặc sản phẩm được xác định và đưa ra. Nó có thể bao gồm việc thiết kế các khía cạnh quan trọng như cấu trúc tổ chức, các thành phần chính, và mối quan hệ giữa chúng.
- Initial Operational Capability Milestone (IOC): Đây là mốc quan trọng khi sản phẩm hoặc hệ thống đạt được khả năng vận hành ban đầu. Điều này có thể bao gồm việc triển khai sản phẩm cho môi trường thực tế và kiểm tra khả năng vận hành cơ bản của nó.
- Product Release: Mốc phát hành sản phẩm đánh dấu thời điểm khi sản phẩm được chính thức phát hành và có sẵn cho người sử dụng cuối cùng hoặc khách hàng. Việc này có thể đi kèm với việc công bố công khai và quảng bá sản phẩm.
- 
- Các chu kỳ và giai đoạn:
- 
- Một chu kỳ là một chuỗi hoạt động cụ thể dựa trên một kế hoạch và tiêu chí đánh giá đã được xác định, kết quả là một phiên bản có thể thực thi (nội bộ hoặc ngoại vi).
- 
- Kết hợp Tất cả: Phương pháp Lặp Lại
- 
- 
- Các Lĩnh vực Tạo Ra Mô Hình
- 
- 
- Các Lĩnh vực Hướng Dẫn Phát Triển Lặp Lại
- 
- Trong mỗi lĩnh vực, các luồng công việc nhóm các hoạt động được thực hiện cùng nhau. Các luồng công việc của lĩnh vực sẽ xuất hiện ở mức độ khác nhau, phụ thuộc vào giai đoạn cụ thể.
- Tổng Quan về Các Khái Niệm của RUP:
- 
- 
### 4. Tổng kết
- Best Practices hướng dẫn kỹ thuật phần mềm bằng cách đối phó với nguyên nhân cơ bản.
- Best Practices củng cố lẫn nhau.
- Quy trình hướng dẫn đội ngũ về người nào làm gì, khi nào, và như thế nào.
- Rational Unified Process là một phương tiện để đạt được Best Practices.
## Bài 2: Mô hình hóa đối tượng
### 1. Mục tiêu:
- Giải thích các nguyên lý cơ bản của hướng đối tượng
- Xác định các khái niệm và thuật ngữ cơ bản về hướng đối tượng và các ký hiệu UML liên quan
- Thể hiện sức mạnh của hướng đối tượng
- Trình bày một số ký hiệu mô hình hóa UML cơ bản
### 2. Các nguyên lý cơ bản của hướng đối tượng:
- Mô hình hóa: Là sự đơn giản hóa các thực thể trong thực tế
- Tại sao cần mô hình:
- Để hiểu rõ hơn về hệ thống mà mình đang phát triển
- Mô hình hóa giúp đạt được 4 mục tiêu:
- Giúp ta hình dung một hệ thống như chúng ta mong muốn
- Cho phép chỉ định cấu trúc hoặc hành vi của một hệ thống
- Cung cấp mẫu hướng dẫn xây dựng hệ thống
- Ghi lại các quyết định
- Việc mô hình hóa các mô hình giúp ta hiểu được hệ thống đó
- Bốn nguyên tắc mô hình hóa
- Mô hình hóa chỉ ra được cách giải quyết vấn đề
- Mỗi mô hình thể hiện mức độ rõ ràng khác nhau
- Các mô hình tốt nhất khi chúng có liên hệ với thực tế
- Một mô hình đơn lẻ sẽ là không đủ
- Các phương pháp mô hình hóa
- Mô hình thủ tục
- Đặc điểm: Dựa trên chuỗi các bước thực hiện một tác vụ cụ thể.
- Ví dụ: Làm theo các bước để nấu ăn, sắp xếp dữ liệu trong mảng
- Mô hình hướng đối tượng
- Đặc điểm: Tập trung vào các đối tượng, mỗi đối tượng có thuộc tính và phương thức của nó.
- Ví dụ: Lập trình hướng đối tượng trong Java hoặc C++, trong đó mỗi lớp là một đối tượng có các thuộc tính và phương thức riêng.
- Mô hình dựa trên luật
- Đặc điểm: Sử dụng quy tắc và điều kiện để xác định hành vi hoặc kết quả.
- Ví dụ: Hệ thống chuyển mạch trạng thái dựa trên các luật logic, hệ thống chuyển đổi giữa các trạng thái khác nhau theo điều kiện.
- Mô hình hướng khía cạnh
- Đặc điểm: Tách biệt các khía cạnh khác nhau của hệ thống để giảm sự phức tạp và tăng tính module.
- Ví dụ: Sử dụng khía cạnh để quản lý ghi log, nâng cao tính chất chia rẽ (separation of concerns).
- Mô hình hướng tác nhân
- Đặc điểm: Tập trung vào các đơn vị tự trị (tác nhân) tương tác với môi trường.
- Ví dụ: Mô phỏng hành vi đám đông, nơi mỗi người có thể là một tác nhân có hành vi riêng và tương tác với nhau.
- Mô hình hướng dịch vụ
- Đặc điểm: Xây dựng hệ thống bằng cách sắp xếp các dịch vụ độc lập và tương tác qua giao diện chung.
- Ví dụ: Kiến trúc dựa trên dịch vụ (SOA) trong phát triển phần mềm, trong đó các dịch vụ độc lập cung cấp chức năng cụ thể.
- Mô hình dựa trên mô hình
- Đặc điểm: Xây dựng mô hình để mô tả và dự đoán hành vi của hệ thống.
- Ví dụ: Mô hình hóa hệ thống giao thông để dự đoán luồng xe và tìm ra các biện pháp cải thiện.
- KHÔNG CÓ CÁI NÀO LÀ TỐT NHẤT. SỬ DỤNG TÙY THEO TRƯỜNG HỢP.
- So sánh giữa Procedure-oriented vs Object-oriented:
- Procedure-oriented:
- Phân giải hàm (các hàm con)
- Cấu trúc kiểm soát (gọi các hàm)
- Chia sẻ và truy cập cùng một trung tâm dữ liệu
- 
- Object-oriented:
- Sự hợp tác giữa các đối tượng thông qua việc truyền đi các thông điệp
- Cục bộ hóa của các thay đổi!
- 
#### a. Object technology:
- Khái niệm: Một tập hợp các nguyên tắc hướng dẫn xây dựng phần mềm với các ngôn ngữ, CSDL và các công cụ khác hỗ trợ các nguyên tắc đó.
- Điểm mạnh:
- Cung cấp một mô hình duy nhất:
- Một “ngôn ngữ” duy nhất được sử dụng bởi cả người dung, người phân tích, thiết kế và người cài đặt.
- Tạo điều kiện tái sử dụng kiến trúc và mã nguồn.
- Các mô hình trở nên gần hơn với thế giới thực:
- Mô tả chính xác các thực thể
- Phân chia thành phần dựa theo thực tế
- Dễ hiểu, dễ bảo trì
- Cung cấp sự ổn định:
- Một thay đổi nhỏ trong yêu cầu không tạo ra sự thay đổi lớn trong quá trình phát triển.
- Thích nghi tốt với các thay đổi
- Object technology hỗ trợ triển khai các phương pháp tốt nhất:
- Phát triển lặp: Chấp nhận sự thay đổi trong yêu cầu, tạo điều kiện tái sử dụng
- Sử dụng kiến trúc dựa trên thành phần: nhấn mạnh vào kiến trúc, phát triển dựa trên thành phần.
- Mô hình trực quan: dễ hiểu, dễ sửa đổi.
- Hạn chế của Object Technology:
- Phức tạp, chi phí thiết kế cao
- Object-Oriented vs. Model-Driven:
- Nguyên Nhân: Trong mô hình hướng đối tượng, việc mô tả và thiết kế thường tập trung vào đối tượng và lớp, trong khi không tập trung đủ vào mô hình trừu tượng của toàn bộ hệ thống.
- Ví Dụ: Nếu có một dự án phức tạp với nhiều tầng và mối quan hệ phức tạp, việc sử dụng Object-Oriented có thể dẫn đến việc mô hình hóa không đầy đủ.
- Object-Oriented vs. Rule-Based:
- Nguyên Nhân: Cách tiếp cận Object-Oriented tập trung nhiều vào cấu trúc dữ liệu và hành vi của đối tượng, trong khi không nắm bắt đủ được các quy tắc và điều kiện.
- Ví Dụ: Trong một hệ thống yêu cầu nhiều luật kinh doanh, việc sử dụng Object-Oriented có thể làm mất đi tính linh hoạt khi phải thay đổi mã nguồn để thích ứng với các quy tắc mới.
- Object-Oriented vs. Service-Oriented:
- Nguyên Nhân: Trong Object-Oriented, sự tương tác giữa các đối tượng thường được thực hiện thông qua phương thức, trong khi Service-Oriented thúc đẩy việc tương tác thông qua dịch vụ độc lập.
- Ví Dụ: Khi cần tích hợp một hệ thống với các dịch vụ bên ngoài, sử dụng Service-Oriented có thể linh hoạt hơn so với việc gọi các phương thức của các đối tượng trong Object-Oriented.
- Object-Oriented vs. Aspect-Oriented:
- Nguyên Nhân: Trong Object-Oriented, các khía cạnh của hệ thống thường phải được xử lý trong các đối tượng, có thể dẫn đến mã nguồn phức tạp và khó hiểu.
- Ví Dụ: Trong trường hợp cần xử lý các khía cạnh như ghi log, việc tích hợp chúng vào các đối tượng có thể làm tăng độ phức tạp của mã nguồn.
- Object-Oriented vs. Implementing/Debugging/…:
- Nguyên Nhân: Việc triển khai và gỡ lỗi trong mô hình hướng đối tượng có thể đòi hỏi hiểu biết sâu rộng về các đối tượng và mối quan hệ giữa chúng.
- Ví Dụ: Trong khi gỡ lỗi, việc theo dõi và hiểu rõ các đối tượng và kế thừa có thể trở thành thách thức, đặc biệt là trong các hệ thống lớn.
### 3. Các nguyên tắc cơ bản của hướng đối tượng:
- Tính trừu tượng
- Tính đóng gói
- Tính mô-đun
- Tính phân cấp
#### a. Tính trừu tượng:
- Khái quát hoá các chi tiết quan trọng của một thực thể.
- Xác định ranh giới dựa trên các góc nhìn của người xem
- Không mô tả chi tiết, chỉ tập trung vào bản chất phân biệt của một thứ gì đó.
- Dưới đây là những ví dụ về sự trừu tượng.
- Một sinh viên là một người đăng ký học các lớp tại trường đại học.
- Giải thích: Ở đây, khái niệm "sinh viên" được trừu tượng hóa. Thay vì chỉ đề cập đến một cá nhân cụ thể, chúng ta đang nói về một nhóm lớn các người có chung đặc điểm là họ đang học tại trường đại học.
- Một giáo sư là một người giảng dạy các lớp tại trường đại học.
- Giải thích: Tương tự, trong trường hợp này, khái niệm "giáo sư" được trừu tượng hóa. Thay vì chỉ đề cập đến một người giáo viên cụ thể, chúng ta đang mô tả một nhóm người có chung đặc điểm là họ đang giảng dạy tại trường đại học.
- Một khóa học là một lớp được cung cấp bởi trường đại học.
- Một khóa học cụ thể là một phiên bản cụ thể cho một khóa học, bao gồm các ngày trong tuần và giờ học.
- Giải thích: Tại đây, chúng ta tiếp tục trừu tượng hóa khi nói về "khóa học cụ thể". Thay vì chỉ đề cập đến một buổi học cụ thể, chúng ta đang mô tả các phiên bản cụ thể của một khóa học, bao gồm thời gian và ngày trong tuần.
#### b. Tính đóng gói:
- Kết hợp các thuộc tính và phương thức của đối tượng, ẩn đi các cài đặt bên trong
- Khách hàng phụ thuộc vào giao diện
- Lưu ý:
- Đóng gói là việc đặt "bit dữ liệu" và các hoạt động thao tác chúng vào cùng một nơi.
- Đóng gói KHÔNG cho phép thao tác trực tiếp trên những thứ đã được đóng gói mà không sử dụng giao diện được cung cấp.
- Một ví dụ là chân ga của ô tô. Nói chung, bạn đặt chân xuống và ô tô chạy nhanh hơn. Bạn không phải lo lắng về dây cáp, điện tử, động cơ và các yếu tố khác.
- Minh họa:
- Giáo sư có khả năng dạy 4 lớp
- 
- Đóng gói quan trọng vì giao diện thông điệp của đối tượng đảm bảo rằng tất cả giao tiếp với đối tượng diễn ra qua một tập hợp các hoạt động đã được định nghĩa trước. Dữ liệu bên trong đối tượng chỉ có thể được tiếp cận thông qua các hoạt động của chính đối tượng đó. Trong ví dụ, khi một đối tượng khác muốn tăng số lớp tối đa mà Giáo sư Clark có thể giảng dạy, nó chỉ cần gửi một yêu cầu và sử dụng hoạt động SetMaxLoad(). Việc này giúp ẩn đi chi tiết cách thức thay đổi số lớp tối đa và giữ cho đối tượng yêu cầu không cần phải biết cụ thể về cách thức triển khai.
#### c. Tính mô đun:
- Mô đun hóa là sự chia nhỏ một cái gì đó phức tạp thành những phần có thể quản lý được.
- Mô đun hóa giúp con người hiểu được những vấn đề phức tạp.
#### d. Tính phân cấp:
- Các thành phần có cùng mức độ trừu tượng sẽ ở cùng cấp trong hệ thống phân cấp
- 
### 4. Các khái niệm cơ bản trong hướng đối tượng
- Đối tượng
- Lớp
- Thuộc tính
- Phương thức
- Đa hình
- Giao diện
- Một số khái niệm khác:
- Gói (Package)
- Các thành phần (Components)
- Hệ thống nhỏ (Subsystem)
- Mối quan hệ (association, dependency, generalization)
#### a. Đối tượng:
- Khái niệm: Là một đại diện cho một thực thể, có thể là vật lý, có thể là khái niệm, có thể là phần mềm.
- Định nghĩa khác: Là một thực thể có ranh giới và nhận dạng được xác định rõ ràng, bao gồm **trạng thái** và **hành vi**.
- Trạng thái được thể hiện bằng các thuộc tính và mối quan hệ
- Hành vi được thể hiện bằng các thao tác, phương thức và máy trạng thái.
- Trạng thái của đối tượng:
- Là một trong những điều kiện có thể tồn tại của vật đó.
- Thường thay đổi theo thời gian
- Hành vi của đối tượng:
- Xác định cách đối tượng hành động và phản ứng
- Hiển thị một đối tượng được mô hình hóa bằng tập hợp các thông báo mà nó có thể phản hồi (các hoạt động mà đối tượng có thể thực hiện)
- Định danh của đối tượng:
- Mỗi đối tượng có danh tính duy nhất, ngay cả khi trạng thái giống hệt với đối tượng khác.
- Biển diễn **đối tượng** bằng UML:
- Được biểu diễn bằng hình chữ nhật có tên được gạch chân
- 
#### b. Lớp (Class):
- Là sự mộ tả tập hợp các đối tượng có cùng **thuộc tính**, **hoạt động**, **mối quan hệ** và ngữ nghĩa
- Một đối tượng là thể hiện (instance) của lớp
- Lớp là một sự trừu tượng mà:
- Nhấn mạnh các đặc điểm liên quan
- Ngăn chặn các đặc điểm khác.
- Biểu diễn lớp bằng UML:
- Được biểu diễn bằng HCN có các cạnh ngăn
- 
#### c. Mối quan hệ giữa lớp và đối tượng:
- Một lớp là một định nghĩa trừu tượng của một đối tượng.
- Lớp xác định cấu trúc và hành vi của từng đối tượng thuộc lớp đó
- Lớp như một khuôn mẫu khởi tạo đối tượng.
- Lớp **không phải** là tập các đối tượng
- Lớp là mô tả tĩnh; đối tượng là một thể hiện thời gian chạy (run-time instance) của lớp đó.
- Bắt đầu với các đối tượng thế giới thực, trừ đi những điều bạn không quan tâm. Sau đó, lấy những trừu tượng này và phân loại, hoặc phân loại chúng, dựa trên những điều bạn quan tâm. Các lớp trong mô hình là kết quả của quá trình phân loại này.
#### d. Thuộc tính:
- Thuộc tính của lớp là các tính chất của các đối tượng thuộc lớp đó, mô tả phạm vi các giá trị mà thể hiện của thuộc tính đó có thể nhận.
- *Một lớp có thể có hoặc không có bất kỳ thuộc tính nào.*
- 
#### e. Phương thức:
- Phương thức là việc thực hiện một dịch vụ có thể được yêu cầu từ bất kỳ đối tượng nào của lớp để tác động đến hành vi.
- *Một lớp có thể có hoặc không có bất kỳ phương thức nào.*
#### f. Khuôn mẫu (Stereotypes):
- Xác định một thành phần mô hình mới theo một thành phần mô hình khác.
- Khuôn mẫu có thể được áp dụng cho tất cả các yếu tố mô hình, bao gồm các lớp, mối quan hệ, thành phần, v.v.
- Mỗi yếu tố UML chỉ có thể có một khuôn mẫu
#### g. Đa hình:
- Khả năng ẩn nhiều các triển khai khác nhau đằng sau một giao diện duy nhất.
- Ví dụ: 
- Trong ví dụ này, một đối tượng yêu cầu muốn biết giá trị hiện tại của một công cụ tài chính. Tuy nhiên, giá trị hiện tại cho mỗi công cụ tài chính được tính toán theo một cách khác nhau. Cổ phiếu cần xác định giá đề nghị hiện tại trên thị trường tài chính nơi nó được niêm yết. Trái phiếu cần xác định thời hạn đáo hạn và lãi suất. Một quỹ chung cần tra cứu giá đóng cửa cho ngày từ công ty quản lý quỹ đó.
- Trong một môi trường phát triển không hướng đối tượng, chúng ta sẽ viết mã có vẻ như sau:
-
```
IF financial Instrument = Stock THEN
calcStockValue ()
IP financial Instrument = Bond THEN
calcBondValue()
IF financial Instrument = MutualFund THEN
calcMutualFundValue()
```
#### h. Giao diện (Interface):
- Là cách thể hiện tính đa hình
- Các giao diện hỗ trợ kiến trúc "plug-and-play"
- 
- Cách biểu diễn:
- 
- Biểu diễn dưới dạng "lolipop" là cách tốt nhất khi cần chỉ ra sự tồn tại của một giao diện
- Nếu bạn cần xem chi tiết của giao diện (ví dụ như các thao tác), thì biểu diễn lớp/khuôn mẫu là phù hợp hơn.
#### i. Gói (Package):
- Gói là một cơ chế có mục đích chung để tổ chức các phần tử thành các nhóm.
- Gói là một phần tử mô hình có thể chứa các phần tử mô hình khác.
- Một gói có thể được sử dụng để:
- Tổ chức mô hình đang được phát triển.
- Như một đơn vị quản lý cấu hình.
#### k. Hệ thống con (Sub system):
- Là sự kết hợp của một gói (có thể chứa các phần tử mô hình khác) và một lớp (có hành vi)
- Thực hiện một hoặc nhiều giao diện xác định hành vi của nó.
#### l. Thành phần (Component):
- Thành phần: một phần quan trọng, gần như độc lập, có thể thay thế được của hệ thống, thực hiện một chức năng rõ ràng trong bối cảnh của một kiến trúc đã được xác định.
- Một thành phần có thể là:
- Một thành phần mã nguồn (ví dụ: tệp .h, .cpp, các tệp script shell, tệp dữ liệu)
- Một thành phần run time (ví dụ: Java Beans, COM Object: DLL và OCX).
- Một thành phần thực thi được (ví dụ: .exe).
#### m. Mối quan hệ giữa Sub-system và Component:
- Các thành phần là sự hiện thực hóa vật lý của một sự trừu tượng trong thiết kế.
- Các hệ thống con có thể được sử dụng để thể hiện thành phần trong thiết kế.
- Một thành phần tuân thủ và cung cấp sự hiện thực vật lý của một tập hợp các giao diện. Các thành phần là những đối tượng triển khai. Chúng là hiện thực vật lý của một trừu tượng trong thiết kế của bạn. Một hệ thống con có thể được sử dụng để đại diện cho thành phần trong thiết kế.
- Một hệ thống con là biểu diễn thiết kế của một thành phần. Cả hai đều bao gồm một tập hợp các hành vi có thể thay thế đằng sau một hoặc nhiều giao diện. Các hệ thống con và giao diện sẽ được thảo luận sau trong khóa học.
#### n. Các mối quan hệ:
##### n.1. Quan hệ kết hợp
- Là quan hệ ngữ nghĩa giữa các lớp: Xác định rằng các đối tượng của một chủ thể được kết nối với các đối tượng của một chủ thể khác.
- Mối quan hệ cấu trúc, chỉ định rằng các đối tượng của một đối tượng liên kết với các đối tượng của một cái khác.
- 
- Quan hệ kết hợp: đa bội
- Đa bội là số thể hiện của một lớp liên quan tới một thể hiện của lớp khác
- Với mỗi quan hệ kết hợp, có mỗi đa bội được đặt ở mỗi thực thể trong quan hệ kết hợp.
- VD: 
- Các chỉ số đa bội: 
##### n.2. Quan hệ thu nạp:
- Quan hệ thu nạp là một dạng liên kết đặc biệt mô hình hóa mối quan hệ toàn phần giữa một tổng hợp (toàn bộ) và các bộ phận của nó.
- Là kiểu quan hệ “a là một phần của b”.
- Đa bội giống như các quan hệ kết hợp khác.
- Một hình thoi rỗng được đính kèm ở cuối của một đường liên kết trên bên của tổng hợp (toàn bộ) để chỉ thu nạp.
- Mối quan hệ quy nạp có độ đa dạng lớn hơn một đối với tổng hợp được gọi là chia sẻ. Việc phá hủy tổng hợp không nhất thiết phá hủy các phần. Theo ngụ ý, một quy nạp chia sẻ tạo thành một đồ thị hoặc cây với nhiều gốc. Quy nạp chia sẻ được sử dụng khi có mối quan hệ mạnh mẽ giữa hai lớp. Do đó, cùng một thể hiện có thể tham gia vào hai quy nạp khác nhau.
- 
- Điều hướng:
- Chỉ ra rằng có khả năng điều hướng từ một lớp liên kết đến lớp mục tiêu bằng cách sử dụng mối liên kết.
- Thuộc tính điều hướng trên một vai trò chỉ ra rằng có khả năng điều hướng từ một lớp liên kết đến lớp mục tiêu bằng cách sử dụng mối liên kết. Điều này có thể được triển khai qua nhiều cách: bằng các tham chiếu trực tiếp đối tượng, các mảng kết hợp, bảng băm hoặc bất kỳ kỹ thuật triển khai nào cho phép một đối tượng tham chiếu đến đối tượng khác.
- Việc điều hướng được biểu thị bằng một mũi tên mở ở đầu mục tiêu của đường liên kết kế bên cạnh lớp mục tiêu (lớp đang được điều hướng tới). Giá trị mặc định của thuộc tính điều hướng là true (mối liên kết là hai chiều theo mặc định).
- Trong ví dụ về đăng ký khóa học, mối liên kết giữa Lịch trình và Khóa học được điều hướng ở cả hai hướng. Điều này có nghĩa là một Lịch trình phải biết về Khóa học được gán cho Lịch trình, và Khóa học phải biết về các Lịch trình mà nó đã được đặt vào.
- Khi không có đầu mũi tên nào được hiển thị, giả sử mối liên kết có thể được điều hướng ở cả hai hướng.
- Trong trường hợp của mối liên kết giữa Lịch trình và Bộ điều khiển Đăng ký, Bộ điều khiển Đăng ký phải biết về các Lịch trình của mình, nhưng các Lịch trình không có thông tin về Bộ điều khiển Đăng ký (hoặc các lớp khác). Do đó, thuộc tính điều hướng ở đầu mối Bộ điều khiển Đăng ký của mối liên kết này được tắt.
##### n.3. Quan hệ phụ thuộc:
- Là mối quan hệ giữa hai phần tử của mô hình trong đó sự thay đổi của phần tử này có thể làm thay đổi phần tử kia
- 
##### n.4. Quan hệ tổng quá hóa:
- Mối quan hệ giữa các lớp trong đó một lớp chia sẻ cấu trúc và/hoặc hành vi của một hoặc nhiều lớp.
- Xác định một hệ thống phân cấp trừu tượng trong đó một lớp con kế thừa từ một hoặc nhiều siêu lớp.
- Là kiểu quan hệ “a là một loại của b”.
- Ví dụ:
- 
- 
- Đa kế thừa có nghĩa là một lớp có thể kế thừa từ nhiều lớp khác nhau. Ví dụ, lớp Bird kế thừa cả từ FlyingThing và Animal. Đa kế thừa là một khái niệm khá trực quan và có thể cần thiết để mô hình thế giới thực một cách chính xác. Tuy nhiên, có thể xuất hiện vấn đề về cài đặt khi sử dụng đa kế thừa, và không phải tất cả các ngôn ngữ lập trình hỗ trợ nó. Do đó, hãy cân nhắc cẩn thận khi sử dụng đa kế thừa. Hãy sử dụng nó chỉ khi nó mô tả chính xác khái niệm bạn đang cố gắng mô hình và giảm độ phức tạp của mô hình của bạn. Tuy nhiên, hãy nhớ rằng biểu diễn này có thể cần được điều chỉnh trong quá trình thiết kế và triển khai. Nói chung, một lớp thường chỉ kế thừa từ một lớp.
- Một lớp con kế thừa các thuộc tính, thao tác và mối quan hệ của lớp cha.
- Một lớp con có thể:
- Thêm các thuộc tính, thao tác, mối quan hệ bổ sung
- Định nghĩa lại các thao tác được kế thừa (cần thận trọng!)
- Các thuộc tính, thao tác và/hoặc mối quan hệ chung được hiển thị ở mức cao nhất tương ứng trong cấu trúc phân cấp.
##### n.5. Quan hệ hiện thực hóa:
- Là quan hệ giữa một classifier đóng vai trò là hợp đồng và một classifier đóng vai trò thực hiện, có thể tìm thấy giữa:
- Các giao diện và các classifier hiện thực chúng.
- 
- Các ca sử dụng và các collaboration hiện thực chúng
- 
- Realization là một mối quan hệ ngữ nghĩa giữa hai bộ phân loại. Một bộ phân loại làm nhiệm vụ của hợp đồng mà bộ phân loại kia đồng ý thực hiện.
- Mối quan hệ thực hiện là sự kết hợp của một phụ thuộc và một tổng hợp. Đó không phải là sự tổng hợp thực sự, vì chỉ "hợp đồng" (nói cách khác, chữ ký thao tác) được "kế thừa." Sự "pha trộn" này được biểu diễn trong biểu đồ UML của nó, là sự kết hợp giữa phụ thuộc và tổng hợp.
- Mối quan hệ thực hiện có thể được mô phỏng như là một đường nét đứt với mũi tên trống trỏ vào bộ phân loại hợp đồng (dạng cơ bản), hoặc khi kết hợp với một giao diện, như là một "que kem" (dạng được lược bỏ).
#### o. Notes trong UML:
- Là một comment để bổ sung thông tin cho sơ đồ
- Có thể them vào bất kỳ thành phần UML nào.
- Là một hình chữ nhật cắt góc.
- Có thể neo vào một phần tử bằng cách sử dụng đường kẻ nét đứt
- 
## Bài 3: Tổng quan về yêu cầu phần mềm
### 1. Mục tiêu:
- Mô tả khái niệm cơ bản về Yêu cầu phần mềm và cách nó ảnh hưởng đến Phân tích và Thiết kế
- Trình bày cách đọc và diễn giải các thành phần của Yêu cầu phần mềm mà được sử dụng làm điểm khởi đầu cho Phân tích và Thiết kế
### 2. Nội dung:
- Giới thiệu
- Các khái niệm quan trọng
- Mô hình ca sử dụng
- Bảng chú giải
- Đặc tả bổ sung
- Checkpoints
### 3. Giới thiệu:
- Mục đích của Yêu cầu phần mềm là:
- Thiết lập và duy trì sự đồng thuận với khách hàng và các bên liên quan khác về những gì hệ thống nên thực hiện.
- Ví dụ: Trong dự án xây dựng ứng dụng đặt đồ ăn online, yêu cầu có thể mô tả rõ ràng về việc người dùng có thể thực hiện đặt hàng, thanh toán và theo dõi trạng thái đơn hàng. Các bên liên quan, bao gồm cả nhóm phát triển và đội ngũ kinh doanh, phải đồng thuận về quy trình này.
- Mang lại cho những nhà phát triển hệ thống sự hiểu biết tốt hơn về yêu cầu của hệ thống.
- Ví dụ: Trong dự án phát triển ứng dụng quản lý dự án, yêu cầu có thể đề cập đến việc hệ thống cần hỗ trợ quản lý các công việc, giao việc, và tạo báo cáo tiến độ. Việc mô tả chi tiết giúp nhóm phát triển hiểu rõ nhu cầu cụ thể của người sử dụng.
- Xác định quy mô của hệ thống.
- Ví dụ: Quy mô hệ thống thường được xác định bằng cách xác định các thành phần chính của hệ thống, các tác nhân ngoại vi mà hệ thống tương tác với, và phạm vi chức năng và phi chức năng của hệ thống.
- Cung cấp cơ sở để lập kế hoạch nội dung kỹ thuật của các vòng lặp.
- Ví dụ: Trong dự án phát triển ứng dụng di động, yêu cầu có thể chỉ định rằng trong vòng lặp đầu tiên, nhóm phát triển sẽ tập trung vào việc xây dựng giao diện người dùng và chức năng đăng nhập. Điều này giúp lập kế hoạch cho công việc cụ thể trong giai đoạn đầu tiên của dự án.
- Cung cấp cơ sở để ước lượng chi phí và thời gian phát triển hệ thống.
- Ví dụ: Trong dự án xây dựng trang web thương mại điện tử, yêu cầu có thể chỉ định rõ số lượng trang sản phẩm, tính năng thanh toán và tích hợp vận chuyển. Thông tin này giúp nhóm phát triển ước lượng chi phí và thời gian cần thiết.
- Định nghĩa giao diện người dùng của hệ thống.
- Ví dụ: Trong dự án phát triển ứng dụng đồng hồ thông minh, yêu cầu có thể mô tả cụ thể về cách mà người dùng có thể tương tác với các chức năng như theo dõi sức khỏe, nhận thông báo, và thực hiện cuộc gọi. Điều này giúp nhóm phát triển xây dựng một giao diện người dùng thân thiện và dễ sử dụng.
- Các tài liệu liên quan đến Yêu cầu phần mềm
- Biểu đồ ca sử dụng
- Bảng chú giải
- Bảng mô tả bổ sung
- Case study: Yêu cầu phần mềm của hệ thống đăng ký môn học.
### 4. Các khái niệm quan trọng
- Hành vi hệ thống là gì?
- Là cách mà hệ thống hành động và phản ứng
- Đó là hoạt động có thể quan sát và kiểm thử của hệ thống
- Hành vi của hệ thống được ghi lại trong các ca sử dụng
- Ca sử dụng mô tả về hệ thống, môi trường của nó và mối quan hệ giữa hệ thống và môi trường đó.
- Các khái niệm chính trong mô hình ca sử dụng
- Một tác nhân (Actor): Đại diện cho một thứ gì đó tương tác với hệ thống
- Một ca sử dụng: Là một chuỗi các hành động mà hệ thống có thể thực hiện, dẫn đến một kết quả có thể có thể quan sát được, có giá trị đối với tác nhân cụ thể
### 5. Mô hình ca sử dụng
- Khái niệm:
- Là mô hình mô tả cá yêu cầu chức năng của hệ thống dưới dạng ca sử dụng.
- Là mô hình của những chức năng dự định (ca sử dụng) và môi trường (tác nhân) của hệ thống.
- Lợi ích:
- **Giao tiếp** với người dùng cuối và chuyên gia lĩnh vực:
- Đảm bảo sự đồng thuận từ giai đoạn sớm của quá trình phát triển hệ thống.
- Đảm bảo sự hiểu biết chung về yêu cầu.
- Nhận dạng: Xác định người dùng hệ thống và những gì hệ thống nên làm:
- Thiết lập các yêu cầu cho giao diện hệ thống.
- Xác minh: Xác nhận rằng tất cả các yêu cầu đã được thu thập:
- Đảm bảo rằng nhóm phát triển hiểu rõ yêu cầu.
- Cách đọc biểu đồ
- Include: Include nghĩa là mối quan hệ bắt buộc phải có giữa các Use Case với nhau.
- Xét về nghĩa, Include nghĩa là bao gồm, tức nếu Use Case A có mối quan hệ include Use Case B, thì nghĩa là: Use Case A bao gồm Use Case B. Để Use Case A xảy ra, thì Use Case B phải đạt được.
- Extends: Extend là mối quan hệ mở rộng giữa các Use Case với nhau.
- Nếu Include là mối quan hệ bắt buộc, thì Extend là một mối quan hệ không bắt buộc. Nó thể hiện mối quan hệ có thể có hoặc có thể không giữa các Use Case với nhau.
- Đặc tả ca sử dụng
- Tên
- Mô tả ngắn gọn
- Luồng sự kiện
- Mối quan hệ
- Biểu đồ hoạt động
- Biểu đồ ca sử dụng
- Tiền điều kiện
- Hậu điều kiện
- Luồng sự kiện của ca sử dụng:
- Có một luồng chính
- Có nhiều luồng thay thế:
- Biến thể thông thường
- Những trường hợp kỳ lạ
- Luồng ngoại lệ để xử lý lỗi
- Kịch bản là gì?
- Kịch bản là một thể hiện của ca sử dụng
- 
- Biểu đồ hoạt động
- Được sử dụng để ghi lại những hành động có trong ca sử dụng
- Nó chủ yếu là một biểu đồ luồng, thể hiện luồng kiểm soát từ hoạt động này sang hoạt động khác.
- Ví dụ: 
- 
- Một biểu đồ hoạt động có thể bao gồm các yếu tố sau:
* **Trạng thái hoạt động** đại diện cho việc thực hiện một hoạt động hoặc bước trong quy trình làm việc.
* **Chuyển tiếp** cho thấy trạng thái hoạt động tiếp theo sau một trạng thái hoạt động khác.
* **Quyết định** đánh giá các điều kiện được xác định bởi các **điều kiện bảo vệ**. Những điều kiện bảo vệ này xác định chuyển tiếp thay thế nào sẽ được thực hiện và do đó, hoạt động nào sẽ được thực hiện. Bạn cũng có thể sử dụng biểu tượng quyết định để chỉ ra nơi các luồng lại hội tụ. Quyết định và các điều kiện bảo vệ cho phép bạn hiển thị các luồng thay thế trong quy trình làm việc của một trường hợp sử dụng.
* **Thanh đồng bộ** hiển thị các luồng con song song. Chúng cho phép bạn hiển thị các luồng đồng thời trong quy trình làm việc của một trường hợp sử dụng.
### 6. Bảng chú giải
- Bảng chú giải là một phần của tài liệu đặc tả ca sử dụng, dùng để lưu trữ các thuật ngữ quan trọng xuất hiện trong dự án.
- Mục đích:
- Để định nghĩa rõ ràng và thống nhất các thuật ngữ.
- Tránh nhầm lẫn và sự hiểu sai giữa các bên liên quan.
- Lợi ích:
- Cải thiện chất lượng và tính nhất quán của các ca sử dụng:
- Giả sử trong dự án phát triển ứng dụng bán hàng trực tuyến của chúng ta, có hai nhóm phân tích viên đang làm việc song song.
- Nhóm A sử dụng thuật ngữ “Khách hàng” để chỉ người mua hàng, trong khi nhóm B sử dụng thuật ngữ “Người dùng”. Điều này có thể gây ra nhầm lẫn và hiểu lầm.
- Tuy nhiên, nếu chúng ta có một glossary rõ ràng, tất cả mọi người đều sẽ sử dụng cùng một thuật ngữ, giúp cải thiện chất lượng và tính nhất quán của các ca sử dụng.
- Tăng hiệu quả và tiết kiệm thời gian trong quá trình phân tích và thiết kế:
- Giả sử chúng ta có một thuật ngữ “Giỏ hàng”, được định nghĩa là “Một danh sách các sản phẩm mà khách hàng muốn mua”.
- Mỗi khi chúng ta cần giải thích thuật ngữ này trong một ca sử dụng, chúng ta chỉ cần tham chiếu đến glossary thay vì phải giải thích lại từ đầu.
- Điều này giúp tăng hiệu quả và tiết kiệm thời gian trong quá trình phân tích và thiết kế.
- Dễ dàng cập nhật và bảo trì các ca sử dụng
- Giả sử sau một thời gian phát triển dự án, chúng ta quyết định thay đổi định nghĩa của “Giỏ hàng” thành “Một danh sách các sản phẩm mà khách hàng muốn mua và đã thêm vào giỏ hàng của họ”.
- Thay vì phải cập nhật định nghĩa này trong từng ca sử dụng, chúng ta chỉ cần cập nhật nó trong glossary.
- Tất cả các ca sử dụng sau đó sẽ tham chiếu đến định nghĩa mới từ glossary.
- Giúp tăng khả năng tái sử dụng và tái cấu trúc các ca sử dụng:
- Khi chúng ta cần chuyển đổi từ ca sử dụng sang các tài liệu khác như yêu cầu chức năng, biểu đồ hoạt động, biểu đồ tuần tự, v.v., chúng ta có thể sử dụng glossary như một công cụ để đảm bảo rằng tất cả các thuật ngữ đều được sử dụng một cách nhất quán và chính xác trong tất cả các tài liệu.
- Case Study: Glossary
### 7. Đặc tả bổ sung
- Các yêu cầu phi chức năng và yêu cầu chức năng không được thu thập bởi các ca sử dụng được bao gồm trong Các đặc tả Bổ sung. Các đặc tả Bổ sung bao gồm các ràng buộc về việc triển khai.
- Functionality (Chức năng): Danh sách các yêu cầu chức năng chung đối với nhiều ca sử dụng
- Yêu cầu: Hệ thống phải cho phép người dùng tạo mới, chỉnh sửa và xóa bài đăng trên trang web.
- Ví dụ: Người dùng phải có thể thêm một bài đăng mới bằng cách điền vào một biểu mẫu với các trường thông tin như tiêu đề, nội dung, và hình ảnh kèm theo.
- Usability (Khả năng sử dụng): Các yêu cầu liên quan đến hoặc ảnh hưởng đến khả năng sử dụng của hệ thống.
- Ví dụ bao gồm các yêu cầu về dễ sử dụng hoặc yêu cầu đào tạo xác định cách hệ thống có thể được sử dụng dễ dàng bởi các tác nhân của nó.
- Yêu cầu: Hệ thống phải có giao diện người dùng thân thiện và dễ sử dụng.
- Ví dụ: Hệ thống phải cung cấp các nút điều hướng rõ ràng và hướng dẫn sử dụng rõ ràng để người dùng có thể dễ dàng tìm và sử dụng các tính năng.
- Reliability (Độ tin cậy): Bất kỳ yêu cầu nào liên quan đến độ tin cậy của hệ thống. Các chỉ số định lượng như thời gian trung bình giữa các lỗi hoặc số lỗi mỗi nghìn dòng mã nên được nêu ra.
- Yêu cầu: Hệ thống phải hoạt động ổn định và không gặp sự cố quá thường xuyên.
- Ví dụ: Thời gian trung bình giữa các lỗi phải lớn hơn 30 ngày và số lỗi mỗi nghìn dòng mã phải ít hơn 5.
- Performance (Hiệu suất): Khả năng của hệ thống để thực hiện các nhiệm vụ trong khoảng thời gian và điều kiện nhất định.
- Bao gồm thời gian phản hồi cụ thể. Tham chiếu đến các trường hợp sử dụng liên quan bằng tên.
- Yêu cầu: Hệ thống phải có thời gian phản hồi dưới 2 giây khi người dùng yêu cầu thông tin.
- Ví dụ: Khi người dùng tìm kiếm sản phẩm trên trang web, hệ thống phải trả về kết quả trong vòng 2 giây.
- Supportability (Khả năng hỗ trợ): Sự dễ dàng trong việc duy trì, hỗ trợ và cập nhật hệ thống.
- Yêu cầu: Hệ thống phải có tài liệu hướng dẫn và hỗ trợ kỹ thuật dễ tiếp cận cho người quản trị và người dùng cuối.
- Ví dụ: Hệ thống phải cung cấp một trang Wiki nội bộ để chứa tài liệu hướng dẫn và các câu hỏi thường gặp để người dùng có thể tra cứu.
- Design constraints (Ràng buộc thiết kế): Các giới hạn và điều kiện mà quy định thiết kế của hệ thống.
- Chúng được xem xét ban đầu trong giai đoạn Bắt đầu như một phần bổ sung để xác định phạm vi của hệ thống.
- Chúng được tinh chỉnh theo cách tiến triển dần dần trong các giai đoạn Phát triển và Xây dựng.
- Yêu cầu: Hệ thống phải được xây dựng bằng ngôn ngữ lập trình Java và sử dụng cơ sở dữ liệu MySQL.
- Ví dụ: Hệ thống không được phát triển trên nền tảng Windows XP và phải tuân thủ các nguyên tắc thiết kế SOLID.
- An Ninh (Security): Mô tả các biện pháp an ninh được yêu cầu để bảo vệ thông tin và chức năng của hệ thống.
- Yêu cầu: Hệ thống phải cung cấp cơ chế xác thực đáng tin cậy để đảm bảo rằng chỉ người dùng được ủy quyền mới có thể truy cập vào các tính năng quản lý và dữ liệu nhạy cảm.
- Ví dụ: Hệ thống phải yêu cầu người dùng đăng nhập bằng tên người dùng và mật khẩu hợp lệ trước khi cho phép truy cập vào thông tin hồ sơ cá nhân hoặc thực hiện các thay đổi đối với dữ liệu cần được bảo mật. Hệ thống cũng phải mã hóa mật khẩu để đảm bảo an toàn trong truyền thông và lưu trữ.
### 8. Checkpoints
- Yêu cầu về mô hình ca sử dụng:
- Mô hình ca sử dụng có dễ hiểu không?
- Bằng cách nghiên cứu mô hình ca sử dụng, liệu bạn có thể nghĩ ra một ý tưởng rõ ràng về các chức năng của hệ thống và các chúng liên quan đến nhau không?
- Tất cả các yêu cầu chức năng đã được đáp ứng chưa?
- Mô hình ca sử dụng có chứa hành vi nào dư thừa không?
- Việc chia mô hình thành những gói ca sử dụng có phù hợp không?
- Những điều trên, cũng như các danh sách kiểm tra còn lại trong phần này, chỉ là một mẫu của những điều cần xem xét khi đánh giá Mô hình Ca Sử dụng. Cần thiết phải thiết lập các danh sách kiểm tra rõ ràng, chi tiết để hỗ trợ việc đánh giá Mô hình Ca Sử dụng.
- Xác minh rằng không có câu hỏi nào còn mở. Các ca sử dụng bạn đã tìm thấy phải có thể thực hiện tất cả các hành vi của hệ thống; nếu không, có một số ca sử dụng bị thiếu. Nếu bạn đã để lại bất kỳ yêu cầu nào để xử lý trong các mô hình đối tượng, chẳng hạn như yêu cầu phi chức năng, bạn phải đề cập đến điều này. Đặt tham chiếu trong Các Đặc tả Bổ sung trừ khi yêu cầu liên quan đến một ca sử dụng cụ thể, trong trường hợp đó chỉ ra ở phần Yêu cầu Đặc biệt của ca sử dụng.
- Mô hình ca Sử dụng không nên đưa ra nhiều chức năng hơn so với những gì đã được yêu cầu.
- Sự theo dõi nguồn gốc từ các yêu cầu ban đầu đến các ca sử dụng và Các Đặc tả Bổ sung là rất quan trọng để quản lý dự án và đánh giá ảnh hưởng cũng như để đảm bảo rằng không có gì bị bỏ sót.
- Cách đóng gói phải làm cho Mô hình ca Sử dụng trở nên đơn giản và dễ hiểu để duy trì.
- Yêu cầu về các tác nhân:
- Tất cả các tác nhân đã được xác định đầy đủ?
- Mỗi tác nhân có liên quan đến ít nhất một ca sử dụng hay không?
- Mỗi tác nhân chỉ có một vai trò hay không? Có hợp nhất hoặc chia nhỏ chúng ra không?
- Có hai tác nhân nào có cùng vai trò trong một ca sử dụng hay không?
- Các tác nhân có tên sáng tạo và mô tả hay chưa? Liệu cả người dùng và khách hàng có thể hiểu được không?
- 
- Yêu cầu về ca sử dụng:
- Liệu mỗi ca sử dụng có liên quan đến ít nhất một tác nhân?
- Các ca sử dụng có độc lập nhau hay không?
- Có ca sử dụng nào giống hành vi hoặc luồng sự kiện không?
- Các ca sử dụng có tên độc đáo, sáng tạo và giải thích để tránh nhầm lẫn ở giai đoạn sau không?
- Cả khách hàng và người dùng có thể hiểu rõ các tên và mô tả của các ca sử dụng không?
- 
- Yêu cầu về Đặc tả ca sử dụng:
* Có rõ ràng ai muốn thực hiện một ca sử dụng không?
* Mục đích của ca sử dụng có rõ ràng không?
* Mô tả ngắn gọn có cung cấp một bức tranh chân thực về ca sử dụng không?
* Rõ ràng về cách và khi nào luồng sự kiện của ca sử dụng bắt đầu và kết thúc không?
* Thứ tự giao tiếp giữa tác nhân và ca sử dụng có tuân theo mong đợi của người dùng không?
* Các tương tác và thông tin trao đổi giữa tác nhân và ca sử dụng có rõ ràng không?
* Có bất kỳ ca sử dụng nào quá phức tạp không?
* 
- Yêu cầu về bảng chú giải:
- Mỗi thuật ngữ có định nghĩa rõ ràng và ngắn gọn không?
- Mỗi thuật ngữ trong bảng chú giải có được bao gồm ở đâu đó trong phần mô tả ca sử dụng không?
- Các thuật ngữ được sử dụng một cách nhất quán trong các mô tả ngắn gọn của các tác nhân và các ca sử dụng không?
- 
## Bài 4: Tổng quan về phân tích và thiết kế
### 1. Mục tiêu bài học
- Nhắc lại các khái niệm và thuật ngữ chính về Phân tích và Thiết kế
- Giới thiệu quy trình Phân tích và Thiết kế, bao gồm vai trò, tài liệu và quy trình làm việc
- Giải thích sự khác nhau giữa Phân tích và Thiết kế
### 2. Mục đích
- Mục đích của Phân tích và Thiết kế là:
- Chuyển đổi các yêu cầu thành một thiết kế của hệ thống.
- Trong giai đoạn phân tích, các nhà phân tích hệ thống thu thập và phân tích yêu cầu của khách hàng hoặc người dùng. Sau đó, trong giai đoạn thiết kế, họ sẽ chuyển đổi các yêu cầu này thành một thiết kế chi tiết cho hệ thống.
- Phát triển một kiến trúc mạnh mẽ cho hệ thống.
- Mạnh mẽ: Khả năng chịu đựng những nhiễu loạn có thể ảnh hướng đến cơ quan chức năng của hệ thống
- Tính mạnh mẽ của kiến trúc thường được đánh giá dựa trên một số tiêu chí như tính linh hoạt, khả năng mở rộng, hiệu suất, bảo mật và khả năng bảo trì.
- Điều chỉnh thiết kế để phù hợp với môi trường implementation, thiết kế hệ thống một cách tối ưu.
- Khi thiết kế hệ thống, cần xem xét các yếu tố môi trường triển khai như nền tảng phần cứng, hệ thống vận hành, môi trường mạng và các yêu cầu về hiệu suất. Thiết kế phải được tinh chỉnh sao cho phù hợp với các yếu tố này và đảm bảo hiệu suất cao nhất.
- Ví dụ: Khi phát triển một phần mềm Chat Online, ta có thể xem xét các yếu tố sau:
- **Nền tảng phần cứng:** Phần mềm cần được triển khai trên các máy chủ mạnh mẽ để xử lý số lượng lớn người dùng đồng thời và dữ liệu trò chuyện. Ví dụ, nó có thể được triển khai trên các máy chủ đám mây có khả năng mở rộng.
- **Hệ thống vận hành:** Phần mềm cần tương thích với các hệ điều hành phổ biến như Windows, MacOS và Linux để có thể cài đặt và chạy trên nhiều nền tảng khác nhau.
- **Môi trường mạng:** Phải đảm bảo rằng phần mềm có thể hoạt động một cách mượt mà trên các kết nối Internet khác nhau, bao gồm cả kết nối chậm và không ổn định. Cần việc tối ưu hóa giao tiếp mạng và xử lý các tình huống kết nối yếu.
- **Yêu cầu về hiệu suất:** Phần mềm cần được tối ưu hóa để đảm bảo rằng nó có thể xử lý nhiều cuộc trò chuyện đồng thời mà vẫn duy trì được hiệu suất cao.
### 3. Tổng quan:
- 
- Các artifact đầu vào bao gồm Mô hình Use-Case, Bảng chú giải và Đặc tả bổ sung từ Khuôn mẫu Yêu cầu.
- Kết quả của Phân tích và Thiết kế là một Mô hình Thiết kế.
- Mô hình Thiết kế là một biểu đồ hoặc tài liệu mô tả cách hệ thống phần mềm sẽ được cấu trúc và tổ chức.
- Nó là một trừu tượng của mã nguồn, nghĩa là nó không phải là mã nguồn thực sự, nhưng là một phản ánh của cách mã nguồn có thể được tổ chức.
- Mô hình Thiết kế bao gồm các lớp thiết kế được cấu trúc thành các gói thiết kế; nó cũng chứa các mô tả về cách các đối tượng của các lớp thiết kế này hợp tác để thực hiện các ca sử dụng.
- Tài liệu Kiến trúc (Architecture Document) là một tài liệu chứa thông tin chi tiết về kiến trúc của hệ thống phần mềm. Tài liệu này cung cấp một cái nhìn tổng quan về cách các thành phần của hệ thống tương tác với nhau và làm thế nào chúng được cấu trúc để đáp ứng các yêu cầu chức năng và phi chức năng của hệ thống. Gồm có:
- Data flow: tài liệu diagram về các use case và data flow
- Database: tài liệu thiết kế database
- API: tài liệu về API
- Mô hình thiết kế
- Trong kỹ thuật phần mềm, “Design Model” (hay mô hình thiết kế) là một hình ảnh hoặc các hình ảnh dựa trên đối tượng mô tả các trường hợp sử dụng cho một hệ thống. Nói cách khác, đây là phương tiện để mô tả cách triển khai và mã nguồn của một hệ thống theo cách biểu đồ.
- Thiết kế dữ liệu: Đại diện cho các đối tượng dữ liệu và mối quan hệ giữa chúng trong một sơ đồ quan hệ thực thể.
- Thiết kế kiến trúc: Xác định mối quan hệ giữa các yếu tố cấu trúc chính của phần mềm.
- Thiết kế giao diện: Đại diện cho cách phần mềm giao tiếp với người dùng.
- Thiết kế cấp thành phần: Chuyển đổi các yếu tố cấu trúc của kiến trúc phần mềm thành mô tả thủ tục của các thành phần phần mềm.
- Mô hình dữ liệu
- Mô hình hóa dữ liệu là quá trình tạo sơ đồ trực quan đơn giản hóa của hệ thống phần mềm và các thành phần dữ liệu trong đó, sử dụng văn bản và ký hiệu để thể hiện dữ liệu và cách dữ liệu diễn ra. Mô hình dữ liệu cung cấp kế hoạch chi tiết cho các doanh nghiệp trong việc thiết kế cơ sở dữ liệu mới hoặc tái cấu trúc một ứng dụng cũ .
### 4. Các khái niệm chính
- Phân tích vs Thiết kế:
| Phân tích | Thiết kế |
| ----------------------------- | ------------------------------------ |
| Tập trung và việc hiểu vấn đế | Tập trung vào việc hiểu giải pháp |
| Lên ý tưởng vận hành | Chỉ ra cách vận hành, các thuộc tính |
| Hành vi | Hiệu suất |
| Cấu trúc hệ thống | Gần với mã nguồn |
| Các yêu cầu chức năng | Vòng đời đối tượng |
| Tạo ra mô hình nhỏ | Các yêu cầu phi chức năng |
| | Tạo ra mô hình lớn |
- Phân tích:
* Tập trung vào việc hiểu vấn đề: Trong giai đoạn này, nhóm phân tích tập trung vào việc nắm bắt và hiểu rõ yêu cầu của khách hàng và người dùng cuối.
* Trong dự án xây dựng một ứng dụng đặt bàn ăn trực tuyến, nhóm phân tích tập trung vào việc hiểu rõ nhu cầu của khách hàng, bao gồm việc đặt bàn, thay đổi đặt bàn và hủy đặt bàn.
* Lên ý tưởng vận hành: Phân tích sẽ tạo ra các khái niệm và ý tưởng về cách hệ thống sẽ hoạt động.
* Họ tạo ra một mô hình use-case để minh họa cách mà người dùng sẽ tương tác với hệ thống, bao gồm các use-case như "Đặt bàn", "Thay đổi đặt bàn" và "Hủy đặt bàn".
* Hành vi: Đưa ra mô tả về hành vi của hệ thống, bao gồm các ca sử dụng và luồng làm việc.
* Mô tả cụ thể luồng làm việc cho mỗi use-case, chẳng hạn như luồng làm việc khi một người dùng muốn thay đổi đặt bàn của họ.
* Cấu trúc hệ thống: Xác định cấu trúc tổng thể của hệ thống.
* Xác định cấu trúc tổng thể của hệ thống, bao gồm các thành phần chính như trang web, cơ sở dữ liệu và máy chủ.
* Các yêu cầu chức năng: Tập trung vào việc xác định các chức năng cần thiết cho hệ thống.
* Xác định các chức năng cụ thể mà hệ thống cần phải hỗ trợ, như đặt bàn, xác nhận đặt bàn và quản lý thực đơn.
* Tạo ra mô hình nhỏ: Phân tích sẽ tạo ra các mô hình nhỏ hơn, như mô hình use-case, để mô tả cụ thể hơn về các yêu cầu và hành vi của hệ thống.
* Tạo ra các biểu đồ use-case và biểu đồ luồng dữ liệu để mô tả chi tiết hơn về các yêu cầu và hành vi của hệ thống.
- Thiết kế:
* Tập trung vào việc hiểu giải pháp: Thiết kế tập trung vào việc tìm ra cách triển khai giải pháp cho các yêu cầu đã được phân tích.
* Thiết kế tập trung vào việc xác định cách triển khai các chức năng đã được xác định trong giai đoạn phân tích. Ví dụ, trong thiết kế, nhóm sẽ quyết định sử dụng một cơ sở dữ liệu quan hệ như MySQL để lưu trữ thông tin đặt bàn.
* Chỉ ra cách vận hành, các thuộc tính: Thiết kế sẽ chỉ ra cụ thể cách mà hệ thống sẽ hoạt động và các thuộc tính cần thiết của nó.
* Thiết kế sẽ xác định cách hệ thống sẽ hoạt động cụ thể, bao gồm cách mà người dùng sẽ tương tác với giao diện người dùng và cách dữ liệu sẽ được lưu trữ và truy xuất từ cơ sở dữ liệu.
* Hiệu suất: Tối ưu hóa hiệu suất của hệ thống là một mục tiêu quan trọng trong thiết kế.
* Tối ưu hóa hiệu suất của hệ thống bằng cách thiết kế các thuật toán hiệu quả và sử dụng các công nghệ phù hợp để xử lý tải.
* Gần với mã nguồn: Thiết kế sẽ gần gũi với mã nguồn, xác định các lớp, phương thức và cấu trúc dữ liệu cụ thể.
* Xác định cụ thể các lớp, phương thức và cấu trúc dữ liệu trong mã nguồn của hệ thống, cũng như các mối quan hệ giữa chúng.
* Vòng đời đối tượng: Xác định các vòng đời và quản lý vòng đời của các đối tượng trong hệ thống.
* Xác định các đối tượng trong hệ thống, bao gồm các phương thức và thuộc tính của chúng, cũng như các tương tác giữa các đối tượng.
* Các yêu cầu phi chức năng: Tập trung vào các yêu cầu không liên quan đến chức năng như bảo mật, sẵn sàng và hiệu suất.
* Thiết kế cũng sẽ xác định và triển khai các yêu cầu phi chức năng như bảo mật và sẵn sàng của hệ thống.
* Tạo ra mô hình lớn: Thiết kế sẽ tạo ra một mô hình lớn hơn, chứa các lớp và thành phần phần mềm chi tiết hơn.
* Tạo ra một mô hình lớn hơn và chi tiết hơn, bao gồm tất cả các thành phần và tương tác của hệ thống.
- Mục tiêu trong Phân tích là hiểu vấn đề và bắt đầu phát triển một mô hình hình ảnh về cái ta đang cố gắng xây dựng với các vấn đề về triển khai và công nghệ. Phân tích tập trung vào việc chuyển các yêu cầu chức năng thành các khái niệm phần mềm. Ý tưởng là để có được một phiên bản sơ bộ về các đối tượng tạo nên hệ thống của chúng ta, nhưng tập trung vào hành vi.
- Một mục tiêu của Thiết kế là tinh chỉnh mô hình với ý định phát triển một Mô hình Thiết kế sẽ cho phép một chuyển đổi mạch lạc sang giai đoạn lập trình. Trong thiết kế, chúng ta điều chỉnh cho phù hợp với môi trường triển khai.
- Phân tích và Thiết kế không phải là phương pháp từ trên xuống hoặc từ dưới lên.
- 
- Các lớp phân tích không được định nghĩa theo một mô hình từ trên xuống hoặc từ dưới lên; chúng ở ở mức trung gian. Từ mức trung gian này, bạn có thể di chuyển lên hoặc xuống.
- Định nghĩa các hệ thống con là di chuyển lên và định nghĩa các lớp thiết kế là di chuyển xuống.
- 
- 
- Kiến trúc:
- Kiến trúc phần mềm bao gồm một tập hợp các giải pháp quan trọng về tổ chức hệ thống phần mềm
- Lựa chọn các thành phần cấu trúc và giao diện của chúng để tạo nên hệ thống.
- Mô tả các hành vi bằng sự tương tác giữa các thành phần trong hệ thống.
- Gộp các thành phần cấu trúc và hành vi tạo thành một hệ thống con lớn hơn.
- Mẫu kiến trúc hướng dẫn tổ chức hệ thống.
- Kiến trúc tạo ra các ràng buộc về thiết kế và triển khai
- Kiến trúc bao gồm một tập hợp các phương pháp, quy tắc hoặc mô hình ràng buộc thiết kế và xây dựng
- Kiến trúc có thể được coi như một tập hợp các quyết định thiết kế chính.
- Nhiệm vụ của một kiến trúc sư là loại bỏ sự sáng tạo không cần thiết. Khi bạn di chuyển gần hơn đến mã nguồn, sự sáng tạo bị loại bỏ.
- Kiến trúc phần mềm: Mô hình "4 + 1" góc nhìn
- 
- Kiến trúc có nhiều ý nghĩa đối với nhiều bên liên quan khác nhau. Trên một dự án cụ thể, thường có nhiều bên liên quan, mỗi bên với các quan tâm và quan điểm riêng về hệ thống cần phát triển. Mục tiêu là cung cấp cho mỗi bên liên quan một cái nhìn về hệ thống giải quyết các quan tâm của họ và lược bỏ các chi tiết khác.
* Logical View (Góc nhìn Logic):
* Tập trung vào cách hệ thống được tổ chức logic và cấu trúc của các thành phần bên trong.
* Bao gồm các lớp, giao tiếp, cấu trúc dữ liệu, và các phương pháp logic mà hệ thống sử dụng để thực hiện các chức năng.
* Góc nhìn Logic giúp nhìn vào cấu trúc logic của hệ thống mà không quan tâm đến các chi tiết về cách hệ thống sẽ triển khai.
* Deployment View (Góc nhìn Triển khai):
* Tập trung vào cách hệ thống được triển khai và phát triển trong môi trường phần cứng và mạng lưới.
* Bao gồm các thành phần phần cứng, máy chủ, máy trạm, và các mạng lưới mà hệ thống sẽ sử dụng.
* Góc nhìn Triển khai giúp hiểu cách hệ thống được triển khai vật lý và cách các thành phần của nó được phân bố trên các nền tảng phần cứng.
* Implementation View (Góc nhìn Triển khai):
* Tập trung vào các khía cạnh triển khai của hệ thống, bao gồm mã nguồn, module, và các công nghệ triển khai.
* Bao gồm các thành phần phần mềm cụ thể và cách chúng được triển khai và sử dụng trong hệ thống.
* Góc nhìn Triển khai giúp hiểu cách hệ thống được triển khai về mặt mã nguồn và cấu trúc phần mềm.
* Process View (Góc nhìn Tiến trình):
* Tập trung vào các tiến trình và luồng điều khiển của hệ thống khi nó đang chạy.
* Bao gồm các tiến trình, luồng điều khiển, và các tương tác giữa các thành phần của hệ thống trong quá trình chạy.
* Góc nhìn Tiến trình giúp hiểu cách các thành phần của hệ thống hoạt động cùng nhau để thực hiện các chức năng cụ thể.
* Use-case View (Góc nhìn Kịch bản):
* Tập trung vào các tình huống sử dụng và các yêu cầu chức năng của hệ thống từ góc độ của người dùng.
* Bao gồm các kịch bản hoạt động và các tương tác giữa người dùng và hệ thống.
* Góc nhìn Kịch bản giúp hiểu cách người dùng sẽ tương tác với hệ thống và cách hệ thống sẽ đáp ứng lại các tương tác đó.
### 5. Quy trình Phân tích và Thiết kế
- 
- Giai đoạn Elaboration sớm tập trung vào việc tạo ra một kiến trúc ban đầu cho hệ thống (Xác định kiến trúc dự kiến) để cung cấp một điểm khởi đầu cho công việc phân tích chính. Nếu kiến trúc đã tồn tại (vì nó đã được tạo ra trong các vòng lặp trước đó, hoặc các dự án trước, hoặc được lấy từ một framework ứng dụng), trọng tâm của công việc sẽ chuyển sang việc **tinh chỉnh kiến trúc**, **phân tích hành vi**, và tạo ra một tập hợp ban đầu các yếu tố cung cấp hành vi phù hợp .
- Sau khi các yếu tố ban đầu được xác định, chúng được tinh chỉnh thêm. **Thiết kế Các thành phần** và **Thiết kế Các thành phần Thời gian thực** tạo ra một tập hợp các thành phần cung cấp hành vi phù hợp để đáp ứng các yêu cầu trên hệ thống. Đồng thời với các hoạt động này, các vấn đề về sự tồn tại được xử lý trong Thiết kế Cơ sở dữ liệu. Kết quả là một tập hợp ban đầu các thành phần được tinh chỉnh thêm trong quy trình triển khai.
- Perform Architectural Synthesis:
- Chi tiết quy trình công việc này nhằm mục đích chỉ ra rằng tồn tại hoặc có khả năng tồn tại một giải pháp sẽ đáp ứng các yêu cầu quan trọng về mặt kiến trúc, từ đó cho thấy rằng hệ thống, như đã hình dung, là khả thi.
- Công việc này diễn ra trong quá trình khởi đầu và do đó nên được giới hạn ở một hoặc hai lần lặp lại. Mục đích là để xác định tính khả thi chứ không phải để xây dựng hệ thống trong quá trình chi tiết quy trình làm việc này.
- Define a Candidate Architecture:
- * 
- Quy trình làm việc này có các mục tiêu sau:
* Tạo ra một bản vẽ sơ bộ về kiến trúc của hệ thống.
* Xác định một tập hợp ban đầu các yếu tố quan trọng về mặt kiến trúc để sử dụng làm cơ sở cho phân tích.
* Xác định một tập hợp ban đầu các cơ chế phân tích: Điều này có thể bao gồm các phương pháp như phân tích lớp, phân tích giao diện, hoặc phân tích luồng dữ liệu.
* Xác định cấu trúc lớp ban đầu và tổ chức của hệ thống: Điều này bao gồm việc quyết định cách các thành phần của hệ thống được tổ chức và tương tác với nhau.
* Xác định các ca sử dụng cụ thể cần được giải quyết trong vòng lặp hiện tại.
* Xác định các lớp phân tích từ các ca sử dụng quan trọng về mặt kiến trúc: Các lớp phân tích là các lớp được sử dụng để phân tích các yêu cầu và chức năng của hệ thống từ một góc độ kiến trúc.Một lớp phân tích có thể có các thuộc tính sau:
* tên: tên của lớp
* mô tả: mô tả ngắn gọn về vai trò của lớp trong hệ thống
* trách nhiệm: danh sách các trách nhiệm của lớp
* thuộc tính: các thuộc tính của lớp
* 
* Cập nhật các ca sử dụng với các tương tác lớp phân tích.
* Analyze Behavior:
* 
* Refine the Architecture:
* 
* Design Components:
* 
* Design the Database:
* 
* 
- Tổng quan hoạt động phân tích, thiết kế:
- 
- Các hoạt động thiết kế tập trung vào khái niệm về kiến trúc. Việc sản xuất và xác nhận kiến trúc này là trọng tâm chính của các vòng lặp thiết kế sớm. Kiến trúc là một phương tiện quan trọng không chỉ để phát triển một Mô hình Thiết kế tốt, mà còn để tăng cường chất lượng của bất kỳ mô hình nào được xây dựng trong quá trình phát triển hệ thống.
- Trách nhiệm của Kiến trúc sư phần mềm:
- Kiến trúc sư phần mềm lãnh đạo và điều phối các hoạt động kỹ thuật và artifact.
* Định nghĩa kiến trúc của phần mềm, các thành phần chính của nó, và các tương tác với hệ thống nội bộ và hệ thống bên ngoài.
* Cung cấp một tầm nhìn kiến trúc cho một tổ chức để thiết lập sự hòa hợp giữa các bên liên quan.
* Tương tác với quản lý sản phẩm, nhà phát triển, khách hàng và các bên liên quan khác để tưởng tượng, thiết kế và phát triển sản phẩm.
* Xem xét mã nguồn thường xuyên để đảm bảo chất lượng của sản phẩm cuối cùng và giúp các nhóm tránh sự phức tạp.
* Làm việc như một người đóng góp và người hướng dẫn cho đội ngũ phát triển phần mềm để xây dựng giải pháp đúng đắn với phương pháp tốt nhất.
* Yêu cầu:
* Kinh nghiệm cả trong lĩnh vực vấn đề, thông qua hiểu biết sâu rộng về yêu cầu, và trong lĩnh vực kỹ thuật phần mềm.
* Lãnh đạo để thúc đẩy nỗ lực kỹ thuật qua các nhóm khác nhau, và đưa ra các quyết định quan trọng dưới áp lực và đưa ra các quyết định đó
* Giao tiếp để đạt được sự tin tưởng, thuyết phục, động viên, và hướng dẫn.
* Hướng mục tiêu và tích cực với tập trung không ngừng vào kết quả. Kiến trúc phần mềm là động lực kỹ thuật đằng sau dự án, không phải là một nhà tầm nhìn hoặc người mơ mộng.
- 
- Trách nhiệm của Người thiết kế:
- Người thiết kế phải biết các kỹ thuật mô hình hóa ca sử dụng, yêu cầu hệ thống và kỹ thuật thiết kế phần mềm,
- Vai trò của người thiết kế xác định các trách nhiệm, hoạt động, thuộc tính và mối quan hệ của một hoặc nhiều lớp, và xác định cách chúng được điều chỉnh cho môi trường triển khai. Ngoài ra, vai trò của người thiết kế có thể có trách nhiệm đối với một hoặc nhiều gói thiết kế, hoặc các hệ thống thiết kế, bao gồm bất kỳ lớp nào thuộc quyền sở hữu của các gói hoặc hệ thống đó.
* Người thiết kế phải có kiến thức làm việc vững chắc về:
* Các kỹ thuật mô hình hóa use-case
* Yêu cầu hệ thống
* Các kỹ thuật thiết kế phần mềm, bao gồm các kỹ thuật Phân tích và Thiết kế hướng đối tượng, và Ngôn ngữ Mô hình hóa Thống nhất (UML)
* Các công nghệ mà hệ thống sẽ triển khai
* Ngoài ra, người thiết kế phải:
* Hiểu về kiến trúc của hệ thống, như được đại diện trong Tài liệu Kiến trúc Phần mềm.
- 
- Phân tích thiết kế phải dựa trên ca sử dụng
- Các ca sử dụng của một hệ thống là cơ sở cho toàn bộ quá trình phát triển
- Lợi ích của ca sử dụng:
- Ngắn gọn, đơn giản và dễ hiểu đối với nhiều bên liên quan
- Giúp đồng bộ nội dung của các mô hình khác nhau.
- Thay vì một danh sách các yêu cầu dưới dạng các mục đánh dấu, ta sẽ tổ chức chúng theo cách mô tả cách một người có thể sử dụng hệ thống. Bằng cách này, ta đã làm cho một yêu cầu trở nên đầy đủ và nhất quán hơn. Chúng ta cũng có thể hiểu rõ hơn về sự quan trọng của một yêu cầu từ quan điểm của người dùng.
- 
- Hiện thực hóa ca sử dụng:
- 
- Hiện thực hóa ca sử dụng mô tả cách một ca sử dụng cụ thể được thực hiện trong Mô hình Thiết kế, dưới dạng các đối tượng cộng tác với nhau. Hiện thực hóa ca sử dụng kết nối các ca sử dụng từ Mô hình Ca sử dụng với các lớp và mối quan hệ của Mô hình Thiết kế. Hiện thực hóa ca sử dụng chỉ định các lớp nào phải được xây dựng để thực hiện mỗi ca sử dụng.
- Việc thực hiện có thể có nhiều hình thức khác nhau. Ví dụ, nó có thể bao gồm một mô tả bằng văn bản (tài liệu), sơ đồ lớp của các lớp và hệ thống con tham gia và sơ đồ tương tác (sơ đồ giao tiếp và sơ đồ trình tự) minh họa luồng tương tác giữa các phiên bản lớp và hệ thống con.
- Sơ đồ trình tự hiển thị trình tự rõ ràng của các thông báo và sẽ tốt hơn khi điều quan trọng là phải trực quan hóa thứ tự thời gian của các thông báo.
- là biểu đồ tương tác mô tả chi tiết cách các hoạt động được thực hiện. Chúng nắm bắt sự tương tác giữa các đối tượng trong bối cảnh cộng tác. Biểu đồ trình tự tập trung vào thời gian và chúng hiển thị thứ tự của tương tác một cách trực quan bằng cách sử dụng trục dọc của biểu đồ để biểu thị thời gian những thông điệp nào được gửi và khi nào.
- Đường sống
- Thời gian hoạt động
- Thông điệp
- Loop
- Sơ đồ giao tiếp là một minh họa về các mối quan hệ và tương tác giữa các đối tượng phần mềm trong Ngôn ngữ Mô hình Thống nhất (UML).
- Đối tượng
- Liên kết
- Tin nhắn
- Trong UML, hiện thực hóa ca sử dụng có khuôn mẫu là cộng tác. Biểu tượng cho sự cộng tác là một dấu ba chấm chứa tên của cộng tác. Biểu tượng cho việc hiện thực hóa ca sử dụng là một phiên bản đường chấm của biểu tượng cộng tác.
- Việc hiện thức hóa ca sử dụng trong Mô hình Thiết kế có thể được truy vết đến một ca sử dụng trong Mô hình Ca sử dụng.
- Trong UML, việc hiện thức hóa ca sử dụng có thể được biểu diễn bằng một tập hợp các biểu đồ mô hình hóa ngữ cảnh của sự cộng tác (các lớp/đối tượng hiện thức hóa ca sử dụng và các mối quan hệ của chúng - biểu đồ lớp), và các tương tác của các sự cộng tác (cách các lớp/đối tượng này tương tác để hiện thực hóa các ca sử dụng - biểu đồ cộng tác và tuần tự).
- Số lượng và loại các biểu đồ được sử dụng phụ thuộc vào những gì cần thiết để cung cấp một bức tranh hoàn chỉnh về sự cộng tác và các hướng dẫn được phát triển cho dự án đang phát triển.
- Phân tích và thiết kế trong một vòng lặp
- 
- Trong quy trình Phân tích và Thiết kế, tại một vòng lặp, một ca sử dụng sẽ là một artifact chính. Bằng cách đi qua một loạt các hoạt động được xác định trong quy trình Phân tích và Thiết kế, nhóm phát triển sẽ tạo ra một hiện thực hóa ca sử dụng liên quan mô tả cách một ca sử dụng cụ thể sẽ được thực hiện.
## Bài 5: Phân tích kiến trúc
### 1. Mục tiêu bài học:
- Giải thích mục đích của Phân tích kiến trúc và nơi chúng được thực hiện trong vòng đời của dự án.
- Mô tả một mẫu kiến trúc tiêu biểu và tập hợp các cơ chế phân tích, và cách chúng ảnh hướng đến kiến trúc.
- Mô tả lý do và những cân nhắc hỗ trợ các quyết định kiến trúc.
- Hướng dẫn cách đọc và hiểu kết quả của Phân tích Kiến trúc:
- Các lớp kiến trúc và mối quan hệ của chúng
- Các trừu tượng chính
- Các cơ chế phân tích
### 2. Khung cảnh phân tích kiến trúc
- Phân tích kiến trúc là một hoạt động trong luồng công việc xác định và lựa chọn kiến trúc cho hệ thống của bức tranh tổng quát về phân tích thiết kế.
- Phân tích kiến trúc là cách đội dự án hay kiến trúc sư xác định kiến trúc mức cao của dự án. Nó tập trung chủ yếu vào việc định giới hạn cho công việc phân tích bằng cách sử dụng các mẫu (*patterns*) và các chỉ dẫn (*idioms*) để làm giảm tải cho hoạt động phân tích, tránh sa vào các giải pháp cụ thể sớm. Phân tích kiến trúc có thể xem như là việc định cấu hình cho phân tích ca sử dụng.
- Trong suốt quá trình phân tích kiến trúc, chúng ta tập trung vào các tầng mức cao của hệ thống, nhằm xác định sơ bộ các thành phần của hệ thống và quan hệ giữa chúng, tổ chức chúng theo các tầng và đặt trong các mối quan hệ giữa các tầng.
### 3. Tổng quan về phân tích kiến trúc
* Trong phân tích ca sử dụng, kiến trúc này sẽ được khai triển thông qua các lớp phân tích – những chế tác được xác định từ mô tả ca sử dụng. Tiếp đó, kiến trúc ban đầu này sẽ được làm mịn và chỉ tiết hóa cũng như các tầng mức thấp hơn được xác định bằng cách tích hợp dần các phần từ thiết kế. Việc làm mịn này được định hướng theo môi trường triển khai và các ràng buộc triển khai khác.
* Phân tích kiến trúc thường được thực hiện một lần từ giai đoạn đầu của pha chi tiết. Hoạt động này được tiến hành bởi các kiến trúc phần mềm viên hoặc đội kiến trúc. Trong trường hợp, rủi ro về kiến trúc là thấp thì hoạt động này có thể được bỏ qua.
* Mục đích:
* Xác định một kiến trúc tiêu biểu cho hệ thống dựa vào kinh nghiệm từ các hệ thống tương tự hay các miền vấn đề tương tự.
* Xác định các mẫu kiến trúc, các cơ chế kiến trúc chính và các quy ước về mô hình hệ thống.
* Xác định các chiến lược sử dụng lại.
* Cung cấp một phần đầu vào cho hoạt động lập kế hoạch dự án.
* Đầu vào:
* Mô hình ca sử dụng
* Các đặc tả bổ sung
* Bảng chú giải
* Mô hình thiết kế
* Các mô hình kiến trúc tham chiếu
* Các tài liệu tổng thể hệ thống
* Các tài liệu hướng dẫn chuyên cho dự án
* Các tài liệu kiến trúc hệ thống.
* Đầu ra:
* Các tài liệu kiến trúc hệ thống
* Mô hình thiết kế
* Mô hình triển khai.
### 4. Các khái niệm chính
#### a. Kiến trúc mô hình “khung nhìn 4+1":
- Là một phương pháp để tái hiện kiến trúc phần mềm.
- Mô hình này dùng để tổ chức, phản ánh hệ thống từ 4+1 khung nhìn khác nhau, trong đó, khung nhìn ca sử dụng định hướng và chi phối các khung nhìn còn lại.
- Trong phân tích kiến trúc, chúng ta sẽ tập trung vào khung nhìn logic. Các khung nhìn khác sẽ được giải quyết trong các khâu hoạt động sau.
- Cụ thể khung nhìn logic sẽ được làm mịn trong khâu xác định các cơ chế thiết kế và khâu xác định các mô đun thiết kế.
- Khung nhìn tiến trình sẽ được biểu diễn trong khâu mô tả kiến trúc thực thi.
- Khung nhìn triển khai sẽ được xây dựng trong khâu mô tả sự phân tán.
- Khung nhìn thực thi sẽ được phát triển trong khâu thực thi, và do đó sẽ nằm ngoài phạm vi của giáo trình phân tích và thiết kế này.
#### b. Gói và các mối quan hệ:
- Gói là một cơ chế tổng quát để tổ chức các phần tử vào trong các gói.
- Gói là một phần tử mô hình có thể chứa các phần tử khác.
- Gói được dùng để:
- Tổ chức mô hình trong quá trình phát triển.
- Là các đơn vị trong khâu hoạt động quản lý cấu hình của dự án.
- Quan hệ phụ thuộc giữa các gói:
- Các gói có thể liên hệ với các gói khác thông qua các mối quan hệ phụ thuộc.
- Các phần tử trong gói phụ thuộc có thể được đưa vào (import) các phần tử từ gói mà nó phụ thuộc vào.
- Những nội dung của gói Cung cấp (phía bị phụ thuộc) có thể được tham chiếu từ gói Khách.
- Các lớp trong gói Khách có thể truy cập các lớp trong gói Cung cấp
- Lưu ý:
- Bất kỳ sự thay đổi nào trong gói Cung cấp, gói Khách đều phải dịch lại và kiểm thử lại.
- Các gói Khách không được sử dụng lại một cách độc lập vì nó còn phụ thuộc vào gói Cung cấp.
- Tránh quan hệ phụ thuộc chu trình giữa các gói:
- Là một ràng buộc trong hệ thống phân cấp gói.
- Quan hệ phụ thuộc ở đây có tính chất bắc cầu: Gói A phụ thuộc gói B, gói B phụ thuộc gói C dẫn đến gói A phụ thuộc gói C.
- Trong trường hợp này không có chu trình nghĩa là không có quan hệ phụ thuộc từ gói C đến gói A.
- Tồn tại sự phụ thuộc chu trình sẽ ngăn cản việc sử dụng lại các gói một cách độc lập bởi vì các gói trong quan hệ phụ thuộc chu trình sẽ phải luôn đi cùng với nhau.
- Phụ thuộc chu trình có thể được loại bỏ bằng cách tách một trong các gói thành các gói nhỏ hơn.
### 5. Tổ chức mức cao cho các phân hệ
#### a. Lựa chọn mẫu thiết kế và framework
- Mẫu (pattern)
- Là phương thức để phát biểu mảng tri thức chuyên biệt nào đó được thu thập, tổng hợp từ kinh nghiệm.
- Nó cung cấp một giải pháp chung cho một vấn đề thường lặp lại trong khung cảnh nào đó.
- Các mẫu thường đưa ra các ví dụ về cách giải quyết vấn đề bằng giải pháp mô hình hóa tốt.
- Mẫu phân tích/thiết kế
- Cung cấp giải pháp cho một vấn đề kỹ thuật trong phạm vi hẹp
- Cung cấp một phần của giải pháp
- Mẫu được phát biểu trong không gian kỹ thuật hẹp như ở khâu phân tích hay thiết kế thì sẽ được gọi là mẫu phân tích hay mẫu thiết kế.
- Khung công việc (framework):
- Xác định cách tiếp cận chung để giải quyết vấn đề
- Mô tả một giải pháp phác thảo cho một vấn đề cụ thể nào đó.
- chính vấn đề này sẽ được giải quyết bằng cách chi tiết hóa giải pháp tương ứng đó.
- Khung công việc thường được chi tiết hóa bằng cách áp dụng các mẫu phân tích và thiết kế vào giải pháp phác thảo đó.
#### b. Mẫu thiết kế:
- Mẫu thiết kế là các mẫu đưa ra các giải pháp cho vấn đề thiết kế nào đó.
- Mẫu thiết kế thường chứa đựng ba nội dung chính sau.
- Phần nêu vấn đề thiết kế thường lặp lại. Theo đó khung cảnh cho việc áp dụng mẫu thiết kế được xác định.
- Trình bày giải pháp thiết kế.
- Phần thảo luận về kết quả, ràng buộc cho việc áp dụng mẫu thiết kế.
- Các mẫu thiết kế cung cấp khả năng tái sử dụng những thiết kế thành công.
#### c. Mẫu kiến trúc:
- Mẫu kiến trúc diễn đạt một lược đồ tổ chức cấu trúc cho hệ thống. Nó cung cấp một tập các hệ thống con, đặc tả trách nhiệm của chúng và đưa vào các luật và các chỉ dẫn cho việc tổ chức các mối quan hệ giữa chúng.
- Phân tích kiến trúc sẽ tập trung ở việc lựa chọn các mẫu kiến trúc, đưa ra tổ chức mức cao cho mô hình đối tượng của hệ thống.
- Sau đây là nội dung một số mẫu kiến trúc thông dụng.
* **Mẫu phân tầng (Layers)** sẽ phân chia hệ thống theo các cấp độ trừu tượng khác nhau. Các tầng này thay đổi từ các tầng mức trên cùng, chuyên biệt cho miền ứng dụng (application-specific layers) cho đến các tầng mức dưới cùng, hướng về môi trường thực thi và công nghệ cài đặt cụ thể.
* **Mẫu MVC (Mô hình/Khung nhìn/Điều khiển - Model/View/ Controller)** tổ chức hệ thống theo ba phân vùng: Vùng mô hình chứa đựng các dữ liệu dạng thực thể cùng với các luật nghiệp vụ. Vùng khung nhìn sẽ truyền tải và tiếp nhận thông tin từ phía người dùng. Và vùng điều khiển sẽ xử lý các yêu cầu người dùng gửi vào thông qua vùng khung nhìn.
* **Mẫu đường ống và bộ lọc (Pipes and filters)** sẽ tổ chức xử lý dữ liệu theo các dòng, và các dòng này sẽ được đẩy luồng thông qua các đường ống để xử lý tại các bộ lọc. Mỗi bộ lọc tương ứng với một bước xử lý.
* **Mẫu bảng đen (Blackboard)** sẽ đưa ra cách tổ chức mà ở đó các ứng dụng chuyên biệt độc lập sẽ cộng tác với nhau đưa ra giải pháp. Các ứng dụng đó làm việc trên một cấu trúc dữ liệu dùng chung.
#### d. Tiếp cận phân tầng
- Phân tầng là sự tái hiện các nhóm gộp chức năng theo trình tự: chúc năng chuyên cho ứng dụng cụ thể sẽ được đặt vào các tầng trên, chức năng chuyên cho miền ứng dụng sẽ ở các tầng giữa và chúc năng chuyên cho miền triển khai ở tầng thấp hơn.
- Sổ lượng và sự kết hợp giữa các tầng là phụ thuộc vào độ phức tạp của cả miền vấn đề và không gian giải pháp. Nhìn chung chỉ có duy nhất một tầng trên cùng **chuyên cho ứng dụng cụ thể (application-specific layer).**
- Các hệ thống con ứng dụng riêng biệt tạo thành một ứng dụng - chứa phần mềm gia tăng giá trị được phát triển bởi tổ chức.
- Đối các miền gồm nhiều hệ thống ứng dụng hoặc với các miền gồm các hệ thống lớn được hình thành từ nhiều hệ thống nhỏ hơn, chúng ta thường cần đến **tầng chuyên biệt nghiệp vụ (business-specific layer**) mà tầng này có thể được phân thành nhiều tầng để tăng tính dễ hiểu.
- chứa một số hệ thống con có thể tái sử dụng, đặc biệt cho loại hình kinh doanh.
- Khi không gian giải pháp được hỗ trợ rất tốt từ các sản phẩm **trung gian (middleware)** và trong đó các phần mềm hệ thống phức tạp đóng vai trò lớn hơn thì chúng ta thường cần đến các tầng mức thấp. Đó thường là các tầng chứa các phần mềm trung gian và phần mềm hệ thống. Tầng trung gian thường chứa các thành phần như các gói giao diện người dùng (GUI), gói giao diện truy xuất cơ sở dữ liệu và các dịch vụ hệ điều hành độc lập nền.
- cung cấp các hệ thống con cho các lớp tiện ích và dịch vụ độc lập với nền tảng cho tính toán đối tượng phân tán trong môi trường không đồng nhất và các nền tảng khác.
- Tầng dưới, **tầng phần mềm hệ thống**, thường chứa các thành phần như các hệ điều hành, hệ cơ sở dữ liệu, hay các giao diện truy cập thiết bị phần cứng.
- chứa phần mềm cho cơ sở hạ tầng thực sự như hệ điều hành, giao diện với phần cứng cụ thể, trình điều khiển thiết bị, và vân vân.
#### e. Mẫu kiến trúc phân tầng
* **Khung cảnh:** Một hệ thống lớn cần phải được tổ chức phân rã.
* **Vấn đề:** Hệ thống phải được xem xét với nhiều vấn đề khác nhau, ở các cấp độ trừu tượng khác nhau, chẳng hạn các vấn đề về điều khiển phần cứng, vấn đề về dịch vụ dùng chung hay các vấn đề về đặc thù của miền. Sẽ là rất phức tạp nếu xây dựng các thành phần theo chiều dọc liên quan đến tất cả các tầng để giải quyết các vấn đề đặt ra cho mỗi tầng. Hơn nữa, cùng một vấn đề nhiều khả năng sẽ được giải quyết nhiều lần ở các thành phần khác nhau theo một cách dễ không nhất quán.
* **Ràng buộc:**
* Các thành phần của hệ thống có thể được thay thế.
* Tầm ảnh hưởng do thay đổi trong các thành phần là được kiểm soát.
* Các trách nhiệm tương tự nên được nhóm gộp với nhau.
* Các thành phần phức tạp có thể được phân rã.
* **Giải pháp:** Cấu trúc hệ thống thành các nhóm thành phần theo các tầng. Đảm bảo rằng các tầng trên sử dụng các dịch vụ của chỉ các tầng dưới. Cố gắng chỉ sử dụng dịch vụ của tầng liền kề dưới, tránh sử dụng dịch vụ của các tầng khác. Dịch vụ có thể là dịch vụ điều khiển sự kiện, điều khiển lỗi hay dịch vụ truy cập cơ sở dữ liệu.
#### f. Lưu ý khi phân tầng:
* **Về cấp độ trừu tượng:**
* Các tầng được sử dụng để bao gói các phần tử có cùng cấp độ trừu tượng
* Cung cấp các trừu tượng hay các khái niệm cần thiết để giúp cho người thiết kế dễ hiểu hơn.
* **Phân tách các mối quan tâm (concerns**):
* Khi phân tầng chúng ta tập trung nhóm gộp các phần tử tương tự và liên quan về mặt logic với nhau để cục bộ hóa các thay đổi. Ngược lại những thứ không liên quan sẽ được phân tách và đóng gói riêng.
* Chúng ta cần tạo phân tách giữa các phần tử mô hình ứng dụng và mô hình miền.
* Nhìn chung chỉ có một tầng ứng dụng.
* Ngược lại, số lượng tầng miền phụ thuộc vào độ phức tạp của vấn đề và các không gian giải pháp
* **Tính thích ứng**:
* Một trong những tiêu chí cho việc phân tầng là tạo được liên kết lỏng lẻo giữa các thành phần.
* Nó cho phép cập nhật sửa đổi các thành phần dễ dàng và linh hoạt và ít ảnh hưởng đến các thành phần khác.
* Do đó, các thành phần dễ bị thay đổi trong vòng đời hệ thống như các thành phần giao diện người dùng hay các quy tắc nghiệp vụ thường được tổ chức đóng gói riêng.
#### g. Mô hình hóa kiến trúc phân tầng
- Chúng ta dùng ký pháp package gắn với stereotype `<<layer>>` để biểu diễn các tầng. Nội dung tầng sẽ được mô tả trong phần đặc tả gói.
- VD: Tổ chức ở Cấp Độ Cao của Mô Hình (trong slide nhé)
- Kiến trúc phân tầng cho hệ Course Registration.
- Tầng Application chứa các phần tử thiết kế chuyên biệt cho ứng dụng Course Registration. Chúng ta dự trù sẽ có nhiều ứng dụng chia sẻ một vài trừu tượng chính và các dịch vụ dùng chung.
- Do đó, chúng ta sẽ tách các nội dung chia sẻ đó và đưa vào tầng Business Service để dùng chung cho nhiều ứng dụng, không chỉ cho riêng hệ Course Registration.
### 6. Xác định các cơ chế phân tích
#### a. Cơ chế kiến trúc
* Một cơ chế kiến trúc là một quyết định chiến lược về các chuẩn chung, các chính sách và các thực thi.
* Nó là sự hiện thực hóa những vấn đề cần được chuẩn hóa trong một dự án.
* Mọi người trong dự án sẽ hiểu và sử dụng các khái niệm một cách thống nhất và sử dụng lại cùng một cơ chế để thực hiện các thao tác tương ứng.
* Cơ chế kiến trúc đưa ra một giải pháp chung cho một vấn đề thường lặp lại.
* Nó có thể là các mẫu về cấu trúc, các mẫu về hành vi hoặc là cả hai. Các cơ chế kiến trúc là một phần quan trọng cho việc kết dính các chức năng được yêu cầu của hệ thống với cách mà chúng được cải đặt trong các ràng buộc về môi trường thực thi.
* Giải pháp tương ứng với các cơ chế kiến trúc cần phải được tích hợp vào kiến trúc.
* Các cơ chế kiến trúc được điều phối bởi các kiến trúc viên.
* Kiến trúc viên sẽ lựa chọn các cơ chế, hợp lệ chúng bằng cách xây dựng và tích hợp, kiểm chứng và chuyển dịch chúng một cách nhất quán sang pha thiết kế.
#### b. Phân loại cơ chế kiến trúc
- Tùy vào từng cấp độ kiến trúc mà chúng ta có các loại cơ chế kiến trúc khác nhau. Tương ứng với cấp độ **khái niệm (conceptual), cụ thể (concrete)** và **cài đặt (actual)** sẽ là **cơ chế phân tích**, **cơ chế thiết kế** và **cơ chế thực thi.**
* **Cơ chế phân tích** nắm bắt các khía cạnh chính của giải pháp một cách độc lập với môi trường thực thi.
* Nó có thể cung cấp các hành vi chuyên biệt cho các lớp miền vấn đề hay các thành phần liên quan đến miền.
* Nó cũng có thể tham chiếu đến bản hiện thực hóa cộng tác giữa các đối tượng hay thành phần.
* Nó có thể được cải đặt như một khung công việc.
* Một số cơ chế phân tích thường gặp như tổ chức lưu trữ bền vững, giao tiếp liên tiến trình, điều khiển lỗi và thất bại, hay cơ chế truyền thông điệp.
* **Cơ chế thiết kế** là cụ thể hơn so với cơ chế phân tích.
* Loại cơ chế này được xác định với những giả định về môi trường thực thi, tuy nhiên, không gắn với môi trường thực thi cụ thể nào cả.
* Chẳng hạn, với cơ chế lưu trữ bền vững, chúng ta có thể giả định mô hình cơ sở dữ liệu là quan hệ hay hướng đối tượng và công nghệ cài đặt là Oracle hay SYBASE.
* **Cơ chế thực thi** đưa ra bản cài đặt chính xác gắn với từng môi trường thực thi cụ thể, chẳng hạn như công nghệ nền, ngôn ngữ cài đặt hay các phần mềm trung gian.
#### c. Tại sao lại cần cơ chế phân tích:
- 
- Xin lỗi các ông t lười quá
#### d. Một số ví dụ về cơ chế phân tích
- **Cơ chế lưu trữ bền vững:** giải quyết vấn đề về tổ chức bền vững.
- Tính chi tiết (Granularity) ????
- Dung lượng (Volume) ???
- Thời lượng
- Cơ chế truy cập
- Tần suất truy cập (tạo/ xóa, cập nhật, đọc)
- Độ tin cậy
- **Cơ chế giao tiếp liên tiến trình:** giải quyết vấn đề về tổ chức giao tiếp giữa các tiến trình.
* Độ trễ
* Đồng bộ
* Kích thước thông điệp
* Giao thức
- **Cơ chế truyền thông điệp:** giải quyết các vấn đề về tổ chức định hướng và truyền thông điệp.
- **Cơ chế phân tán:** giải quyết vấn đề về tổ chức các thành phần trên nhiều nút xử lý của hệ thống.
- **Cơ chế quản lý giao dịch:** giải quyết vấn đề về tổ chức quản lý giao dịch.
* **Cơ chế điều khiển và đồng bộ hóa tiến trình:** giải quyết vấn đề về cơ chế đồng bộ giữa các tiến trình.
* **Cơ chế chuyển đổi định dạng và trao đổi thông tin:** giải quyết vấn đề về chuẩn định dạng làm cơ sở cho việc trao đổi thông tin.
* **Cơ chế an ninh:** giải quyết các vấn đề về an ninh hệ thống.
* Tính chi tiết dữ liệu
* Tính chi tiết người dùng
* Quy tắc bảo mật
* Phân quyền
* **Cơ chế điều khiển lỗi và thất bại:** giải quyết vấn đề tổ chức điều khiển các lỗi phát sinh trong quá trình hệ thống thực thi cũng như cách xử lý cho các lần thất bại.
* **Cơ chế về dư thừa thông tin:** giải quyết các vấn đề về tổ chức thông tin để tránh việc dư thừa thông tin.
* **Cơ chế về giao diện hệ thống cũ:** giải quyết vấn đề giao tiếp với các hệ đã có sẵn.
* Độ trễ
* Thời lượng
* Cơ chế truy cập
* Tần suất truy cập
#### e. Mô tả cơ chế phân tích:
* **Thu thập tất cả các cơ chế phân tích theo một danh sách.** Cùng cơ chế phân tích có thể được đề cập dưới các tên khác nhau và trong các điều kiện hoàn cảnh khác nhau. Chẳng hạn, các vấn đề như kho lưu trữ, lưu trữ bền vững, cơ sở dữ liệu hay tổ chức lưu trữ đều để đến một cơ chế tổ chức lưu trữ các đối tượng lâu dài.
* **Tương ứng các lớp khách (client classes) với các cơ chế phân tích.** Một lớp có thể tham gia trong nhiều cơ chế phân tích và ngược lại một cơ chế phân tích liên quan đến nhiều lớp.
* **Xác định các đặc điểm chính của cơ chế phân tích.** Để lựa chọn được giải pháp thiết kế phù hợp, chúng ta cần phải liệt kê các đặc điểm chính của cơ chế như là những tiêu chỉ để từ đó có thể tiến hành lựa chọn và đánh giá các giải pháp đề ra đỏ. Những đặc điểm đó có thể là về mặt chức năng, quy mô hay khía cạnh thực hiện.
* **Mô hình hóa hành vi sử dụng các cộng tác.** Một khi tất cả các cơ chế phân tích đã được xác định và định danh, chúng cần được mô hình hóa thông qua sự cộng tác của các lớp đối tượng. Một số lớp không trực tiếp liên quan đến chức năng hệ thống mà chỉ đóng vai trò là các lớp tiện ích. Những lớp đó thường nằm ở các tầng trung gian và tầng dưới, nơi cung cấp các dịch vụ và phần mềm dùng chung cho tất cả các lớp ở cấp độ ứng dụng.
* 
### 7. Xác định các trừu tượng chính
#### a. Các trừu tượng chính của hệ thống
- Trừu tượng chính là khái niệm, thường được phát hiện trong Yêu cầu, mà hệ thống phải có khả năng xử lý.
- Các nguồn xác định các trừu tượng chính
- Tri thức miền
- Yêu cầu
- Bảng chú giải
- Mô hình miền hoặc Mô hình nghiệp vụ (nếu có)
#### b. Xác định các trừu tượng chính
- Xác định mối quan hệ các lớp phân tích
- Mục đích: Giảm tải cho khâu phân tích, nhất là khâu phân tích ca sử dụng
- Mô hình hóa các lớp phân tích và mối quan hệ trên biểu đồ lớp
- Bao gồm mô tả ngắn gọn về lớp phân tích
- Ánh xạ các lớp phân tích với các cơ chế phân tích cần thiết
- 
- VD:
- Giáo sư: Người giảng dạy các lớp học tại trường đại học.
* Sinh viên: Người đăng ký học các lớp học tại trường đại học.
* Lịch học: Các khóa học mà một sinh viên đã đăng ký trong một kỳ học.
* Sách giáo trình: Danh mục đầy đủ của tất cả các khóa học được cung cấp bởi trường đại học.
* Khóa học được cung cấp: Một phiên bản cụ thể cho một khóa học, bao gồm các ngày trong tuần và thời gian.
* Khóa học: Một lớp học được cung cấp bởi trường đại học.
### 8. Xác định các hiện thực hóa ca sử dụng
- Là sự chi tiết từ khía cạnh thiết kế của ca sử dụng
- Đó là một phần tử mô hình về tổ chức được sử dụng để nhóm gộp một số các chế tác liên quan đến thiết kế ca sử dụng.
- Các ca sử dụng là tách biệt khỏi các hiện thực hóa ca sử dụng, do đó, chúng ta có thể cập nhật thay đổi một cách độc lập các hiện thực hóa này mà không làm ảnh hưởng đến các ca sử dụng gốc ban đầu.
- Mỗi ca sử dụng trong mô hình ca sử dụng sẽ tương ứng với một hiện thực hóa ca sử dụng trong khâu thiết kế thông qua quan hệ phụ thuộc hiện thực hóa, stereotype của nó là `<<realize>>`.
- Ý nghĩa của việc xác định các hiện thực hóa ca sử dụng:
- Ca sử dụng thiết lập một tâm điểm và định hướng cho các hoạt động phân tích và thiết kế giai đoạn đầu.
- Trong chuyển dịch từ các hoạt động hướng nắm bắt yêu cầu sang các hoạt động hướng thiết kế, hiện thực hóa ca sử dụng đóng vài trò là cầu nối cho chuyển dịch đó.
- Nó cung cấp một phương cách để lần vết hành vi tử mô hình thiết kế về mô hình ca sử dụng.
- Nó cũng giúp tổ chức các cộng tác trong mô hình thiết kế theo định hướng ca sử dụng.
### 9. Checkpoint
- Tổng quan
- Phân chia gói và lớp có được thực hiện một cách logic nhất quán không?
- Các cơ chế phân tích cần thiết đã được xác định chưa?
- Các gói
- Chúng ta đã cung cấp một bức tranh toàn diện về các dịch vụ của các gói ở các tầng cao hơn chưa?
- Các lớp
- Các lớp thực thể chính và mối quan hệ của chúng đã được xác định và mô hình hóa chính xác chưa?
- Tên của mỗi lớp có phản ánh rõ vai trò mà nó đóng không?
- Các trừu tượng/lớp chính và mối quan hệ của chúng có nhất quán với Mô hình Nghiệp vụ, Mô hình Miền, Yêu cầu, Bảng chú giải,... không?
- Link phần 2: https://hackmd.io/@MKEfBaQiQsyTSPlcXGLq9A/BJOplczxR
Sign in with Wallet
Connect another wallet