# Phân tích thiết kế hướng đối tượng 2
## Bài 6: Phân tích ca sử dụng
### 1. Mục tiêu:
- Giải thích mục đính của Phân tích ca sử dụng và nơi chúng được sử dụng trong vòng đời
- Chỉ ra các lớp biểu diễn luồng sự kiện của ca sử dụng
- Phân tách các hành vi của ca sử dụng vào các lớp, chỉ ra trách nhiệm cho từng lớp
- Phát triển hiện thực hóa ca sử dụng mà mô hình hóa sự cộng tác giữa thể hiện của các lớp được xác định
### 2. Phân tích ca sử dụng trong bối cảnh
- Ở phần Analyze Behavior
* Sơ đồ minh họa quy trình làm việc trong khóa học này dựa trên phương pháp Phân tích và Thiết kế của Phương pháp Thống nhất Hợp lý (Rational Unified Process). Trong đó, Phân tích Use-Case là một phần quan trọng.
* Đã thực hiện một nỗ lực ban đầu để xác định kiến trúc, bao gồm các tầng và trừng tượng quan trọng cùng một số cơ chế phân tích chính. Kiến trúc này, kèm theo yêu cầu phần mềm, hướng dẫn và làm đầu vào cho hoạt động Phân tích Use-Case.
* Mỗi ca sử dụng cần phát triển trong một vòng lặp đều được thực hiện một phân tích Use-Case. Trong đó, xác định các lớp phân tích và trách nhiệm của chúng.
* Sử dụng các mẫu kiến trúc đã được xác định để hỗ trợ phân bổ trách nhiệm cho các lớp phân tích. Các tầng kiến trúc và phụ thuộc của chúng cũng có thể ảnh hưởng đến việc này.
* Sự phân bổ trách nhiệm được mô hình hóa trong các thực hiện Use-Case, mô tả cách các lớp phân tích hợp tác thực hiện các trường hợp sử dụng. Các thực hiện này sau đó được làm rõ hơn trong Mô hình Thiết kế Use-Case.
- 
### 3. Tổng quan phân tích ca sử dụng
- 
- Các bước phân tích ca sử dụng
- Bổ sung, hoàn thiện mô tả ca sử dụng
- Với mỗi hiện thực hóa ca sử dụng:
- Tìm các lớp từ các hành vi ca sử dụng
- Phân chia những hành vi ca sử dụng vào các lớp
- Với mỗi lớp phân tích kết quả có được:
- Mô tả trách nhiệm
- Mô tả thuộc tính và các liên kết
- Xác định cơ chế phân tích
- Thống nhất các lớp phân tích
- Checkpoints
### 4. Bổ sung, hoàn thiện mô tả ca sử dụng
- 
- Hệ thống hiển thị một danh sách các khóa học được cung cấp
- Hệ thống truy xuất và hiển thị danh sách các khóa học hiện tại từ CSDL kế thừa danh mục khóa học
- Mô tả cho mỗi ca sử dụng không luôn đủ để tìm ra các lớp phân tích và các đối tượng của chúng.
- Thông thường, khách hàng không quan tâm đến thông tin về những gì xảy ra bên trong hệ thống, vì vậy các mô tả ca sử dụng có thể bỏ qua thông tin như vậy.
- Trong những trường hợp như vậy, mô tả ca sử dụng đọc như một mô tả "hộp đen", trong đó các chi tiết bên trong về những gì hệ thống làm phản hồi đến hành động của một actor có thể bị thiếu hoặc chỉ được mô tả rất tóm tắt.
- Để tìm ra các đối tượng thực hiện ca sử dụng, bạn cần có mô tả "hộp trắng" về những gì hệ thống làm từ một góc nhìn nội bộ.
### 5. Với mỗi hiện thực hóa ca sử dụng
#### a. Tìm lớp từ Hành vi ca sử dụng
- Review: Lớp
- Là một sự trừu tượng
- Mô tả một nhóm các đối tượng có điểm chung:
- Thuộc tính
- Hành vi
- Quan hệ
- Ngữ nghĩa
- Review: Hiện thực hóa ca sử dụng
- Lớp phân tích: Bước đầu tiên hướng tới sự thực thi
- 
- Tìm kiếm các lớp từ các Hành vi ca sử dụng
- Hành vi hoàn chỉnh của một ca sử dụng phải được phân phối đến các lớp phân tích
- Sử dụng ba góc nhìn khác nhau của hệ thống để thúc đẩy việc xác định các lớp ứng cử. Ba góc nhìn này là:
- Ranh giới giữa hệ thống và các tác nhân của nó
- Thông tin mà hệ thống sử dụng
- Logic điều khiển của hệ thống
- Việc sử dụng các khuôn mẫu để đại diện cho các góc nhìn này (ví dụ: ranh giới, điều khiển và thực thể) dẫn đến một mô hình mạnh mẽ hơn vì chúng cô lập những thứ có khả năng thay đổi nhất trong một hệ thống: giao diện/môi trường, luồng điều khiển và các thực thể hệ thống chính. Các hình mẫu này là tiện ích được sử dụng trong Phân tích và biến mất trong Thiết kế.
- Xác định các lớp chỉ đơn giản là vậy: Chúng nên được xác định, đặt tên và mô tả một cách ngắn gọn trong vài câu.
- Lớp phân tích là gì?
- 
- Các lớp phân tích đại diện cho một mô hình khái niệm sớm về "những thứ trong hệ thống có trách nhiệm và hành vi." Các lớp phân tích được sử dụng để thu thập một bản dự thảo "đầu tiên" của Mô hình Đối tượng của hệ thống.
- Các lớp phân tích chủ yếu xử lý các yêu cầu chức năng. Chúng mô hình các đối tượng từ miền vấn đề. Các lớp phân tích có thể được sử dụng để đại diện cho "những đối tượng mà chúng ta muốn hệ thống hỗ trợ" mà không đưa ra quyết định về việc hỗ trợ chúng bằng phần cứng và phần mềm như thế nào.
- Ba khía cạnh của hệ thống có khả năng thay đổi:
- Ranh giới giữa hệ thống và các hoạt động của nó
- Thông tin mà hệ thống sử dụng
- Logic điều khiển của hệ thống
- Trong một nỗ lực để cô lập các phần của hệ thống sẽ thay đổi, các loại lớp phân tích sau đây được xác định với một tập hợp "sẵn có" các trách nhiệm:
- Ranh giới
- Thực thể
- Điều khiển
- Các hình mẫu có thể được định nghĩa cho mỗi loại. Những phân biệt này được sử dụng trong Phân tích, nhưng biến mất trong Thiết kế.
- Các loại lớp phân tích khác nhau có thể được đại diện bằng các biểu tượng khác nhau hoặc bằng tên của hình mẫu trong dấu ngoặc kép (<< >>): <<ranh giới>>, << điều khiển>>, <<thực thể>>.
- Boundary class (lớp ranh giới):
- Là trung gian giữa giao diện và một cái gì đó bên ngoài hệ thống
- Các lớp ranh giới cô lập hệ thống khỏi các thay đổi trong môi trường (ví dụ: các thay đổi trong giao diện với các hệ thống khác và các thay đổi trong yêu cầu của người dùng), giữ cho những thay đổi này không ảnh hưởng đến phần còn lại của hệ thống.
- Có vài loại như:
- Các lớp giao diện (interface) người dùng
- Các lớp giữa trung gian trong việc giao tiếp với người dùng của hệ thống.
- Các lớp giao diện hệ thống
- Các lớp giữa trung gian trong việc giao tiếp với các hệ thống khác. Một lớp ranh giới liên lạc với một hệ thống bên ngoài chịu trách nhiệm quản lý cuộc đối thoại với hệ thống bên ngoài đó; nó cung cấp giao diện đến hệ thống đó cho hệ thống đang được xây dựng.
- Các lớp giao diện thiết bị
- Các lớp cung cấp giao diện cho các thiết bị phát hiện sự kiện bên ngoài. Những lớp ranh giới này thu thập các trách nhiệm của thiết bị hoặc cảm biến.
- Một lớp ranh giới chỗ mỗi cặp tác nhân/ca sử dụng
- Vai trò của lớp ranh giới:
- Mô hình hóa sự tương tác giữa hệ thống và môi trường của chúng
* Một lớp ranh giới được sử dụng để mô hình hóa sự tương tác giữa môi trường của hệ thống và các hoạt động bên trong của nó. Sự tương tác này bao gồm việc biến đổi và dịch chuyển sự kiện và ghi nhận các thay đổi trong bản trình bày của hệ thống (như giao diện).
* Các lớp ranh giới mô hình các phần của hệ thống phụ thuộc vào môi trường của nó. Chúng giúp việc hiểu hệ thống dễ dàng hơn bởi vì chúng làm sáng tỏ ranh giới của hệ thống và hỗ trợ thiết kế bằng cách cung cấp một điểm xuất phát tốt để xác định các dịch vụ liên quan. Ví dụ, nếu bạn xác định một giao diện máy in sớm trong quá trình thiết kế, bạn sẽ nhận ra rằng bạn cũng phải mô hình định dạng của các bản in.
* Vì các lớp ranh giới được sử dụng giữa các actor và hoạt động của hệ thống bên trong (actor chỉ có thể giao tiếp với các lớp ranh giới), chúng cô lập các lực bên ngoài khỏi các cơ chế bên trong và ngược lại. Do đó, việc thay đổi giao diện người dùng hoặc giao thức giao tiếp chỉ đòi hỏi thay đổi các lớp ranh giới, không phải các lớp thực thể và điều khiển.
* Một đối tượng ranh giới (một trường hợp của một lớp ranh giới) có thể tồn tại lâu hơn một ca sử dụng nếu, ví dụ, nó phải xuất hiện trên màn hình giữa việc thực hiện hai ca sử dụng. Tuy nhiên, thông thường, các đối tượng ranh giới chỉ tồn tại trong thời gian một ca sử dụng.
- Ví dụ: Tìm các lớp ranh giới:
- 
- Lời khuyên cho việc Phân tích là tạo ra một bức tranh tốt về cách hệ thống được cấu thành, không phải thiết kế từng chi tiết cuối cùng. Nói cách khác, chỉ xác định các lớp ranh giới cho các hiện tượng trong hệ thống hoặc cho các yếu tố được đề cập trong luồng sự kiện của Ca Sử dụng.
- Xem xét nguồn gốc của tất cả các sự kiện bên ngoài và đảm bảo hệ thống có cách nào để phát hiện các sự kiện này. Một khuyến nghị cho việc xác định ban đầu các lớp ranh giới là một lớp ranh giới cho mỗi cặp actor/ca sử dụng. Lớp này có thể được coi là có trách nhiệm điều phối tương tác với actor. Điều này có thể được điều chỉnh khi thực hiện phân tích chi tiết hơn. Điều này đặc biệt đúng đối với các ứng dụng giao diện người dùng dựa trên cửa sổ, nơi mà thường có một lớp ranh giới cho mỗi cửa sổ hoặc mỗi hộp thoại.
- Chỉ dẫn: Lớp ranh giới
- Các lớp giao diện người dùng:
- Tập trung vào việc thông tin nào được trình bày cho người dùng
- Không tập trung vào chi tiết UI
- Các lớp ranh giới có thể được sử dụng như là "nơi tạm trữ" cho các lớp giao diện người dùng (GUI). Mục tiêu không phải là thiết kế GUI trong phân tích này, mà là cô lập tất cả hành vi phụ thuộc vào môi trường.
- Bản phác thảo hoặc bắt màn hình từ một nguyên mẫu giao diện người dùng có thể đã được sử dụng trong quá trình yêu cầu để minh họa hành vi và giao diện của các lớp ranh giới. Những điều này có thể được liên kết với một lớp ranh giới. Tuy nhiên, chỉ mô hình hóa các trừu tượng chính của hệ thống; đừng mô hình hóa mọi nút, danh sách và widget trong GUI.
- Các lớp giao diện hệ thống và thiết bị
- Tập trung vào việc các giao thức nào phải được định nghĩa
- KHÔNG tập trung vào việc cách các giao thức đó được thực hiện
- Tập trung vào việc mô tả trách nhiệm, chứ không phải chi tiết
- Nếu giao diện với một hệ thống hoặc thiết bị hiện tại đã được xác định rõ, các trách nhiệm của lớp ranh giới nên được suy ra trực tiếp từ định nghĩa giao diện. Nếu có một cách tiếp xúc hoạt động với hệ thống hoặc thiết bị bên ngoài, hãy ghi chú lại để tham khảo sau này trong quá trình thiết kế.
- Lớp thực thể:
- Các trừu tượng chính trong hệ thống
- 
- Các đối tượng thực thể đại diện cho các khái niệm chính của hệ thống đang được phát triển. Các lớp thực thể cung cấp một góc nhìn khác để hiểu về hệ thống, vì chúng hiển thị cấu trúc dữ liệu logic. Việc biết cấu trúc dữ liệu có thể giúp bạn hiểu rõ hệ thống cần cung cấp những gì cho người dùng của nó.
- Các nguồn phổ biến cho các lớp thực thể là:
- Bảng chú giải (phát triển trong quá trình yêu cầu)
- Mô hình miền nghiệp vụ (phát triển trong quá trình mô hình hóa nghiệp vụ, nếu đã thực hiện mô hình hóa nghiệp vụ)
- Luồng sự kiện của ca sử dụng (phát triển trong quá trình yêu cầu)
- Các trừu tượng chính (được xác định trong Phân tích Kiến trúc)
- Như đã đề cập trước đó, đôi khi có nhu cầu mô hình thông tin về một tác nhân trong hệ thống. Điều này không giống như việc mô hình hóa tác nhân (tác nhân là bên ngoài, theo định nghĩa). Trong trường hợp này, thông tin về tác nhân được mô hình hóa dưới dạng một lớp thực thể. Những lớp này đôi khi được gọi là "thay thế".
- Vai trò của lớp thực thể:
- Lưu trữ và quản lý thông tin trong hệ thống
- Ví dụ: Tìm một lớp thực thể:
- Sử dụng luồng sự kiện của ca sừ dụng làm đầu vào
- Trừu tượng chính của ca sử dụng
- Các cách tiếp cận truyền thống, chọn lọc
- Gạch chân các danh từ trong luồng sự kiện của ca sử dụng
- Loại bỏ các ứng viên dư thừa
- Loại bỏ các ứng viên mơ hồ
- Loại bỏ các tác nhân (ngoài phạm vi)
- Loại bỏ các cấu trúc triển khai
- Loại bỏ các thuộc tính (để cho phần sau)
- Loại bỏ các hành động
- Ví dụ: Các ứng viên của lớp thực thể
- 
- Lớp kiểm soát/điều khiển (Control class):
- Hệ thống có thể thực hiện một số ca sử dụng mà không cần các lớp điều khiển chỉ bằng cách sử dụng các lớp thực thể và ranh giới. Điều này đặc biệt đúng đối với các ca sử dụng liên quan chỉ đến việc thao tác đơn giản trên thông tin được lưu trữ.
- Điều phối viên hành vi ca sử dụng
- Các ca sử dụng phức tạp hơn thường yêu cầu một hoặc nhiều ca kiểm soát
- Cung cấp các hành vi:
- Độc lập với môi trường (không thay đổi khi môi trường thay đổi)
- Xác định logic điều khiển (thứ tự giữa các sự kiện) và giao dịch trong một trường hợp sử dụng.
- Thay đổi ít nếu cấu trúc hoặc hành vi nội bộ của các lớp thực thể thay đổi.
- Sử dụng hoặc thiết lập nội dung của nhiều lớp thực thể và do đó cần phối hợp hành vi của các lớp thực thể này.
- Vai trò của lớp điều khiển:
- Phối hợp hành vi ca sử dụng
- VD: Tìm kiếm lớp điều khiển
- Tổng quát, xác định một lớp điều khiển đối với mỗi ca sử dụng
- Khi quá trình phân tích tiếp tục, các lớp điều khiển của ca sử dụng phức tạp có thể chia thành nhiều lớp
- 
- Ví dụ: Tóm lại: Lớp phân tích
- 
#### b. Phân phối các hành vi ca sử dụng vào các lớp
- Với mỗi luồng sự kiện của ca sử dụng
- Xác định lớp phân tích
- Phân bố trách nhiệm của các ca sử dụng cho các lớp phân tích
- Mô hình hóa các tương tác lớp phân tích ở Biểu đồ tương tác
- Hướng dẫn: Phân bổ trách nhiệm ca sử dụng cho các lớp phân tích
- Sử dụng khuôn mẫu của lớp phân tích làm hướng dẫn
- Lớp ranh giới:
- Hành vi liên quan đến việc giao tiếp với một tác nhân
- Lớp thực thể:
- Hành vi liên quan đến việc đóng gói dữ liệu trong phần trừu tượng
- Lớp điều khiển:
- Hành vi cụ thể cho một ca sử dụng hoặc một phần quan trọng của luồng sự kiện
- Ai có dữ liệu cần thiết để thực hiện trách nhiệm
- Nếu một lớp có dữ liệu cần thiết, hãy đặt trách nhiệm với phần dữ liệu
- Nếu có nhiều lớp có dữ liệu:
- Đặt trách nhiệm với một lớp và thêm một quan hệ cho những lớp khác.
- Tạo một lớp mới, đặt trách nhiệm trong một lớp mới, và thêm các quan hệ đến các lớp cần thiết để thể hiện trách nhiệm.
- Khi một hành vi mới được xác định, hãy kiểm tra xem có lớp hiện có nào có các trách nhiệm tương tự, tái sử dụng các lớp nơi có thể. Bạn chỉ nên tạo ra các lớp mới khi bạn chắc chắn rằng không có đối tượng hiện có nào có thể thực hiện hành vi đó.
- Đặt trách nhiệm vào trong một lớp điều khiển, và thêm các quan hệ đến các lớp cần thiết để thể hiện trách nhiệm.
- Chi tiết về Biểu đồ Tuần tự
- 
- VD: 
- Chi tiết về Biểu đồ Cộng tác
- 
- VD: 
- Một biểu đồ tương tác là không đủ
- 
- 
- Biểu đồ tương tác vs Biểu đồ tuần tự
- Biểu đồ tương tác
- Hiển thị các mối quan hệ ngoài sự tương tác
- Tốt hơn để hình dung các mô hình cộng tác
- Tốt hơn để hình dung tất cả các hiệu ứng trên một đối tượng nhất định
- Dễ dàng sử dụng hơn cho các phiên cần suy nghĩ
- Biểu đồ tuần tự
- Hiển thị các chuỗi tin nhắn rõ ràng
- Tốt hơn để hình dung luồng tổng thể
- Tối hơn cho các đặc tả theo thời gian và cho các kịch bản phức tạp
### 6. Với mỗi lớp phân tích kết quả
#### a. Mô tả trách nhiệm
- Trách nhiệm là gì?
- Ta tìm chúng như thế nào?
- 
- VD:
- 
- Duy trì tính nhất quán: Điều cần tìm
* Theo thứ tự quan trọng
* Trách nhiệm dư thừa giữa các lớp
* Phân chia trách nhiệm trong các lớp
* Lớp có một trách nhiệm
* Lớp không có trách nhiệm
* Phân phối hành vi tốt hơn
* Lớp tương tác với nhiều lớp khác
#### b. Mô tả thuộc tính và quan hệ kết hợp
- Nhắc lại: Thuộc tính là gì?
- Tìm thuộc tính
- Thuộc tính/đặc điểm của các lớp được xác định
* Thông tin được lưu giữ bởi các lớp được xác định
* “Danh từ” không trở thành lớp
* Thông tin có giá trị là quan trọng
* Thông tin được “sở hữu” duy nhất bởi một đối tượng
* Thông tin không có hành vi
* Nhắc lại: Quan hệ kết hợp là gì?
* Mối quan hệ ngữ nghĩa giữa hai hoặc nhiều lớp chỉ rõ các liên kết giữa các thể hiện của chúng
* Một mối quan hệ về mặt cấu trúc, xác định rằng các đối tượng của một thứ được kết nối với các đối tượng của một thứ khác
* Tìm các mối quan hệ:
* 
* Nhắc lại: Quan hệ quy nạp là gì?
* 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 thể (toàn bộ) và các bộ phận của nó
* 
- Kết hợp hay quan hệ?
- Nếu hai đối tượng bị ràng buộc chặt chẽ bởi mối quan hệ toàn bộ
- Mối quan hệ sẽ là quy nạp
- Nếu hai đối tượng thường được xem là độc lập, mặc dù chúng thường xuyên liên kết với nhau
- Mối quan hệ sẽ là kết hợp
- Mục đích:
- Là "bộ mặt" mà một lớp có trong kết hợp
- Nhắc lại: Đa bội:
- 
- Ý nghĩa: Đa bội trả lời cho hai vấn đề
- Việc kết hợp là bắt buộc hay tùy chọn?
- Số thể hiện tối thiểu và tối đa có thể liên kết đến một thể hiện khác?
- 
- Ví dụ: Kết hợp đa bội
- Kết hợp đa bội phải phản ánh được nhiều vai trò.
- 
- VD: 
#### c. Xác định cơ chế phân tích:
- Mô tả cơ chế phân tích:
- Tập hợp tất cả các cơ chế phân tích thành một danh sách
- Vẽ một bảng ánh xạ các lớp người dùng đến cơ chế phân tích
- Xác định đặc điểm của cơ chế phân tích
### 7. Đồng nhất các lớp phân tích
- 
- Đánh giá kết quả của bạn:
- 
### 8. Checkpoint:
- Lớp phân tích:
- Các lớp có hợp lý không?
- Tên của mỗi lớp có phản ánh rõ ràng vai trò của nó không?
- Lớp này có đại diện cho một sự trừu tượng được xác định rõ ràng không?
- Tất cả các thuộc tính và trách nhiệm có được kết hợp chức năng không?
- Các lớp có cung cấp các hành vi được yêu cầu không?
- Tất cả các yêu cầu cụ thể về lớp có được giải quyết không?
- Hiện thực hóa ca sử dụng:
- Tất cả các dòng chính và/hoặc phụ đã được xử lý bao gồm trường hợp ngoại lệ chưa ?
* Tất cả các đối tượng cần thiết đã được tìm thấy chưa?
* Tất cả các hành vi đã được phân phối một cách mạch lạc cho các đối tượng tham gia chưa?
* Có phải tất cả các thuộc tính và trách nghiệm được kết hợp về mặt chức năng?
* Hành vi đã được phân phối cho các đối tượng phù hợp chưa?
* Khi có nhiều biểu đồ tương tác, mối quan hệ của chúng có rõ ràng và nhất quán không?
- Phân tích ca sử dụng:
- Mục đích của use-case là gì?
* Lớp phân tích là gì? Đặt tên và mô tả 3 khuôn mẫu phân tích
* Điều kiện sử dụng use-case là gì?
* Mô tả một số điều cần xem xét khi phân bổ trách nghiệm cho các lớp phân tích?
* Có bao nhiêu biểu đồ tương tác nên được tạo ra trong quá trình phân tích use-case?

## Bài 7: Xác định các phần tử thiết kế
### 1. Mục đích:
- Tìm hiểu mục đích của Xác định các phần tử thiết kế và chỉ ra chúng được thực hiện ở đâu trong vòng đời.
- Phân tích sự tương tác giữa các lớp phân tích và các phần tử các định mô hình thiết kế
- Lớp thiết kế
- Hệ thống con
- Giao diện hệ thống con
### 2. Bối cảnh:
- Nằm ở Làm mịn Kiến trúc
- Trong Phân tích Kiến trúc, đã có một nỗ lực ban đầu để xác định các tầng của hệ thống của chúng ta, tập trung vào các tầng trên cùng. Trong Phân tích Trường hợp Sử dụng, bạn đã phân tích yêu cầu của mình và phân bổ trách nhiệm cho các lớp phân tích.
- Trong Xác định Các Phần Tổ chức Thiết kế, các lớp phân tích được tinh chỉnh thành các phần tử thiết kế (các lớp thiết kế và hệ thống phụ).
- Trong Phân tích Ca Sử dụng, bạn quan tâm đến "những gì". Trong các hoạt động kiến trúc, bạn quan tâm đến "cách" (ví dụ: Thiết kế). Kiến trúc là về việc đưa ra các lựa chọn.
### 3. Tổng quan:
- 
- Kiến trúc sư thực hiện Xác định Các Phần Tổ chức Thiết kế, một lần trong mỗi vòng lặp.
- Mục đích
- Phân tích tương tác của các lớp phân tích để xác định các phần tử Mô hình Thiết kế.
- Tạo tác đầu vào
- Các Đặc tả Bổ sung
- Hướng dẫn Cụ thể cho Dự án
- Tài liệu Kiến trúc Phần mềm
- Các lớp Phân tích
- Mô hình Phân tích
- Mô hình Thiết kế
- Tạo tác Kết quả
- Các phần tử Mô hình Thiết kế
- Các lớp
- Các gói
- Các hệ thống con
- Các bước xác định lớp phân tích:
- Xác định các lớp và hệ thống con
- Xác định giao diện hệ thống con
- Cập nhật sự tổ chức của mô hình thiết kế
- Checkpoint
### 4. Xác định các lớp và hệ thống con:
- 
- Là many-to-many mapping
- Xác định Các Phần Tổ chức Thiết kế là nơi các lớp phân tích được xác định trong Quá trình Phân tích Ca sử dụng được tinh chỉnh thành các phần tử thiết kế (ví dụ: các lớp hoặc các hệ thống phụ).
- Các lớp phân tích chủ yếu xử lý các yêu cầu chức năng và mô hình các đối tượng từ miền "vấn đề"; các phần tử thiết kế xử lý các yêu cầu phi chức năng và mô hình các đối tượng từ miền "giải pháp".
- Đây là nơi mà bạn quyết định các "lớp" phân tích nào thực sự là các lớp, các hệ thống con nào (cần được phân giải cấp tiếp theo) và các thành phần hiện có nào không cần phải được "thiết kế" gì cả.
- Sau khi các lớp thiết kế và các hệ thống con đã được tạo ra, mỗi cái phải được đặt tên và mô tả ngắn gọn. Các trách nhiệm của các lớp phân tích gốc nên được chuyển sang các hệ thống con mới được tạo ra. Ngoài ra, các cơ chế thiết kế được xác định cũng nên được liên kết với các phần tử thiết kế.
- Xác định lớp thiết kế:
- Một lớp thiết kế ánh xạ trực tiếp một lớp phân tích nếu:
- Đó là một lớp đón giản
- Nó thể hiện một sự trừu tượng logic duy nhất
- Điều này có thể ám chỉ đến một ý tưởng, một quy luật hoặc một phương pháp mà chỉ có một cách để hiểu hoặc áp dụng, không có sự mơ hồ hoặc đa dạng trong cách tiếp cận.
- Trong phân tích thiết kế hướng đối tượng, một ví dụ về sự trừu tượng logic duy nhất có thể là nguyên lý "Single Responsibility Principle" (Nguyên tắc duy nhất trách nhiệm).
- Nguyên tắc này nói rằng mỗi lớp hoặc module trong một hệ thống phải chỉ có một trách nhiệm duy nhất và không nên chịu trách nhiệm vượt quá điều đó. Ví dụ, nếu bạn có một lớp User trong một ứng dụng, nó nên chỉ chịu trách nhiệm về việc quản lý thông tin người dùng như tên, địa chỉ email, và các thao tác liên quan đến người dùng. Nó không nên chịu trách nhiệm về việc xử lý thanh toán hoặc xác thực, vì điều này sẽ vi phạm nguyên tắc duy nhất trách nhiệm.
- Nguyên tắc này là trừu tượng vì nó không chỉ áp dụng cho một ngữ cảnh cụ thể hoặc một loại ứng dụng cụ thể. Thay vào đó, nó là một nguyên lý thiết kế chung và logic duy nhất áp dụng cho nhiều loại hệ thống và dự án phát triển phần mềm.
- Nhiều lớp phân tích phức tạp có thể
- Chia thành nhiều lớp
- Trở thành một gói
- Trờ thành một hệ thống con
- ...
- Một lớp phân tích có thể trở thành:
* Một lớp duy nhất trong Mô hình Thiết kế.
* Một phần của một lớp trong Mô hình Thiết kế.
* Một lớp tổng hợp trong Mô hình Thiết kế (nghĩa là các phần trong tổng hợp này có thể không được mô hình rõ ràng trong Mô hình Phân tích.)
* Một nhóm các lớp mà kế thừa từ cùng một lớp trong Mô hình Thiết kế.
* Một nhóm các lớp có liên quan chức năng trong Mô hình Thiết kế (ví dụ: một gói).
* Một hệ thống phụ trong Mô hình Thiết kế.
* Một mối quan hệ trong Mô hình Thiết kế.
- Nhắc lại: Lớp và gói
- Lớp: là sự môt tả của một tập hợp những đối tượng có cùng trách nhiệm, mối quan hệ, hành vi và thuộc tính, và mối quan hệ ngữ nghĩa
- Gói:
- Là một cơ chế có mục đích chung cho việc tổ chức các phần tử thành các nhóm
- Một phần tử mô hình có thể chứa nhiều phần tử vô hình khác.
- Nhóm các lớp thiết kế vào trong gói:
- Khi xác định các lớp, bạn nên nhóm chúng vào các gói, với mục đích tổ chức và quản lý cấu hình.
- Mô hình Thiết kế có thể được cấu trúc thành các đơn vị nhỏ hơn để dễ hiểu hơn. Bằng cách nhóm các phần tử Mô hình Thiết kế vào các gói và hệ thống con, sau đó chỉ ra cách các nhóm đó liên quan đến nhau, việc hiểu cấu trúc tổng thể của mô hình trở nên dễ dàng hơn.
- Bạn có thể căn cứ vào tiêu chí đóng gói của mình dựa trên một số các nhân tố với nhau, như:
- Đơn vị cấu hình
- Bạn có thể sử dụng các gói và hệ thống phụ như các đơn vị đặt hàng, cấu hình hoặc giao hàng khi một hệ thống hoàn chỉnh.
- Phân bổ tài nguyên giữa các nhóm phát triển
- Phân bổ nguồn lực và năng lực của các nhóm phát triển khác nhau có thể yêu cầu dự án được chia thành các nhóm khác nhau tại các địa điểm khác nhau.
- Phản ánh các loạt người dùng
- Hệ thống phụ có thể được sử dụng để cấu trúc Mô hình Thiết kế theo cách phản ánh các loại người dùng. Nhiều yêu cầu thay đổi bắt nguồn từ người dùng; các hệ thống phụ đảm bảo rằng các thay đổi từ một loại người dùng cụ thể chỉ ảnh hưởng đến các phần của hệ thống tương ứng với loại người dùng đó.
- Đại diện cho các sản phẩn và dịch vụ hiện có mà hệ thống đang dùng.
- Mẹo đóng gói:
- Các lớp biên:
- Khi các lớp biên được phân phối vào các gói, có hai chiến lược khác nhau có thể được áp dụng. Lựa chọn chiến lược nào phụ thuộc vào việc liệu giao diện hệ thống có khả năng thay đổi mạnh trong tương lai hay không.
- Nếu giao diện hệ thống có khả năng sẽ trải qua các thay đổi đáng kể, Các lớp biên được đặt trong các gói riêng biệt.
- Khi giao diện người dùng được thay đổi, chỉ có các gói này bị ảnh hưởng. Một ví dụ về một thay đổi lớn như vậy là sự chuyển từ giao diện dựa trên dòng lệnh sang giao diện dựa trên cửa sổ.
- Nếu không có khả năng cao rằng giao diện hệ thống sẽ trải qua các thay đổi đáng kể, Các lớp biên được đóng gói cùng với các lớp có liên quan chức năng.
- Các lớp biên sau đó nên được đặt cùng với các lớp thực thể và kiểm soát mà chúng có mối liên hệ chức năng. Điều này sẽ giúp dễ dàng nhận thấy các lớp biên nào bị ảnh hưởng nếu một lớp thực thể hoặc kiểm soát cụ thể được thay đổi.
- Các lớp biên bắt buộc mà không có mối liên hệ chức năng với bất kỳ lớp thực thể hoặc kiểm soát nào, nên được đặt trong các gói riêng, cùng với các lớp biên thuộc cùng một giao diện.
- Nếu một lớp biên liên quan đến một dịch vụ tùy chọn, hãy nhóm nó trong một hệ thống phụ riêng với các lớp cộng tác để cung cấp dịch vụ đó. Hệ thống phụ sẽ tương ứng với một thành phần tùy chọn sẽ được cung cấp khi chức năng tùy chọn được đặt hàng.
- Các lớp có liên quan chức năng:
- Tiêu chí để xác định liệu các lớp có liên quan chức năng hay không:
* Sự thay đổi trong hành vi và/hoặc cấu trúc của một lớp đòi hỏi sự thay đổi trong một lớp khác
* Việc loại bỏ một lớp ảnh hưởng đến lớp khác
* Bất kỳ lớp nào trở nên dư thừa do việc loại bỏ một lớp sẽ có một cách nào đó liên kết với lớp bị loại bỏ. Dư thừa ở đây có nghĩa là lớp chỉ được sử dụng bởi lớp bị loại bỏ, hoặc phụ thuộc vào lớp bị loại bỏ.
* Hai đối tượng tương tác với một số lượng lớn các thông điệp hoặc có một sự tương tác phức tạp
* Một lớp biên có thể có liên quan chức năng đối với một lớp thực thể cụ thể nếu chức năng của lớp biên là hiển thị lớp thực thể đó
* Hai lớp tương tác với, hoặc bị ảnh hưởng bởi các thay đổi trong cùng một tác nhân
* Hai lớp có mối quan hệ với nhau (liên kết, tổng hợp)
* Một lớp tạo ra các thể hiện của một lớp khác
* Tiêu chí để xác định khi nào hai lớp không nên được đặt trong cùng một gói:
* Hai lớp có liên quan đến các tác nhân khác nhau không nên được đặt trong cùng một gói
* Một lớp tùy chọn và một lớp bắt buộc không nên được đặt trong cùng một gói
* Phụ thuộc vào Gói: Khả năng Hiển thị Các Phần tử Gói
- Chỉ các lớp public mới có thể được tham chiếu bên ngoài của gói sở hữu.
- Khả năng hiển thị có thể được xác định cho các phần tử gói theo cách tương tự như cách nó được xác định cho các thuộc tính và hoạt động của lớp. Khả năng hiển thị này cho phép bạn chỉ định cách các gói khác có thể truy cập các phần tử thuộc sở hữu của gói.
- Public: Các lớp công cộng có thể được truy cập bên ngoài của gói sở hữu. Biểu tượng khả năng hiển thị: +.
- Protected: Các lớp bảo vệ chỉ có thể được truy cập bởi gói sở hữu và bất kỳ gói nào kế thừa từ gói sở hữu. Biểu tượng khả năng hiển thị: #.
- Private: Các lớp riêng tư chỉ có thể được truy cập bởi các lớp trong gói sở hữu. Biểu tượng khả năng hiển thị: -.
- Liên kết Gói: Gợi Ý
* Các gói không nên được liên kết chéo (tức là, có phụ thuộc lẫn nhau); ví dụ, hai gói không nên phụ thuộc vào nhau. Trong những trường hợp này, các gói cần được tổ chức lại để loại bỏ các phụ thuộc chéo.
* Các gói ở các tầng thấp không nên phụ thuộc vào các gói ở các tầng cao hơn. Các gói chỉ nên phụ thuộc vào các gói ở cùng một tầng và ở tầng dưới tiếp theo. Trong những trường hợp này, chức năng cần được phân chia lại. Một giải pháp là chỉ định các phụ thuộc dưới dạng các giao diện và tổ chức các giao diện ở tầng dưới.
* Nói chung, các phụ thuộc không nên bỏ qua các tầng, trừ khi hành vi phụ thuộc là chung trên tất cả các tầng, và phương án thay thế là đơn giản là chuyển tiếp các cuộc gọi thực hiện qua các tầng.
* Các gói không nên phụ thuộc vào các hệ thống con — chỉ nên phụ thuộc vào các gói khác hoặc trên các giao diện.
- Nhắc lại: Hệ thống con và giao diện
- Đây là một "sự kết hợp" giữ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ó.
- Các hệ thống con:
- Hoàn toàn bao gồm hành vi.
- Đại diện cho một khả năng độc lập với các giao diện rõ ràng (tiềm năng tái sử dụng).
- Mô hình nhiều biến thể triển khai.
- Gói vs Hệ thống con:
- Hệ thống con:
- Cung cấp hành vi
- Hoàn toàn đóng gói các nội dung của chúng
- Dễ dàng thay thế
- Gói:
- Không cung cấp hành vi
- Không hoàn toàn đóng gói nội dung của chúng
- Có thể không dễ thay thế
- Cách sử dụng hệ thống con:
- Các hệ thống con có thể được sử dụng để phân chia hệ thống thành các phần có thể độc lập với nhau:
- Được đặt hàng, cấu hình hoặc giao hàng độc lập.
- Được phát triển, miễn là các giao diện không thay đổi.
- Triển khai trên một tập hợp các nút tính toán phân tán.
- Thay đổi mà không làm hỏng các phần khác của hệ thống.
- Hệ thống con cũng có thể được sử dụng để:
- Phân chia hệ thống thành các đơn vị có thể cung cấp bảo mật hạn chế đối với các tài nguyên quan trọng.
- Đại diện cho các sản phẩm hiện có hoặc hệ thống bên ngoài trong thiết kế (ví dụ: các thành phần).
- Hệ thống nâng cao mức độ trừu tượng
- Xác định hệ thống con:
- Xem xét sự cộng tác giữa các đối tượng.
- Nếu các lớp trong một cộng tác chỉ tương tác với nhau để tạo ra một tập hợp kết quả được xác định rõ ràng, thì gói gọn chúng vào bên trong một hệ thống phụ.
* Tìm kiếm sự tùy chọn.
* Nếu hành động cộng tác mô hình hóa hành vi tùy chọn hoặc các tính năng có thể loại bor, nâng cấp hoặc thay thế bằng các lựa chọn thay thế. sau đó gói gọn chúng trong một hệ thống con
* Xem xét giao diện người dùng của hệ thống.
* Tạo ra các hệ thống con "ngang" (các lớp biên và các lớp thực thể liên quan trong các hệ thống con riêng biệt) hoặc "dọc" (các lớp biên và các lớp thực thể liên quan trong cùng một hệ thống con), tùy thuộc vào sự kết hợp của giao diện người dùng và các lớp thực thể.
* Xem xét các tác nhân.
* Phân chia chức năng được sử dụng bởi hai tác nhân khác nhau, vì mỗi tác nhân có thể thay đổi yêu cầu một cách độc lập.
* Tìm kiếm sự liên kết và kết cấu giữa các lớp.
* Tổ chức các lớp có sự kết hợp cao vào các hệ thống con, tách biệt theo các đường kết hợp yếu.
* Xem xét khả năng thay thế.
* Đại diện cho các mức dịch vụ khác nhau cho một khả năng cụ thể (ví dụ, khả năng cao, trung bình và thấp) như một hệ thống phụ riêng biệt, thực hiện các giao diện tương tự.
* Xem xét phân phối.
* Nếu chức năng cụ thể phải tồn tại trên một nút cụ thể, đảm bảo rằng chức năng của hệ thống con tương ứng ánh xạ vào một nút duy nhất.
* Xem xét tính biến động.
* Bạn sẽ muốn bao gồm những phần của hệ thống mà bạn mong đợi sẽ thay đổi.
- Các ứng viên hệ thống con:
- Các lớp phân tích có thể phát triển thành các hệ thống con:
- Các lớp cung cấp các dịch vụ phức tạp và/hoặc tiện ích.
- Các hệ thống đánh giá tín dụng hoặc rủi ro trong các ứng dụng tài chính
- Các hệ thống đánh giá dựa trên quy tắc trong các ứng dụng thương mại
- Các dịch vụ xác thực bảo mật trong hầu hết các ứng dụng.
- Các lớp biên (giao diện người dùng và giao diện hệ thống bên ngoài).
- Các sản phẩm hiện có hoặc hệ thống bên ngoài trong thiết kế (ví dụ: các thành phần):
- Phần mềm giao tiếp.
- Hỗ trợ truy cập cơ sở dữ liệu.
- Các loại và cấu trúc dữ liệu.
- Các tiện ích chung.
- Các sản phẩm cụ thể cho ứng dụng.
- Xác định hệ thống con
- Khi lớp phân tích phức tạp đến mức có vẻ như nó bao gồm các hành vi không thể là trách nhiệm của một lớp duy nhất hoạt động một mình, hoặc các trách nhiệm có thể cần được sử dụng lại, lớp phân tích đó nên được phân loại thành một hệ thống. Điều này là một quyết định dựa chủ yếu vào sự phỏng đoán được hướng dẫn bởi kinh nghiệm. Biểu diễn thực tế có thể mất vài lần lặp để ổn định.
- Như đã thảo luận trước đó, việc sử dụng một hệ thống cho phép giao diện được xác định và ổn định, trong khi để lại các chi tiết thiết kế của việc triển khai giao diện để ẩn đi trong khi định nghĩa của nó tiếp tục phát triển.
- Quyết định làm cho một cái gì đó trở thành một hệ thống thường được thúc đẩy bởi kiến thức và kinh nghiệm của kiến trúc sư. Vì nó thường có một ảnh hưởng mạnh mẽ đối với việc phân chia không gian giải pháp, quyết định cần được đưa ra trong bối cảnh của toàn bộ mô hình. Đây là kết quả của kiến thức thiết kế chi tiết hơn, cũng như áp đặt các ràng buộc được áp dụng bởi môi trường triển khai.
- Khi một lớp phân tích được phát triển thành một hệ thống, các trách nhiệm đã được phân bổ cho lớp phân tích "siêu nhân" sau đó được phân bổ cho hệ thống và một giao diện liên kết (tức là, chúng được sử dụng để định nghĩa các hoạt động giao diện). Các chi tiết về cách hệ thống đó thực sự thực hiện các trách nhiệm (tức là, các hoạt động giao diện) được hoãn lại cho Thiết kế Hệ thống.
### 5. Xác định giao diện hệ thống con
- Xác định giao diện:
- Mục đích:
- Để xác định giao diện của hệ thống con dựa vào trách nhiệm
- Các bước:
- Xác định tập hợp các giao diện ứng viên cho tất cả hệ thống con
- Tổ chức các trách nhiệm của hệ thống phụ thành các nhóm trách nhiệm có sự kết hợp, có liên quan. Các nhóm này xác định bộ giao diện ban đầu, cắt đầu tiên cho hệ thống phụ. Để bắt đầu, xác định một hoạt động cho mỗi trách nhiệm, bao gồm cả các tham số và giá trị trả về.
- Tìm kiếm điểm tương đồng giữa các giao diện
- Tìm kiếm các tên tương đương, các trách nhiệm tương đương và các hoạt động tương đương. Trích xuất các hoạt động chung vào một giao diện mới. Hãy chắc chắn kiểm tra các giao diện hiện có cũng, sử dụng lại chúng nếu có thể.
- Định nghĩa sự phụ thuộc của giao diện
- Thêm các mối quan hệ phụ thuộc từ giao diện đến tất cả các lớp và/hoặc giao diện xuất hiện trong các chữ ký hoạt động của giao diện.
- Nối những giao diện với những hệ thống con
- Tạo các liên kết thực hiện từ hệ thống phụ đến các giao diện mà nó thực hiện.
- Định nghĩa hành vi được đặc tả bởi giao diện
- Nếu các hoạt động trên giao diện phải được gọi theo một thứ tự cụ thể, định nghĩa một máy trạng thái mà mô tả các trạng thái công khai (hoặc được suy luận) mà bất kỳ yếu tố thiết kế nào thực hiện giao diện đều phải hỗ trợ.
- Đóng gói các giao diện
- Các giao diện có thể được quản lý và kiểm soát độc lập với các hệ thống phụ chính của chúng. Phân chia các giao diện theo trách nhiệm của chúng.
- Giao diện ổn định, được xác định rõ là chìa khóa cho một kiến trúc ổn định, linh hoạt.
- Hướng dẫn về Giao diện:
* Tên Giao diện:
* Phản ánh vai trò trong hệ thống.
* Mô tả Giao diện:
* Truyền đạt các trách nhiệm.
* Định nghĩa Hoạt động:
* Tên nên phản ánh kết quả của hoạt động.
* Mô tả những gì hoạt động làm, tất cả các tham số và kết quả.
* Tài liệu Giao diện:
* Thông tin hỗ trợ gói: các biểu đồ tuần tự và trạng thái, kế hoạch kiểm thử, v.v.
- Các quy ước Mô hình hóa: Hệ thống con và Giao diện
- Gói `<<subsystem>>` cung cấp một nơi chứa cho các phần tử tạo thành hệ thống con, các biểu đồ tương tác mô tả cách các phần tử hệ thống con hợp tác để thực hiện các hoạt động của các giao diện mà hệ thống con thực hiện, và các biểu đồ khác làm rõ các phần tử hệ thống con. Hệ thống con thực hiện giao diện.
- Lớp `<<subsystem proxy>>` thực hiện giao diện(s) (như một proxy) và sẽ chỉ đạo việc triển khai các hoạt động của các giao diện hệ thống con. (Điều này sẽ được thảo luận thêm trong mô-đun về Thiết kế Hệ thống Con.)
- VD: CourseCatalog: Danh mục khóa học
### 6. Xác định các cơ hội tái sử dụng:
- Xác định các cơ hội tái sử dụng:
- Mục đích:
- Để xác định nơi các hệ thống con tồn tại và/hoặc các thành phần có thể được tái sử dụng dựa trên giao diện
- Các bước:
- Tìm kiếm những giao diện tương đồng
- Điều chỉnh giao diện mới để cải thiện sự phù hợp
- Thay thế những giao diện ứng viên bằng các giao diện hiện có
- Ánh xạ hệ thống con ứng viên vào các thành phần hiện có
- Các cơ hội có thể tái sử dụng:
- Bên trong hệ thống đang phát triển:
- Sự tương đồng được nhận biết trên các gói và hệ thống phụ.
- Bên ngoài hệ thống đang phát triển:
- Các thành phần có sẵn thương mại.
- Các thành phần từ một ứng dụng đã được phát triển trước đó.
- Các thành phần được phân tích ngược.
- Cơ hội tái sử dụng nội bộ hệ thống
- Việc tái sử dụng có thể được phát hiện trong hệ thống phần mềm hiện tại. Có thể có các yếu tố thiết kế cần thiết cho nhiều hệ thống hoặc gói hơn. Slideshow trên đây được thiết kế để mô tả trực quan những gì xảy ra khi tái sử dụng được phát hiện:
* Xây dựng ứng dụng đầu tiên và một số phần tổng quát.
* Xây dựng ứng dụng thứ hai, và bạn phát hiện rằng một số phần của ứng dụng đầu tiên có thể được tái sử dụng, nhưng các phần không được thiết kế để tái sử dụng. (Một số phần được tái sử dụng bất kể, với kết quả là sự hỗn loạn). Nhận ra rằng có điều gì đó đang được sử dụng bởi một yếu tố mà các yếu tố khác có thể tìm thấy hữu ích (biểu đồ đầu tiên).
* Lấy các yếu tố thiết kế tái sử dụng ứng cử viên (các lớp, gói hoặc hệ thống) và làm cho chúng có thể tái sử dụng. Điều này có thể bao gồm thay đổi tên của chúng, làm cho chúng trở nên tổng quát hơn, cải thiện tài liệu của chúng, di chuyển chúng đến một tầng chức năng chung, v.v. Cơ bản, thực thể tái sử dụng ứng viên được "đẩy xuống" thành một tầng dưới trong kiến trúc để các yếu tố khác có thể truy cập vào nó. Ban đầu, chỉ có khách hàng gốc của yếu tố mới có thể sử dụng nó (biểu đồ thứ hai).
* Bây giờ bạn có thể sử dụng chúng cho ứng dụng mới.
* Khi ứng dụng đầu tiên được nâng cấp, các phiên bản cũ của các yếu tố có thể được thay thế bằng các phiên bản tái sử dụng (biểu đồ thứ ba).
### 7. Cập nhật tổ chức của Mô hình Thiết kế:
- Xem xét về Phân lớp:
- Khả năng Hiển thị:
- Phụ thuộc chỉ trong lớp hiện tại và các lớp phía dưới.
- Tính Biến động:
- Các lớp ở tầng cao bị ảnh hưởng bởi các thay đổi yêu cầu.
- Các lớp ở tầng thấp bị ảnh hưởng bởi các thay đổi môi trường.
- Tính Chung chung:
- Các phần tử mô hình trừu tượng hơn ở các tầng thấp hơn.
- Số Lớp:
- Hệ thống nhỏ: 3-4 lớp.
- Hệ thống phức tạp: 5-7 lớp.
- Mục tiêu là giảm kết nối và làm giảm công sức bảo trì.
- Xem xét về Phân chia:
- Liên kết và Tính gắn kết:
- Các yếu tố thiết kế có sự liên kết/chắc chắn (ví dụ, nhiều mối quan hệ và giao tiếp) nên được đặt trong cùng một phân vùng.
- Tổ chức người sử dụng:
- Điều này xảy ra khi một Mô hình Nghiệp vụ hiện có có cấu trúc được phân chia tổ chức mạnh mẽ. Thường ảnh hưởng đến các tầng trên cùng (dịch vụ cụ thể cho ứng dụng).
- Năng lực và/hoặc lĩnh vực kỹ năng:
- Ở các tầng giữa và thấp hơn, sự chuyên môn trong kỹ năng nên được xem xét trong quá trình phát triển và hỗ trợ công nghệ cơ sở phức tạp (ví dụ, mạng lưới, phân phối, quản lý cơ sở dữ liệu và/hoặc giao tiếp; kiểm soát quy trình). Ở các tầng trên cùng, sự chuyên môn trong kỹ năng nên được xem xét trong lĩnh vực vấn đề (ví dụ, quản lý cuộc gọi viễn thông, giao dịch chứng khoán, xử lý yêu cầu bảo hiểm và kiểm soát giao thông hàng không).
- Phân phối Hệ thống:
- Điều này giúp hình dung về giao tiếp mạng lưới, sẽ xảy ra khi hệ thống thực thi.
- Bảo mật:
- Chức năng yêu cầu phải có xác thực bảo mật đặc biệt phải được phân chia thành các hệ thống phụ sẽ được phát triển độc lập, với giao diện đến các khu vực bí mật là khía cạnh duy nhất của các hệ thống phụ này.
- Biến đổi:
- Chức năng có khả năng là tùy chọn và do đó chỉ được cung cấp trong một số biến thể của hệ thống, nên được tổ chức vào các hệ thống phụ.
- Cố gắng tránh các phụ thuộc vòng lặp.

## Bài 8: Xác định cơ chế thiết kế
### 1. Mục đích:
- Xác định mục đích của hoạt động Xác định cơ chế thiết kế và giải thích thời điểm hoạt động trong quá trình phát triển
- Giải thích về cơ chế thiết kế và thực thi, và cách ánh xa chúng từ cơ chế phân tích
- Mô tả một số cơ chế chính được sử dụng trong case study
### 2. Bối cảnh:
- Xác định Cơ chế Thiết kế là một hoạt động trong chi tiết quy trình Tinh chỉnh Kiến trúc.
- Xác định Cơ chế Thiết kế là nơi chúng ta tinh chỉnh các cơ chế phân tích thành các cơ chế thiết kế dựa trên các ràng buộc do môi trường triển khai áp đặt.
### 3. Tổng quan:
* Mục đích:
* Tinh chỉnh các cơ chế phân tích thành các cơ chế thiết kế dựa trên các ràng buộc được áp đặt bởi môi trường triển khai.
* Đầu vào:
* Các Đặc tả Bổ sung
* Tài liệu Kiến trúc Phần mềm
* Lớp Phân tích
* Mô hình Thiết kế
* Đầu ra:
* Các phần tử Mô hình Thiết kế
* Các lớp
* Các gói
* Các hệ thống con
* Tài liệu Kiến trúc Phần mềm
* Các bước thực hiện:
* Phân loại các client của cơ chế phân tích
* Tài liệu hóa cơ chế kiến trúc
### 4. Phân loại các client của cơ chế phân tích:
- Nhắc lại về Mẫu và Framework
- Mẫu:
- Cung cấp một giải pháp cụ thể cho một vấn đề phổ biến trong một bối cảnh
- Mẫu thiết kế/phân tích:
- Cung cấp một giải pháp cho một vấn đề kỹ thuật trong một phạm vi hẹp
- Cung cấp một phần của giải pháp hoặc một phần của mô hình giải pháp
- Framework:
- Xác định phương pháp chung để giải quyết vấn đề
- Cung cấp một khung giải pháp cơ bản, các chi tiết của nó có thể bao gồm các mẫu phân tích/thiết kế
- Mẫu thiết kế là gì?
- Mẫu thiết kế cung cấp một cơ chế để tinh chỉnh các hệ thống con hoặc các thành phần của hệ thống phần mềm hoặc các mỗi quan hệ giữa chúng.
- Nó mô tả một cấu trúc thường xuyên lặp lại nhằm giải quyết vấn đề thiết kế chung trong một bối cảnh cụ thể.
- Các loại mẫu thiết kế:
- Mẫu hành vi: Nhóm này dùng trong thực hiện các hành vi của đối tượng, sự giao tiếp giữa các object với nhau.
- Mẫu khởi tạo: Những Design pattern loại này cung cấp một giải pháp để tạo ra các object và che giấu được logic của việc tạo ra nó, thay vì tạo ra object một cách trực tiếp bằng cách sử dụng method new. Điều này giúp cho chương trình trở nên mềm dẻo hơn trong việc quyết định object nào cần được tạo ra trong những tình huống được đưa ra.
- Nhóm cấu trúc: Những Design pattern loại này liên quan tới class và các thành phần của object. Nó dùng để thiết lập, định nghĩa quan hệ giữa các đối tượng.
- Ví dụ về cách dùng mẫu thiết kế:
- Command(Mẫu hành vi): Có thể dùng để thực hiện gửi yêu cầu đến một đối tượng mà không biết thao tác yêu cầu hoặc kết quả của yêu cầu
- Nó cho phép chuyển yêu cầu thành đối tượng độc lập, có thể được sử dụng để tham số hóa các đối tượng với các yêu cầu khác nhau như log, queue (undo/redo), transtraction.
- Command Pattern cho phép tất cả những Request gửi đến object được lưu trữ trong chính object đó dưới dạng một object Command. Khái niệm Command Object giống như một class trung gian được tạo ra để lưu trữ các câu lệnh và trạng thái của object tại một thời điểm nào đó.
- Command dịch ra nghĩa là ra lệnh. Commander nghĩa là chỉ huy, người này không làm mà chỉ ra lệnh cho người khác làm. Như vậy, phải có người nhận lệnh và thi hành lệnh. Người ra lệnh cần cung cấp một class đóng gói những mệnh lệnh. Người nhận mệnh lệnh cần phân biệt những interface nào để thực hiện đúng mệnh lệnh.
- Command Pattern còn được biết đến như là Action hoặc Transaction.
- 
- Command: là một interface hoặc abstract class, chứa một phương thức trừu tượng thực thi (execute) một hành động (operation). Request sẽ được đóng gói dưới dạng Command.
- ConcreteCommand: là các implementation của Command. Định nghĩa một sự gắn kết giữa một đối tượng Receiver và một hành động. Thực thi execute() bằng việc gọi operation đang hoãn trên Receiver. Mỗi một ConcreteCommand sẽ phục vụ cho một case request riêng.
- Client: tiếp nhận request từ phía người dùng, đóng gói request thành ConcreteCommand thích hợp và thiết lập receiver của nó.
- Invoker: tiếp nhận ConcreteCommand từ Client và gọi execute() của ConcreteCommand để thực thi request.
- Receiver: đây là thành phần thực sự xử lý business logic cho case request. Trong phương execute() của ConcreteCommand chúng ta sẽ gọi method thích hợp trong Receiver.
- Như vậy, **Client** và **Invoker** sẽ thực hiện việc **tiếp nhận** request. Còn việc **thực thi** request sẽ do **Command**, **ConcreteCommand** và **Receiver** đảm nhận.
- Abstract Factory(Mẫu khởi tạo):
- Có thể dùng để khởi tạo các đối tượng về UI, độc lập với hệ điều hành.
- Là phương pháp tạo ra một Super-factory dùng để tạo ra các Factory khác. Hay còn được gọi là Factory của các Factory.
- Trong Abstract Factory pattern, một interface có nhiệm vụ tạo ra một Factory của các object có liên quan tới nhau mà không cần phải chỉ ra trực tiếp các class của object. Mỗi Factory được tạo ra có thể tạo ra các object bằng phương pháp giống như Factory pattern.
- Hãy tưởng tượng, Abstract factory như là một nhà máy lớn chứa nhiều nhà máy nhỏ, trong các nhà máy đó có những xưởng sản xuất, các xưởng đó tạo ra những sản phẩm khác nhau.
- 
- Tóm lại:
- Super-factory class có lớp khởi tạo là private
- Sử dụng một super-factory class để khởi tạo các ConcreteFactory. Tạo một hàm static có giá trị trả về là AbstractFactory, sau đó dựa vào các tính chất để tạo các ConcreteFactory
- ConcreteFactory kế thừa từ AbstractFactory
- ConcreteFactory override các hàm từ AbstractFactory để trả ra từng product
- Các hàm từ AbstractFactory đều sử dụng các AbstractProduct để làm giá trị trả về
- Các Product kế thừa từ AbstractProduct
- Proxy(Mẫu cấu trúc): Có thể sử dụng virtual proxy để cho phép chỉ tải đối tượng khi cần thiết
- Là “ủy quyền” hay “đại diện”. Mục đích xây dựng Proxy pattern cũng chính vì muốn tạo ra một đối tượng sẽ ủy quyền, thay thế cho một đối tượng khác.
- Là mẫu thiết kế mà ở đó tất cả các truy cập trực tiếp đến một đối tượng nào đó sẽ được chuyển hướng vào một đối tượng trung gian (Proxy Class). Mẫu Proxy (người đại diện) đại diện cho một đối tượng khác thực thi các phương thức, phương thức đó có thể được định nghĩa lại cho phù hợp với múc đích sử dụng.
- 
- Observer(Mẫu hành vi): Mỗi khi trạng thái của đối tượng thay đổi, các đối tượng liên quan được thông báo, các đối tượng được thay đổi độc lập với các đối tượng được quan sát.
- Nó định nghĩa mối phụ thuộc một – nhiều giữa các đối tượng để khi mà một đối tượng có sự thay đổi trạng thái, tất các thành phần phụ thuộc của nó sẽ được thông báo và cập nhật một cách tự động.
- Observer có thể đăng ký với hệ thống. Khi hệ thống có sự thay đổi, hệ thống sẽ thông báo cho Observer biết. Khi không cần nữa, mẫu Observer sẽ được gỡ khỏi hệ thống.
- 
- Mô tả cơ chế phân tích:
- Liệt kê các cơ chế phân tích vào 1 danh sách
- Xác định ánh xạ từ lớp phân tích đến cơ chế phân tích
- Xác định đặc điểm của cơ chế phân tích
- Mục đích của phân loại cơ chế phân tích:
- Tinh chỉnh các thông tin thu thập dựa trên cơ chế phân tích
- Các bước phân loại cơ chế phân tích:
* Xác định các lớp client của từng cơ chế phân tích.
* Scan tất cả các client của một cơ chế phân tích nhất định, xem xét các đặc điểm mà họ yêu cầu cho cơ chế đó. Ví dụ: một số đối tượng phân tích có thể sử dụng cơ chế persistence, nhưng yêu cầu của chúng về điều này có thể rất khác nhau: Một lớp có một nghìn phiên bản liên tục có yêu cầu persistence khác biệt đáng kể so với một lớp có bốn triệu trường hợp liên tục. Tương tự, một lớp có phiên bản phải cung cấp phản hồi chưa đến một mili giây đối với dữ liệu phiên bản yêu cầu cách tiếp cận khác với lớp có dữ liệu phiên bản được truy cập thông qua các ứng dụng hàng loạt.
* Xác định các đặc điểm thông tin của từng cơ chế phân tích.
* Có thể có các đặc điểm thông tin khác nhau, cung cấp các mức độ khác nhau về hiệu suất, dấu chân, bảo mật, chi phí kinh tế, v.v. Mỗi cơ chế phân tích là khác nhau - vì vậy các đặc điểm khác nhau sẽ áp dụng cho từng cơ chế. Nhiều cơ chế yêu cầu ước tính số lượng và kích thước của các phiên bản cần quản lý. Sự di chuyển của một lượng lớn dữ liệu thông qua bất kỳ hệ thống nào tạo ra các vấn đề hiệu suất to lớn phải được xử lý.
* Nhóm các lớp khách dựa theo việc sử dụng của các đặc điểm thông tin
* Xác định một cơ chế thiết kế cho các nhóm client dường như chia sẻ nhu cầu về một cơ chế phân tích với một đặc điểm thông tin tương tự. Các nhóm này cung cấp một cắt giảm ban đầu tại các cơ chế thiết kế. Một cơ chế phân tích ví dụ, "giao tiếp giữa các quá trình", có thể ánh xạ vào một cơ chế thiết kế "object request broker". Các cấu hình đặc trưng khác nhau sẽ dẫn đến các cơ chế thiết kế khác nhau xuất hiện từ cùng một cơ chế phân tích. Cơ chế persistence đơn giản trong phân tích sẽ làm phát sinh một số cơ chế persistence trong thiết kế: tính persistence trong bộ nhớ, dựa trên tệp, dựa trên cơ sở dữ liệu, phân phối, v.v.
* Tiến hành từ dưới lên và lập danh sách triển khai các cơ chế có thể có sẵn
### 5. Tài liệu hóa cơ chế kiến trúc:
- Cơ chế thiết kế (Design mechanism) giả thiết một số chi tiết của môi trường thực thi, nhưng không quá gần với một sự cài đặt đặc biệt nào (như cơ chế thực thi).
- Cơ chế thực thi (Implementation mechanisms) được sử dụng trong quá trình cài đặt. Nó là sự làm mịn của cơ chế thiết kế, dùng để đặc tả chính xác sự cài đặt của cơ chế thiết kế. Nó có thể bao gồm một số công nghệ, ngôn ngữ cài đặt,...Một số ví dụ về các cơ chế cài đặt bao gồm ngôn ngữ lập trình, sản phẩm COTS, cơ sở dữ liệu (Oracle, Sybase), các công nghệ phân tán, tương tác giữa các tiến trình (COM/DCOM, CORBA).
- Cơ chế phân tích hệ thống đăng ký khóa học
- Cơ chế lưu trữ bền vững
- Đối với tất cả các lớp có phiên bản có thể trở nên liên tục, ta cần xác định:
- Độ chi tiết: Phạm vi kích thước của các đối tượng cần lưu trữ bền vững?
- Dung lượng: Số lượng đối tượng cần lưu trữ bền vững?
- Thời lượng: Thời gian mà mỗi đối tượng cần được lưu trữ bền vững?
- Cơ chế truy cập: Cách mà một đối tượng cụ thể được nhận diện và truy xuất từ cơ sở dữ liệu?
- Tần suất cập nhật: Liệu các đối tượng có thay đổi thường xuyên hay không? Liệu chúng cần được cập nhật vĩnh viễn hay không?
- Độ tin cậy: Các đối tượng có cần phải tồn tại sau một sự cố của quá trình, bộ xử lý hoặc toàn bộ hệ thống hay không?
- Ví dụ về cơ chế bền vững:
- Một vài slide tiếp theo minh họa mô hình sử dụng cơ chế liên tục được chọn cho các lớp RDBMS trong ví dụ của chúng tôi: JDBC. Sơ đồ trên là chế độ xem tĩnh.
- Đối với JDBC, một máy khách làm việc với DBClass để đọc và ghi dữ liệu liên tục.
- DBClass chịu trách nhiệm truy cập cơ sở dữ liệu JDBC bằng cách sử dụng lớp DriverManager.
- Khi Kết nối cơ sở dữ liệu được mở, DBClass sau đó có thể tạo các câu lệnh SQL sẽ được gửi đến RDBMS cơ bản và được thực thi bằng cách sử dụng lớp Câu lệnh. Tuyên bố là những gì "nói chuyện" với cơ sở dữ liệu.
- Kết quả của truy vấn SQL được trả về trong một đối tượng ResultSet. DBClass là người chịu trách nhiệm làm cho một phiên bản lớp khác liên tục.
- Nó hiểu ánh xạ OO-to-RDBMS và có hành vi giao tiếp với RDBMS. DBClass làm phẳng đối tượng, ghi nó vào RDBMS, đọc dữ liệu đối tượng từ RDBMS và xây dựng đối tượng.
- Mỗi lớp persistency đều có DBClass tương ứng. PersistentClassList được sử dụng để trả về một tập hợp các đối tượng liên tục do truy vấn cơ sở dữ liệu `(ví dụ: DBClass.read()).` `<<role>>` Khuôn mẫu được sử dụng cho bất cứ thứ gì nên được coi là trình giữ chỗ cho yếu tố thiết kế thực tế được cung cấp bởi nhà phát triển. Quy ước này làm cho việc áp dụng cơ chế dễ dàng hơn, bởi vì nó dễ dàng hơn để nhận ra những gì nhà thiết kế phải cung cấp.

## Bài 9: Mô tả kiến trúc thực thi
### 1. Mục tiêu:
- Xác định mục đích của hoạt động Mô tả kiến trúc thực thi và thời điểm hoạt động trong quá trình phát triển.
- Trình bày cách mô hình hóa các tiến trình và luồng.
- Giải thích cách các lớp và hệ thống con nào được ánh xạ đến các tiến trình và luồng.
- Xác định cơ sở lý luận và các cân nhắc mà hỗ trợ các quyết định kiến trúc
### 2. Bối cảnh:
- Trong việc Mô tả Kiến trúc Thực thi, các luồng điều khiển độc lập được xác định, và các yếu tố thiết kế (hệ thống con và lớp) được ánh xạ vào các luồng điều khiển này. Trọng tâm đặt vào Khung nhìn tiến trình của kiến trúc.
- Nếu hệ thống đang được phát triển chỉ cần chạy một tiến trình, thì không cần phải có một Khung nhìn tiến trình riêng biệt. Trong trường hợp như vậy, việc Mô tả Kiến trúc Thực thi có thể được bỏ qua.
### 3. Tổng quan:
- 
- Khái niệm chính: Khung nhìn Tiến trình
- Là một phần quan trọng của về mặt kiến trúc của các tiến trình và luồng trong Mô hình Thiết kế
- Concurrency là gì?
- Ví dụ:
- Đường 1 chiều cần ít sự phối hợp
- Đường 2 chiều cần nhiều sự phối hợp để đảm bảo sự tương tác an toàn
- Đường giao nhau cần sự phối hợp cẩn thận
- Tại sao chúng ta lại quan tâm đến Concurrency?
- Phần mềm có thể cần phải hồi các sự kiện dường như ngẫu nhiên được tạo ra ở bên ngoài
- Thực hiện các tác vụ song song có thể cải thiện hiệu suất nếu có sẵn nhiều CPU
- VD: Khởi động của hệ thống
- Việc điều khiển hệ thống được nâng cao thông qua Concurrency
- Hiện thực hóa Concurrency: Cơ chế Concurrency
- Để hỗ trợ Concurrency, một hệ thống phải cung cấp nhiều luồng điều khiển
- Các cơ chế Concurrency phổ biến:
- Đa tiến trình:
- Nhiều CPU thực thi đồng thời
- Đa tác vụ:
- Các hệ điều hành mô tả hoạt động Concurrency trên một CPU bằng cách xen kẽ việc thực thi các tác vụ với nhau
- Giải pháp dựa trên ứng dụng
- Phần mềm ứng dụng chịu trách nhiệm cho việc thay đổi giữa các nhánh code khác nhau tại những thời điểm phù hợp
- Các bước Mô tả Kiến trúc thực thi
- Phân tích yêu cầu concurrency
- Xác định các tiến trình và luồng
- Xác định các vòng đời tiến trình
- Ánh xạ các tiến trình vào quá trình triển khai
- Phân phối các phần tử mô hình giữa các tiến trình
### 4. Phân tích yêu cầu concurrency
- Các yêu cầu về concurrency được thúc đẩy bởi:
- Mức độ hệ thống phải được phân phối
- Mức độ hệ thống được điều khiển theo sự kiện
- Độ phức tạp tính toán của những thuật toán chính
- Mức độ thực thi song song được hỗ trợ bởi môi trường
- Các yêu cầu về concurrency được xếp hạng theo tầm quan trọng để giải quyết sự xung đột
### 5. Xác định các tiến trình và luồng
- Khái niệm:
- Tiến trình:
- Cung cấp một luồng điều khiển nặng (heavyweight)
- Đứng độc lập
- Có thể chia thành nhiều luồng
- Luồng:
- Cung cấp một luồng điều khiển nhẹ (lightweight)
- Chạy trong bối cảnh của tiến trình tương ứng
- Xác định các tiến trình và luồng:
- Đối với mỗi luồng điều khiển riêng biệt mà hệ thống cần, tạo ra một tiến trình hoặc luồng.
- Các luồng điểu khiển riêng biệt có thể cần thiết để:
- Tận dụng nhiều CPU hoặc các node
- Tăng mức sử dụng CPU
- Phục vụ các sự kiện liên quan đến thời gian
- Ưu tiên các hoạt động
- Có được khả năng mở rộng (load sharing)
- Phân chia các vấn đề trong lĩnh vực phần mềm
- Cải thiện tính sẵn có của hệ thống
- Hỗ trợ các hệ thống con chính
- Mô hình hóa tiến trình:
- Tiến trình có thể được mô hình hóa bằng các sử dụng:
- Các lớp Active (Biểu đồ Lớp) và Các đối tượng (Biểu đồ tương tác)
- Các thành phần (Biểu đồ thành phần)
- Khuôn mẫu: `<<process>>` hoặc `<<thread>>`
- Mối quan hệ của tiến trình có thể được mô hình hóa bằng các sự phụ thuộc
### 6. Xác định vòng đời tiến trình
- Tạo, hủy các tiến trình và luồng
- Kiến trúc đơn tiến trình
- Tạo tiến tình diễn ra khi ứng dụng bắt đầu chạy
- Hủy tiến trình diễn ra khi ứng dụng kết thúc
- Kiến trúc đa tiến trình
- Các tiến trình mới được tạo từ một tiến trình khởi tạo, cái mà được tạo ra khi ứng dụng bắt đầu
- Mỗi tiến trình phải được hủy một cách riêng biệt
### 7. Ánh xạ tiến trình và quá trình triển khai
- Các tiến trình và luồng phải được ánh xạ vào các cấu trúc khiển khai cụ thể
- Các vấn đề cần xem xét:
- Kết nối các tiến trình
- Yêu cầu về hiệu suất
- Giới hạn về tiến trình và luồng của hệ thống
- Các tiến trình và luồng hiện tại
- Tài nguyên IPC sẵn có
### 8. Phân phối các phần tử mô hình giữa các tiến trình
- Phân bố các phần tử thiết kế
- Các thể hiện của một lớp hoặc hệ thống con đã cho phải thực thi trong ít nhất 1 tiến trình
- Chúng có thể thực thi trong vài tiến trình
- Xem xét từ phần tử thiết kế đến tiến trình
- Dựa trên:
- Các yêu cầu về hiệu suất và concurrency
- Các yêu cầu về phân phối và hỗ trợ thực thi song song
- Các yêu cầu về sự dự phòng và tính sẵn có
- Các đặc điểm của lớp/hệ thống con cần xem xét:
- Tự chủ
- Phụ thuộc
- Tính liên tục
- Phân phối
- Các chiến lược ánh xạ: 2 chiến lược (được sử dụng đồng thời)
- Inside-Out
- Nhóm các phần tử hợp tác chặt chẽ với nhau và phải được thực thi trong cùng một luồng điều khiển
- Phân chia các phần tử không tương tác với nhau
- Lặp lại cho đến khi đạt được số tiến trình nhỏ nhất mà vẫn cung cấp khả năng phân phối cần thiết và sử dụng tài nguyên hiệu quả.
- Outside-In
- Xác định một luồng điều khiển riêng cho từng kích thích bên ngoài
- Xác định một server luồng điều khiển riêng cho từng dịch vụ
- Giảm số lượng luồng xuống mức có thể hỗ trợ
- Mô hình hóa Ánh xạ từ Phần tử thành Tiến trình
- Biểu đồ lớp
- Active class là 1 tiến trình
- Từ tiến trình đến lớp là mối quan hệ thành phần
- Từ tiến trình đến hệ thống con là môi quan hệ thành phần
- Mối quan hệ của tiến trình
- Mối quan hệ tiến trình phải hỗ trợ các mối quan hệ của phần tử thiết kế

## Bài 10: Mô tả phân tán
### 1. Mục tiêu
- Giải thích mục tiêu của hoạt động Mô tả phân tán và thời điểm thực hiện trong quá trình phát triển
- Mô tả cách chức năng của hệ thống được phân phối vào các node vật lý
- Mô hình quyết định phân tán hệ thống trong Mô hình triển khai
- Nêu rõ những lý do và cân nhắc mà hỗ trợ cho các quyết định về kiến trúc
### 2. Bối cảnh
- 
### 3. Tổng quan:
- 
- Khái niệm chính: Khung nhìn triển khai
- Là một phần quan trọng về mặt kiến trúc của mô hình triển khai
- Tại sao cần phân tán?
- Giảm tải bộ xử lý
- Yêu cầu xử lý đặc biệt
- Vấn đề về quy mô
- Vấn đề về kinh tế
- Phân quyền truy cập vào hệ thống
- Các mẫu phân tán:
- Client/Server:
- 3 tầng
- Fat Client
- Fat Server
- Phân tán Client/Server
- Peer-to-peer
- Kiến trúc Client/Server:
- 
- Kiến trúc 3 cấp độ:
- 
- Kiến trúc "Fat Client":
- 
- Kiến trúc ứng dụng web:
- 
- Kiến trúc Peer-to-Peer:
- 
- Các bước Mô tả phân tán:
- Xác định cấu hình mạng
- Phân bố tiến trình cho các node
- Xác định cơ chế phân tán
### 4. Xác định cấu hình mạng:
- Cấu hình mạng:
- Các node máy trạm dành cho người dùng cuối
- Các node server xử lý "không đầu"
- Các cấu hình đặc biệt
- Phát triển
- Triển khai
- Các bộ xử lý riêng biệt
- Mạng lưới và khả năng, đặc tính của các bộ xử lý và thiết bị trên mạng xác định tính chất và mức độ phân phối có thể có trong hệ thống. Thông tin sau cần được thu thập:
* Bố trí vật lý của mạng, bao gồm vị trí.
* Các nút trên mạng, cấu hình và khả năng của chúng. Cấu hình bao gồm cả phần cứng và phần mềm được cài đặt trên các nút, số lượng bộ xử lý, dung lượng đĩa, dung lượng bộ nhớ, dung lượng swap, v.v. Phần cứng được cài đặt trên nút có thể được biểu diễn bằng "thiết bị".
* Băng thông của mỗi đoạn trên mạng.
* Sự tồn tại của bất kỳ đường dẫn dự phòng nào trên mạng. (Điều này sẽ giúp cung cấp khả năng chống lỗi.)
- Các phần tử mô hình hóa của Mô hình triển khai
- Node
- Tài nguyên tính toán thời gian chạy vật lý
- Node bộ xử lý
- Thực thi phần mềm hệ thống
- Node thiết bị
- Hỗ trợ thiết bị
- Thông thường được điều khiển bởi bộ xử lý
- Kết nối
- Cơ chế giao tiếp
- Phương tiện vật lý
- Giao thức phần mềm
### 5. Phân bố tiến trình cho các node
- Các vấn đề cần cân nhắc:
- Các mẫu phân tán
- Thời gian phản hồi và thông lượng hệ thống
- Tối thiểu lưu lượng mạng giao nhau
- Dung lượng node
- Băng thông phương tiện giao tiếp
- Phần cứng và các kết nối giao tiếp có sẵn
- Yêu cầu định tuyến lại
### 6. Xác định cơ chế phân tán
- Cơ chế phân tán
- RMI được chọn làm cơ chế cài đặt cho phân tán
- 
- Cơ chế thiết kế: Phân tán: RMI
- Đặc điểm phân tán:
- Độ trễ
- Tính đồng bộ
- Kích thước thông điệp
- Giao thức
- Remote Method Invocation (RMI)
- Cung cấp miễn phí RMI cho từng lớp phân phối
- 
- 
- Các bước kết hợp RMI
- Cung cấp truy cập vào các lớp hỗ trợ RMI
- VD: các giao diện Remote và Serializable, Dịch vụ Đặt tên
- Gói java.rmi và java.io trong tầng Middleware
- Đói với mỗi lớp được phân tán:
- Các controller cần được phân phối trong tầng Ứng dụng
- Cần có phụ thuộc từ Ứng dụng đến tầng Middleware để truy cập các gói java
- Hoãn lại:
- Xác định giao diện cho lớp thực hiện Remote
- Có lớp kế thừa từ UnicastRemoteObject
- Có các lớp dành cho dữ liệu được chuyển đến các đối tượng phân tán thực hiện giao diện Serializable
- Các loại dữ liệu cốt lõi nằm trong tầng Nghiệp vụ
- Cần có sự phụ thuộc từ tầng Nghiệp vụ đến tầng Middleware để truy cập java.rmi
- Thêm các mối quan hệ hiện thực hóa (Hoãn lại)
- Chạy bộ tiền xử lý (Ngoài phạm vi)
- Các client của lớp được phân tán tìm kiếm các đối tượng từ xa bằng cách sử dụng dịch vụ Đặt tên
- Hầu hết các Client của lớp được phân tán là các biểu mẫu (forms)
- Các biểu mẫu nằm trong tầng Ứng dụng
- Cần có sự phụ thuộc từ tầng Ứng dụng đến tầng Middleware để truy cập java.rmi
- Thêm mối quan hệ từ Client của lớp phân tán đến Dịch vụ Đặt tên (Hoãn lại)
- Tạo và cập nhật các biểu đồ tương tác với xử lý phân tán (Hoãn lại)
### 7. Checkpoint:
- Các vấn đề liên quan đến phối hợp và đồng bộ hóa cập nhật dữ liệu phân tán đã được giải quyết và được tài liệu hóa chưa?
- Các dịch vụ đòi hỏi phản hồi nhanh hơn có sẵn cục bộ (LAN so với WAN) chưa?
- Tất cả các vấn đề liên quan đến máy chủ dự phòng đã được giải quyết và được tài liệu hóa (máy chủ chính so với máy chủ phụ)?
- Các chế độ thất bại đã được tài liệu hóa chưa?

## Bài 11: Thiết kế ca sử dụng
### 1. Mục tiêu:
- Xác định mục đích của Thiết kế ca sử dụng và thời điểm chúng hoạt động trong quá trình phát triển
- Xác minh rằng có sự nhất quán trong việc triển khai ca sử dụng
- Tinh chỉnh việc hiện thực hóa ca sử dụng từ Phân tích Ca sử dụng bằng cách sử dụng các phần tử của Mô hình thiết kế
### 2. Bối cảnh:
- 
### 3. Tổng quan:
- 
- Các bước Thiết kế Ca sử dụng
- Mô tả tương tác giữa những đối tượng thiết kế
- Đơn giản hóa biểu đồ tuần tự bằng cách sử dụng hệ thống con
- Mô tả các hành vi liên quan đến lưu trữ lâu dài
- Tinh chỉnh mô tả luồng sự kiện
- Hợp nhất các lớp và hệ thống con
### 4. Mô tả tương tác giữa những đối tượng thiết kế
- Nhắc lại: Hiện thực hóa ca sử dụng
- 
- Nhắc lại: Từ Lớp phân tích đến Phần tử thiết kế
- 
- Tinh chỉnh hiện thực hóa ca sử dụng:
- Xác định các đối tượng tham gia
- Phân bổ trách nhiệm giữa các đối tượng
- Mô hình hóa các thông điệp giữa các đối tượng
- Mô tả kết quả của tiến trình từ thông điệp
- Mô hình hóa mối quan hệ của lớp liên quan
- 
- Các bước tinh chỉnh hiện thực hóa ca sử dụng
- Xác định mỗi đối tượng tham gia vào trong luồng sự kiện của ca sử dụng
- Biểu diễn từng đối tượng tham gia trong biểu đồ tuần tự
- Dần dần kết hợp các cơ chế kiến trúc có thể áp dụng
- Biểu diễn hệ thống con trong biểu đồ tuần tự
- Giao diện:
- Đại diện cho bất kỳ phần tử mô hình nào hiện thực hóa giao diện
- Không thông điệp nào được vẽ từ giao diện
- 
- Lớp Proxy:
- Đại diện cho một hệ thống con cụ thể
- Thông điệp có thể vẽ được từ Proxy
- 
- Kết hợp các cơ chế kiến trúc:
- Bảo mật:
- Ánh xa Lớp phân tích đến cơ chế kiến trúc từ Phân tích ca sử dụng
- 
- Phân tán:
- Ánh xa Lớp phân tích đến cơ chế kiến trúc từ Phân tích ca sử dụng
- 
- Nhắc lại: Các bước kết hợp RMI:
- 
- 
- 
### 5. Đơn giản hóa biểu đồ tuần tự bằng cách sử dụng hệ thống con
- Đóng gói các tương tác của hệ thống con
- Các tương tác có thể được mô tả tại nhiều cấp độ khác nhau
- Các tương tác của hệ thống con có thể được mô tả trong chính biểu đồ tuần tự của chúng.
- 
- Thời điểm đóng gói luồng con vào trong hệ thống con:
- Đóng gói một luồng con khi nó:
- Xảy ra trong nhiều hiện thực hóa ca sử dụng
- Có tiềm năng tái sử dụng
- Phức tạp và dễ đóng gói
- Là trách nhiệm của một người hoặc nhóm
- Tạo ra kết quả được xác định rõ ràng
- Được đóng gói trong thành phần mô hình triển khai duy nhất
- Hướng dẫn: Đóng gói tương tác hệ thống con
- Hệ thống con nên được thể hiện bởi các giao diện của nó trong biểu đồ tương tác
- Các thông điệp đến hệ thống con được mô hình hóa dưới dạng thông điệp tới giao diện hệ thống con
- Các thông điệp đến hệ thống con tương ứng với các hoạt động của giao diện hệ thống con
- Tương tác giữa các hệ thống con được mô hình hóa trong Thiết kế Hệ thống con
- Lợi ích của việc đóng gói tương tác hệ thống con
- Hiện thực hóa ca sử dụng:
- Ít lộn xộn hơn
- Có thể được tạo ra trước khi thiết kế bên trong của hệ thống con được tạo ra (phát triển song song)
- Tổng quát hơn và dễ dàng thay đổi hơn (Hệ thống con có thể được thay thế)
- Phát triển hệ thống con song song
- Tập trung vào các yêu cầu ảnh hướng đến giao diện hệ thống con
- Phác thảo các giao diện cần thiết
- Mô hình hóa thông điệp mà bao quanh biên hệ thống con
- Vẽ biểu đồ tương tác về giao diện hệ thống con cho từng ca sử dụng
- Tinh chỉnh các giao diện cần thiết để cung cấp thông điệp
- Phát triển song song hệ thống con
- Sử dụng giao diện hệ thống con làm điểm đồng bộ hóa
### 6. Mô tả hành vi liên quan đến lưu trữ lâu dài
- Mô tả hành vi liên quan đến lưu trữ lâu dài
- Mô hình hóa các giao dịch
- Ghi các đối tượng lưu trữ lâu dài
- Đọc các đối tượng lưu trữ lâu dài
- Xóa các đối tượng lưu trữ lâu dài
- Mô hình hóa các giao dịch
- Giao dịch là gì?
- Atomic operation invocations
- "Tất cả hoặc không có gì"
- Cung cấp sự lưu trữ lâu dài
- Tùy chọn lập mô hình
- Văn bản (script)
- Thông điệp rõ ràng
- Điều kiện lỗi
- Rollback
- Failure modes
- Có thể cần chia thành các biểu đồ tương tác
- Kết hợp các cơ chế kiến trúc: Lưu trữ lâu dài
- Ánh xa Lớp phân tích đến cơ chế kiến trúc từ Phân tích ca sử dụng
- 
### 7. Tinh chỉnh mô tả luồng sự kiện
- Chú thích biểu đồ tương tác:
- Script: Được sử dụng để mô tả chi tiết về những thông điệp
- Note: Gồm nhiều thông tin về một phần tử cụ thể của biểu đồ
- 
### 8. Hợp nhất các lớp và hệ thống con
- Xem xét hợp nhất mô hình thiết kế
- Tên các phần tử mô hình nên mô tả chức năng của chúng
- Gộp các phần tử mô hình giống nhau
- Sử dụng kế thừa trong phần tử mô hình trừu tượng
- Giữ các thành phần mô hình và luồng sự kiện nhất quán
### 9. Checkpoint: Thiết kế ca sử dụng
- Phân chia gói/thành phần hệ thống có hợp lý và nhất quán không?
- Tên của các gói/thành phần có mô tả được không?
- Các lớp gói public và giao diện hệ thống có cung cấp một tập hợp dịch vụ duy nhất, logic và nhất quán không?
- Các phụ thuộc gói/thành phần có tương ứng với các mối quan hệ giữa các lớp chứa nó không?
- Các lớp chứa trong một gói có thuộc về đúng nơi theo tiêu chí phân chia gói không?
- Có các lớp hoặc hợp tác giữa các lớp có thể được tách thành gói/thành phần độc lập không?
- Tất cả các luồng chính và/hoặc con của vòng lặp này đã được xử lý chưa?
- Tất cả hành vi đã được phân phối trong các yếu tố thiết kế tham gia chưa?
- Hành vi đã được phân phối cho các yếu tố thiết kế phù hợp chưa?
- Nếu có nhiều biểu đồ tương tác cho thực hiện use-case, liệu có dễ hiểu biết được biểu đồ hợp tác nào liên quan đến luồng sự kiện nào không?
## Bài 12: Thiết kế hệ thống con
### 1. Mục tiêu:
- Mô tả mục đích của Thiết kế hệ thống con và nơi nó được thực hiện trong quá trình phát triển
- Xác định các hành vi được chỉ định trong các giao diện của hệ thống con về mặt cộng tác của lớp được chứa
- Ghi lại cấu trúc bên trong của hệ thống con
- Xác định các sự phụ thuộc và các thành phần bên ngoài của hệ thống con
### 2. Bối cảnh:
- 
### 3. Tổng quan:
- 
- Nhắc lại: Hệ thống con và giao diện:
- Hệ thống con:
- Là một kết hợp giữa một gói và một lớp
- Hiện thực hóa một hoặc nhiều giao diện là xác định hành vi của nó
- Nguyên tắc hệ thống con:
- Mục tiêu:
- Kết nối lỏng lẻo
- Tính di động, khả năng tương thích plug-and-play
- Ngăn cách khỏi sự thay đổi
- Phát triển độc lập
- Gợi lý:
- Không để lộ chi tiết, chỉ giao diện
- Chỉ phụ thuộc vào các giao diện khác
- Key ở đây là đóng gói và trừu tượng
- Nhắc lại: Quy ước mô hình hóa cho hệ thống con và giao diện
- Giao diện ở bên ngoài hệ thống con
- 
- Các bước thiết kế hệ thống con
- Phân phối các hành vi của hệ thống con vào các phần tử hệ thống con
- Tài liệu hóa các phần tử hệ thống con
- Mô tả các phụ thuộc của hệ thống con
- Checkpoint
### 4. Phân phối các hành vi của hệ thống con vào các phần tử hệ thống con
- Trách nhiệm của hệ thống con
- Trách nhiệm của hệ thống con được xác định bởi hoạt động của giao diện
- Mô hình hiện thực hóa giao diện
- Các hoạt động của giao diện có thể được hiện thực hóa bởi:
- Các hoạt động của lớp bên trong
- Các hoạt động của hệ thống con bên trong
- Phân phối trách nhiệm của hệ thống con
- Xác định các thành phần thiết kế mới, hoặc tái sử dụng (VD: các lớp hoặc/và hệ thống con)
- Phân bổ trách nhiệm của hệ thống con vào phần tử thiết kế
- Kết hợp các cơ chế áp dụng (VD: lưu trữ lâu dài, phân tán)
- Tài liệu hóa các sự cộng tác phần tử thiết kế trong "hiện thực hóa giao diện"
- Một hoặc nhiều biểu đồ tương tác mỗi một hành động của giao diện
- (Các) biểu đồ lớp chứa các mối quan hệ phần tử thiết kế được yêu cầu
- Xem lại "Xác định các phần tử thiết kế"
- Điều chỉnh biên của hệ thống con và các phụ thuộc nếu cầu
- Quy ước mô hình: Biểu đồ tương tác hệ thống con
- 
- Kết hợp các cơ chế kiến trúc: Lưu trữ lâu dài
- Ánh xa Lớp phân tích đến cơ chế kiến trúc từ Phân tích ca sử dụng
- 
- Nhắc lại: Các bước kết hợp JDBC:
- 
- 
### 5. Tài liệu hóa các phần tử hệ thống con
### 6. Mô tả sự phụ thuộc của hệ thống con
- Hướng dẫn:
- Hệ thống con phụ thuộc vào hệ thống con
- 
- Hệ thống con phụ thuộc vào 1 gói
- 
### 7. Checkpoint:
- Mối liên kết hiện thực hóa có được xác định cho từng giao diện do hệ thống con cung cấp không?
- Liên kết phụ thuộc có được xác định cho từng giao diện được hệ thống con sử dụng không?
- Bạn chắc chắn rằng không có một phần tử nào trong hệ thống con có khả năng nhìn thấy public không?
- Mỗi hoạt động trên một giao diện được thực hiện bởi hệ thống con có được tài liệu hóa trong một biểu đồ tương tác không? Nếu không, liệu hoạt động có được thực hiện bởi một lớp duy nhất, để dễ nhìn thấy rằng có một phép ánh xạ đơn giản 1:1 giữa hoạt động của lớp và hoạt động của giao diện không?

## Bài 13: Thiết kế lớp
### 1. Mục tiêu:
- Xác định mục tiêu của Thiết kế lớp và nơi chúng thực hiện trong vòng đời
- Xác định các lớp và mối quan hệ bổ sung cần thiết để hỗ trợ thực hiện các cơ chế đã chọn
- Xác định và phân tích các chuyển đổi trạng thái trong đối tượng của các lớp điều khiển trạng thái
- Tinh chỉnh các mối quan hệ, hành động và thuộc tính
### 2. Bối cảnh:
- 
### 3. Tổng quan:
- 
- Các bước thiết kế lớp:
- Tạo các lớp thiết kế ban đầu
- Xác định các hành động
- Xác định các phương thức
- Xác định các trạng thái
- Xác định các thuộc tính
- Xác định sự phụ thuộc
- Xác định sự liên kết (association)
- Xác định sự tổng quát hóa
- Giải quyết các xung đột ca sử dụng
- Xử lý các yêu cầu phi chức năng nói chung
- Checkpoints
### 4. Tạo các lớp thiết kế ban đầu
- Các cân nhắc khi thiết kế lớp:
- Khuôn mẫu của lớp
- Lớp biên
- Lớp thực thế
- Lớp điều khiển
- Các mẫu thiết kế có thể áp dụng
- Cơ chế kiến trúc
- Lưu trữ lâu dài
- Phân tán
- Cần tạo ra bao nhiêu lớp?
- Nhiều lớp đơn giản có nghĩa là mỗi lớp:
- Đóng gói ít logic tổng thể của hệ thống
- Được tái sử dụng nhiều hơn
- Dễ để triển khai
- Ít lớp phức tạp có nghĩa là mỗi lớp:
- Đóng gói phần lớp logic tổng thể của hệ thống
- Ít được tái sử dụng
- Khó để triển khai
- Một lớp nên tập trung vào một mục đích duy nhất. Một lớp chỉ nên làm một việc và làm tốt việc đó
- Chiến lược thiết kế các lớp biên:
- Lớp biên UI:
- Những cộng cụ phát triển UI nào sẽ được sử dụng?
- Công cụ phát triển có thể tạo ra được bao nhiêu giao diện?
- Lớp biên giao diện hệ thống ngoài:
- Thường mô hình hóa như hệ thống con
- Chiến lược thíết kế các lớp thực thể:
- Các đối tượng thực thể thường thụ động và lưu trữ lâu dài
- Yêu cầu về hiệu suất có thể buộc phải tính toán lại
- Xem bước Xác định các lớp lưu trữ lâu dài
- Chiến lược thíết kế các lớp điều khiển:
- Điều gì xảy ra với lớp điều khiển:
- Chúng có thực sự cần thiết?
- Có nên tách chúng ra không?
- Xác định dựa trên:
- Độ phức tạp
- Xác suất thay đổi
- Phân tán và hiệu suất
- Quản lý giao dịch
### 5. Xác định các hoạt động:
- Tìm các hoạt động ở đâu:
- Trong các thông điệp ở các biểu đồ tương tác
- Chức năng phụ thuộc vào cách triển khai khác:
- Chức năng quản lý
- Cần cho các bản sao của lớp
- Cần cho sự kiểm tra ngang bằng
- Tên và mô tả hoạt động:
- Tạo tên hoạt động phù hợp
- Chỉ ra kết quả
- Sử dụng bối cảnh của máy khách
- Nhất quán giữa các lớp
- Xác định đặc điểm của hành động
- `operationName([direction]parameter:class,..):returnType`
- Direction có thể in, out, hoặc inout và có giá trị defaultt là in nếu không có nó
- Cung cấp một mô tả ngắn gọn, bao gồm ý nghĩa của từng tham số
- Hướng dẫn: Xác định đặc điểm của hoạt động
- Khi thiết kế đặc điểm của hoạt động, xem xét liệu các tham số có:
- Được truyền theo giá trị hay tham chiếu
- Bị thay đổi bởi hoạt động
- Không bắt buộc
- Được đặt giá trị ban đầu
- Nằm trong phạm vi tham số hợp lệ
- Càng ít tham số càng tốt
- Truyền đối tượng thay vì "data bits"
- Operation Visibility
- Được dùng để đóng gói
- Có thể là public, protected hoặc private
- Cách ghi chú Visibility
- Các ký hiệu được sử dụng:
- `+` Public access
- `#` Protected access
- `-` Private access
- Phạm vi:
- Xác định số thể hiện của thuộc tính/hành vi
- Instance: Một instance cho mỗi thể hiện của lớp
- Classifier: Một instance cho tất cả thể hiện của lớp
- Phạm vị phân loại được biểu thị bằng cách gạch chân ở tên thuộc tính, hành vi
### 6. Xác định phương thức
- Xác định phương thức:
- Phương thức là gì?
- Mô tả việc thực thi hành động
- Mục đích:
- Xác định các khía cạnh đặc biệt của việc thực thi hành động
- Những thứ cần xem xét:
- Thuật toán đặc biệt
- Các đối tượng và hành động sẽ được sử dụng
- Cách các thuộc tính và tham số được triển khai và được sử dụng
- Cách các mối quan hệ được triển khai và sử dụng
### 7. Xác định trạng thái
- Xác định trạng thái
- Mục đích
- Xác định các một trạng thái của đối tượng ảnh hướng đến hành vi của nó
- Phát triển mô hình trạng thái để mô hình hóa hành vi này
- Những thứ cần xem xét
- Những đối tượng nào có trạng thái lớn
- Cách xác định một trạng thái có thể của đối tượng
- Cách mô hình trạng thái ánh xạ đến phần còn lại của mô hình
- Mô hình trạng thái là gì?
- Một đồ thị có hướng của trạng thái (node) được nối bởi các chuyển tiếp (các cung có hướng)
- Mô tả một lịch sử hành động của mối đối tượng phản ứng
- Các trạng thái đặc biệt:
- Trạng thái khởi đầu:
- Là trạng thái khi một đối tượng được tạo
- Bắt buộc
- Chỉ có duy nhất một trạng thái khởi đầu
- Trạng thái kết thúc:
- Chỉ ra nơi kết thúc hoạt động của đối tượng
- Không bắt buộc
- Có thể có nhiều hơn một
- Xác định và định nghĩa trạng thái
- Các thuộc tính động, quan trọng
- Sự tồn tại và không tồn tại của một số liên kết nhất định
- Xác định các sự kiện
- Nhìn vào các hoạt động giao diện lớp
- Xác định chuyển trạng thái
- Với mỗi trạng thái. xác định sự kiện nào gây ra sự chuyển trạng thái đến trạng thái nào, bao gồm các điều kiện khi cần
- Sự chuyển trạng thái mô tả những gì diễn ra để đáp lại việc nhận một sự kiện
- Thêm các activity và action:
- Activities
- Được liên kết với một trạng thái
- Bắt đầu khi trạng thái được nhập vào
- Mất thời gian đề hoàn thành
- Gián đoạn
- Actions
- Được liên kết với chuyển trạng thái
- Mất một thời gian không đáng kể để hoàn thành
- Không gián đoạn
- Đối tượng nào có trạng thái quan trọng?
- Các đối tượng mà có role được xác định bởi chuyển trạng thái
- Những ca sử dụng phức tạp được điều khiển trạng thái
- Không cần cho những đối tượng mô hình như:
- Các đối tượng ánh xạ thẳng đến việc triển khai
- Đối tượng không có điều khiển trạng thái
- Đối tượng chỉ có một trạng thái tính toán
- Cách mô hình trạng thái ánh xạ đến phần còn lại của mô hình
- Các sự kiện có thể ánh xạ đến các hành động
- Các phức thức nên được cập nhật với thông tin cụ thể của trạng thái
- Các trạng thái thường được biểu diễn bằng thuộc tính
- Làm đầu vào cho bước "Xác định thuộc tính"
### 8. Xác định thuộc tính
- Cách tìm chúng
- Kiểm tra các mô tả phương thức
- Kiểm tra các trạng thái
- Kiểm tra bất kỳ thông tin mà lớp đó cần duy trì
- Biểu diễn thuộc tính
- Chỉ định tên, loại và giá trị mặc định (tùy chọn)
- attributeName : Type = Default
- Thực hiện theo các quy ước đặt tên khi triển khai ngôn ngữ và dự án
- Kiểu phải là kiểu dữ liệu cơ bản trong ngôn ngữ thực hiện
- Kiểu dữ liệu có sẵn, kiểu dữ liệu do người dùng định nghĩa, hoặc lớp do người dùng định nghĩa
- Chỉ định khả năng hiển thị
- Public: +
- Private: -
- Protected: #
- Thuộc tinhs derived
- Khái niệm:
- Là một thuộc tính mà giá trị của nó có thể được tính toán dựa trên giá trị của các thuộc tính khác
- Thời điểm sử dụng:
- Khi không đủ thời gian để tính toán giá trị mỗi khi cần
- Khi đánh đổi giữa hiệu suất thực thi với yêu cầu về bộ nhớ
### 9. Xác định sự phụ thuộc
- Xác định sự phụ thuộc
- Sự phụ thuộc là gì?
- Là mối quan hệ giữa hai thực thể
- Mục đích:
- Xác định nơi mà không cần mối quan hệ kiến trúc
- Thứ cần tìm kiếm:
- Cái gì làm cho supplier được client nhìn thấy
- Phụ thuộc vs Kết hợp:
- Thụ nạp là mối quan hệ kiến trúc
- Phụ thuộc là mối quan hệ phi kiến trúc
- Để các đối tượng biết đến nhau, chúng phải được nhìn thấy
- Tham chiếu biến cục bộ
- Tham chiếu tham số
- Tham chiếu toàn cục
- Tham chiếu lĩnh vực
- Kết hợp vs Phụ thuộc trong Cộng tác
- Một thể hiện của thu nạp là một liên kết
- Tất cả các liên kết đều trở thành thu nạp trừ khi chúng có khả năng hiển thị toàn cục, cục bộ hoặc tham số
- Mối quan hệ phụ thuộc vào ngữ cảnh
- Phụ thuộc là dạng liên kết tạm thời với:
- Giới hạn thời gian
- Mối quan hệ dộc lập với ngữ cảnh
- Mối quan hệ tóm tắt
- Một phụ thuộc là mối quan hệ thứ cấp vì chúng không cung cấp nhiều về mối quan hệ. Để biết chi tiết, cần phải tham khảo biểu đồ cộng tác
- Khả năng hiển thị biến cục bộ:
- op1() chứa một biến cục bộ loại ClassBư
- Khả năng hiển thị tham số:
- Thể hiện của ClassB được chuyển đến thể hiện của ClassA
- Khả năng hiển thị toàn cục:
- Thể hiện của ClassUtility hiển thị vì nó là toàn cục
- Xem xét việc xác định phụ thuộc:
- Mối quan hệ vĩnh viễn - Kết hợp (khả năng hiển thị lĩnh vực)
- Mối quan hệ tạm thời - Phụ thuộc
- Nhiều đối tượng chia sẽ cùng 1 thể hiển
- Truyền thể hiện dưới dạng tham số (khả năng hiển thị tham số)
- Làm thể hiện thành toàn cục được quản lý (khả năng hiển thị toàn cục)
- Nhiều đối tượng không chia sẻ cùng một thể hiển (khả năng hiển thị cục bộ)
- Mất bao lâu để tạo/hủy?
- Đắt đỏ? Sử dụng khả năng hiển thị lĩnh vực, tham số hoặc toàn cục
- Cố làm các mối quan hệ nhẹ nhàng, đón giản nhất có thể
### 10. Xác định kết hợp
- Xác định kết hợp:
- Mục đích
- Xác định các kết hợp còn lại
- Các thứ cần tìm kiếm:
- Kết hợp vs Tổng hợp
- Tổng hợp vs Thành phần
- Thuộc tính vs Kết hợp
- Khả năng điều hướng
- Thiết kế lớp kết hợp
- Thiết kế đa bội
- Thành phần là gì?
- Một dạng của mối quan hệ tổng hợp với quyền sở hữu mạnh và thời gian tồn tại trùng nhau
- Các phần không thể tồn tại trong tổng thể/tổng hợp
- Tổng hợp: Shared vs Non-shared
- 
- Tổng hợp hay Thành phần?
- Xem xét:
- Thời gian sống của Class1 và Class2
- Thuộc tính vs Thành phần
- Sử dụng thành phần khi
- Thuộc tính cần xác định độc lập
- Nhiều lớp có cùng thuộc tính
- Thuộc tính có cấu trúc phức tạp và thuộc tính riêng
- Các thuộc tính có hành vi phức tạp của riêng chúng
- Các thuộc tính có mối quan hệ riêng
- Ngược lại sử dụng thuộc tính
- Nhắc lại: Khả năng điều hướng là gì?
- Chỉ ra rằng có thể điều hướng từ một lớp kết hợp đến lớp mục tiêu bằng cách sử dụng kết hợp
- Khả năng điều hướng: Hướng nào thực sự cần thiết?
- Khám phá biểu đồ tương tác
- Ngay cả khi cả hai hướng đều có vẻ cần thiết, một hướng có thể làm việc
- Khả năng điều hướng theo một hướng là không thường xuyên
- Số lượng thể hiện của một lớp nhỏ
- Lớp kết hợp
- Một lớp được gán với một kết hợp
- Chứa các thuộc tính của mối quan hệ
- Có một thể hiện mỗi liên kết
- Thiết kế đa bội
- Đa bội = 1 hoặc Đa bội = 0..1
- Có thể được thực hiện trực tiếp bằng một giá trị hoặc con trỏ đơn giản
- Không cần “thiết kế” thêm
- Bội > 1
- Không thể sử dụng một giá trị hoặc con trỏ đơn giản
- Có thể cần thêm “thiết kế”
- Lớp tham số hóa (template) là gì?
- Một định nghĩa lớp xác định các lớp khác
- Thường được sử dụng cho các lớp container
- Một số lớp container thông dụng:
- Sets, lists, dictionaries, stacks, queues
- Thiết kế bội: Tùy chọn
- Nếu một liên kết là không bắt buộc, hãy đảm bảo bao gồm một thao tác để kiểm tra sự tồn tại của liên kết
### 11. Xác định tổng quát
- Nhắc lại: Tổng quát
- 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
- Là một loại quan hệ
- Trong Phân tích, sử dụng một cách tiết kiệm
- Lớp trừu tượng và cụ thể
- Lớp trừu tượng không thể có bất kỳ đối tượng nào
- Các lớp cụ thể có thể có các đối tượng
- Vấn đề đa kế thừa
- Việc giải quyết những vấn đề này phụ thuộc vào việc triển khai
- Ràng buộc tổng quát hóa
- Hoàn thành
- Kết thúc cây thừa kế
- Chưa hoàn thiện
- Cây kế thừa có thể được mở rộng
- Rời rạc
- Các lớp con loại trừ lẫn nhau
- Không hỗ trợ đa kế thừa
- Chồng chéo
- Các lớp con không loại trừ lẫn nhau
- Hỗ trợ đa kế thừa
- Tổng quát vs Tổng hợp
- Thường gây nhầm lẫn
- Tổng quát đại diện cho mối quan hệ "là một" hoặc "một loại của"
- Tổng hợp đại diện cho mối quan hệ "một phần của"
- Tổng quát hóa: Chia sẻ các thuộc tính và hành vi chung
- Tuân theo phong cách lập trình “là một”
- Khả năng thay thế lớp
- Tổng quát hóa: Chia sẻ Triển khai: Phân tách
- Hỗ trợ tái sử dụng phần triển khai của một lớp khác
- Không thể sử dụng nếu lớp bạn muốn “tái sử dụng” không thể thay đổi
- Tổng quát hóa thay thế: Chia sẻ Triển khai: Ủy quyền
- Hỗ trợ tái sử dụng phần triển khai của một lớp khác
- Có thể sử dụng nếu lớp bạn muốn "tái sử dụng" không thể thay đổi
- Kế thừa Triển khai
- Các thao tác public, thuộc tính và mối quan hệ của lớp tổ tiên KHÔNG hiển thị cho clỉent của các phiên bản lớp con
- Lớp con phải định nghĩa tất cả các truy cập đến các thao tác, thuộc tính và mối quan hệ của lớp tổ tiên
- Nhắc lại: Đa hình là gì?
- Là khả năng ẩn nhiều cách triển khai khác nhau dưới một giao diện duy nhất
- Khái quát hóa: Triển khai đa hình
- Đa hình: Sử dụng Giao diện so với Tổng quát hóa
- Giao diện hỗ trợ biểu diễn đa hình độc lập với triển khai
- Mối quan hệ hiện thực hóa có thể vượt qua các hệ thống phân cấp tổng quát hóa
- Giao diện là các đặc tả thuần túy, không có hành vi
- Lớp cơ sở trừu tượng có thể định nghĩa các thuộc tính và mối quan hệ
- Giao diện hoàn toàn độc lập với kế thừa
- Tổng quát hóa được sử dụng để tái sử dụng các triển khai
- Giao diện được sử dụng để tái sử dụng các đặc tả hành vi
- Tổng quát hóa cung cấp một cách để triển khai đa hình
- Thiết kế quyết định Đa hình thông qua Tổng quát hóa
- Chỉ cung cấp giao diện cho các lớp con?
- Thiết kế lớp tổ tiên là lớp trừu tượng
- Tất cả các phương thức được cung cấp bởi các lớp con
- Cung cấp giao diện và hành vi mặc định cho các lớp con?
- Thiết kế lớp tổ tiên là lớp cụ thể với phương thức mặc định
- Cho phép các thao tác đa hình
- Cung cấp giao diện và hành vi bắt buộc cho các lớp con?
- Thiết kế lớp tổ tiên là lớp cụ thể
- Không cho phép các thao tác đa hình
- Biến hình là gì?
- Biến hình
- Sự thay đổi về hình thức, cấu trúc, hoặc chức năng; cụ thể là sự thay đổi về mặt thể chất mà một số loài động vật trải qua, như từ nòng nọc thành ếch.
- Bất kỳ sự thay đổi rõ rệt nào, như về tính cách, ngoại hình, hoặc tình trạng.
- Biến hình tồn tại trong thế giới thực. Vậy nên được mô hình hóa như thế nào?
- Mô hình hóa Biến hình:
- Cách tiếp cận đầu tiên:
- Một mối quan hệ tổng quát có thể được tạo ra
- Cách tiếp cận khác
- Kế thừa có thể được sử dụng để mô hình hóa cấu trúc, hành vi, và/hoặc mối quan hệ chung đối với các phần "thay đổi".
- Biến hình được thực hiện khi đối tượng "giao tiếp" với các phần thay đổi.
- Biến hình và linh hoạt
- Kỹ thuật này cũng tăng thêm tính linh hoạt của mô hình
### 11. Giải quyết các xung đột ca sử dụng
- Giải quyết Va chạm Các Ca Sử Dụng
- Nhiều ca sử dụng có thể đồng thời truy cập vào các đối tượng thiết kế
- Các tùy chọn
- Sử dụng tin nhắn đồng bộ => xử lý theo thứ tự người đến trước được phục vụ trước
- Xác định các thao tác (hoặc mã) cần bảo vệ
- Áp dụng các cơ chế kiểm soát truy cập
- Hàng đợi tin nhắn
- Semaphores (hoặc “tokens”)
- Các cơ chế khóa khác
- Giải quyết va chạm phụ thuộc nhiều vào môi trường triển khai
### 12. Xử lý yêu cầu phi chức năng nói chung
- 
### 13. Checkpoints
- Lớp
- Tên lớp rõ ràng
- Một sự trừu tượng hóa được định nghĩa rõ ràng
- Các thuộc tính/hành vi kết hợp chặt chẽ về mặt chức năng
- Đã tạo các tổng quát hóa
- Tất cả các yêu cầu của lớp đều được giải quyết
- Các yêu cầu phù hợp với các sơ đồ trạng thái
- Chu kỳ sống của phiên bản lớp được mô tả đầy đủ
- Lớp có hành vi cần thiết
- Phương thức
- Các phương thức dễ hiểu
- Mô tả trạng thái chính xác
- Hành vi cần thiết được cung cấp
- Các tham số được định nghĩa chính xác
- Các tin nhắn hoàn toàn gán cho các phương thức
- Các đặc tả triển khai là chính xác
- Chữ ký tuân theo các tiêu chuẩn
- Tất cả các phương thức đều cần thiết cho việc Hiện thực hóa Ca Sử dụng
- Thuộc tính
- Một khái niệm duy nhất
- Tên mô tả
- Tất cả các thuộc tính đều cần thiết cho việc Hiện thực hóa Ca Sử dụng
- Quan hệ
- Có tên mang tính miêu tả vai trò
- Đa bội đúng