Phân tích và thiết kế hệ thống phần mềm hướng đối tượng
MỤC LỤC
Khái niệm cơ bản về mô hình hướng đối tượng 1. Đối tượng
Hãy quan sát và viết ra những gì nhìn thấy được, chúng ta có thể thấy rằng, chiếc đèn bàn có thể có 2 trạng thái: bật (on) và tắt (off), có 2 hành vi bật đèn (turn on) và tắt đèn (turn off), nhưng chiếc radio có thể có thêm các trạng thái: bật (on), tắt (off), âm lượng hiện tại (current volume), kênh hiện tại (current station) và hành vi bật đài (turn on), tắt đài (turn off), tăng âm thanh (increase volume), giảm âm thanh (decrease volume), tim kênh (seek), dò kênh (scan), và chỉnh sóng (ture). Chuyển các trạng thái vào thuộc tỉnh của đối tượng (tốc độ hiện tại (current speed), nhịp bàn đạp hiện tại (current pedal cadence), và trạng thái líp hiện tại (current gear)) và cung cấp các phương thức để thay đổi các trạng thái, đối tượng bảy giờ đã được sẵn sàng sử dụng bởi các đối tượng bên ngoài.
NGễN NGỮ Mễ HèNH HểA UML
Giới thiệu
Để sử dụng UML có hiệu quả, nhìn chung, người mô hình hóa phải nắm được ba vấn đề: các phần tử cơ bản của mô hình UML, các quy tắc (luật) liên kết các phần tử mô hình, và một số cơ chế chung áp dụng cho ngôn ngữ. Ký pháp đồ họa cho quan hệ kết hợp, như minh họa trong Hình 2.11, là đoạn thẳng có thể có hướng, thường có nhân là tên quan hệ, và chứa thông tin về lực lượng quan hệ (multiplicity) cũng như các vai trò tham gia quan hệ (roles).
Biểu đồ ca sử dụng
Biểu đồ ca sử dụng cho phép chúng ta xác định được khung cảnh của hệ thống, làm rừ biờn của hệ thống (gồm những thứ tồn tại bờn trong hệ thống) và mụi trường (những thứ tồn tại bờn ngoài thống và tương tỏc với hệ thống). - Để xác định các tác nhân bên ngoài hệ thống chúng ta xác định (1) các nhóm cần được trợ giúp từ hệ thống để thực hiện công việc của chúng; (2) các nhóm cần cho việc thực thi chức năng của hệ thống: (3) các nhóm tương tác với các phần tử hệ thống như các phần cứng bên ngoài hay các phần mềm hệ thống khác; và (4) các nhóm thực hiện các chức năng bổ sung cho việc quản trị và vận hành hệ thống.
Các biểu đồ tương tác
- Bắt đầu với thông điệp khởi tạo tương tác, tiếp đó biểu diễn các thông điệp kế tiếp từ trờn xuống dưới giữa cỏc đường chu kỳ sống, chỉ rừ cỏc thuộc tỉnh thông điệp (chẳng hạn đưa vào danh sách tham số), và nếu cần giải thích thêm nghĩa của tương tác. Nếu giá trị thuộc tính, giá trị chú thích (tagged values), trạng thái và vai trò của đối tượng thay đổi đáng kể trong quá trình tương tác, chúng ta tạo lập đối tượng đó trên biểu đồ, cập nhật chúng với các giá trị mới và kết nối chúng bằng thông điệp với kiểu mở rộng (stereotype) là <<become>> hay <<copy>>, cùng với số thứ tự thông điệp phù hợp.
Biểu đồ lớp
Lớp tái hiện một khái niệm rời rạc trong ứng dụng được sử dụng để biểu diễn sự vật theo một loại nào đóc sự vật vật lý (như máy bay), sự vật nghiệp vụ (như phiếu đặt vẽ), sự vật login (như lịch trình bay), sự vật trong miền máy tính (như bảng băm) hoặc sự vật hành vi (như một công việc). Thông tin về kết hợp chủ gọi yếu được biểu diễn ở các mẫu kết hợp, gồm có tên vai trò (rolnames), lực lượng kết hợp (multiplicity), và phạm vi truy cập (visibility), như minh họa trong Hình 2.21.
Biểu đồ trạng thái
Một trạng thái có thể được mô tả trong ba cách khác nhau, bỗ trợ cho nhau: (1) Trạng thái là một tập các giá trị đối tượng, ở khía cạnh nào đó, tương tự nhau về mặt định tính;. (2) Trạng thái là giai đoạn thời gian mà đối tượng chờ một vài sự kiện nào đó diễn ra và (3) Trạng thái là giai đoạn thời gian mà đối tượng đang thực thi một hoạt động nào đó.
Biểu đồ hoạt động
Với kỹ thuật này, mô hình hóa các trạng thái rẽ nhánh, phân tách và hợp nhất điều khiển (fork/join) là đặc biệt quan trọng, Khung cảnh cho biểu đổ hoạt động trong trường hợp này liên quan đến các tham số thao tác và các biến địa phương của nó. - Bắt đầu với trạng thái khởi đầu của thao tác, đặc tả các hoạt động và các hành động diễn ra tiếp theo và biểu diễn chủng ở dạng các trạng thái hoạt động hay hành động trong biểu để hoạt động.
Biểu đồ thành phần
Sử dụng các giao diện cho phép chúng ta tránh được sự phụ thuộc trực tiếp giữa các thành phần, dễ cho việc tích hợp và thay thế các thành phần mới. Ngoài ra biểu đồ thành phần còn có thể được dùng trong một số tình huống khác như mô hình hóa các giao diện lập trình ứng dụng (api) cũng như mã nguồn chương trình.
Biểu đồ triển khai
Chúng ta sử dụng cơ chế mở rộng của UML (stereotypes) để biểu diễn các bộ xử lý (processor) và các thiết bị (devices) ở dạng các nút, xem Hình 2.40. - Biểu diễn phân bố theo một trong ba cách: (1) Đưa vào phần đặc tả của nút thay vì biểu diễn trực quan sự phân bố đó; (2) Sử dụng các quan hệ phụ thuộc để kết nối mỗi nút với các thành phần triển khai trên nó; (3) Liệt kê các thành phần được triển khai trên một nút trong một ngăn mở rộng của kỳ pháp nút, như minh họa trong Hình 2.41.
PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG
Phân tích kiến trúc
Đầu vào cho hoạt động phân tích kiến trúc, được minh họa trong Hình 4.2, gồm các chế tác sau: mô hình ca sử dụng, các độc tà bổ sung, từ điển thuật ngữ, 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, và các tài liệu kiến trúc hệ thống. Đố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.
Phân tích ca sử dụng
Việc sử dụng các stereotype để tái hiện các khía cạnh này (chẳng hạn, lớp biên, điều khiển và thực thể) sẽ cho ta một mô hình tốt bởi vì nó phân tách các phần tử mô hình theo tiêu chỉ về tính dễ thay đổi: lớp biên (giao tiếp với môi trường) dễ thay đổi, luồng điều khiển ít thay đổi hơn và các thực thế hệ thống chính hầu như không thay đổi. Lớp hiện làm tách biệt hệ thống khỏi các thay đổi liên quan đến môi trường (những thay đổi về giao diện hệ thống cũng như thay đổi về yêu cầu 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.
THIẾT KẾ HƯỚNG ĐỐI TƯỢNG
Xác định các phần tử thiết kế
Nguyên nhân dẫn tới việc phân bố mô hình thiết kế theo các gói hoặc hệ thống con là chúng ta sử dụng các gói và hệ thống con theo các đơn vị chuyển giao, theo cấu hình, theo thứ bậc khi hệ thống hoàn thành. Khi các lớp phân tích quả phức tạp, ví dụ như các hành vi của nó không thể là trách nhiệm trong một lớp đơn giản, hoặc các trách nhiệm của lớp cần phải được tái sử dụng, lớp phân tích cần được làm mịn thành một hệ thống con (Hình 5.3).
Các cơ chế thiết kế
Để hoàn thiện biểu đồ lớp, cần phải có một quan hệ sử dụng (Uses) từ Application đến OpenCommand đề chỉ ra đối tượng của lớp này tạo ra đối tượng của lớp kia, và một quan hệ Uses từ lớp Menu đến lớp Command vì thao tác AddItem có một tham số có kiểu Command (Hình 5.7). Chúng được sử dụng trong quá trình phân tích để giảm độ phức tạp của phân tích và để cải tiến sự đồng nhất bằng cách cung cấp cho người thiết kế một sự biểu diễn ngắn gọn về các hành vi phức tạp.
Mô tả kiến trúc thực thi
Việc lựa chọn dựa trên mức độ kết dính (các tiến trinh chạy độc lập trong khi các luồng chạy trên mỗi trường của các tiến trình) và các yêu cầu hiệu năng của hệ thống (sự trao đổi thông tin giữa các luống thường nhanh và hiệu quả hơn giữa các tiến trinh). Để minh họa, biểu đồ lớp được về để mô hình hóa các tiến trinh và luồng như là các lớp tích cực và biểu diễn quan hệ hợp thành (composition) của các lớp tích cực (quan hệ bao nhau giữa phần tử tiến trình và các phần tử thiết kế thực hiện nó).
Mô tả sự phân tán
Kiến trúc 3 lớp (Three-tier architecture) là một trường hợp đặc biệt của kiến trúc client/server trong đó chức năng hệ thống được chia làm 3 phần logic: các dịch vụ ứng dụng, các dịch vụ nghiệp vụ và các dịch vụ dữ liệu, các phần logic này có thể đặt ở trên 3 hoặc nhiều nút vật lý (Hình 5.11). Chúng ta cũng cần xem xét thêm một số thông tin như khả năng của nút về bộ nhớ và khả năng xử lý, dung lượng trung bình có thể chuyển tải (bus, LANs, WANs), khả năng của phần cứng và liên kết giữa các nút, khả năng xử lý lỗi.
Thiết kế ca sử dụng
Các chế tác đầu vào của hoạt động này bao gồm mô hình phân tích, các đặc tả bổ sung, các lớp thiết kế, hệ thống con,… và kết quả của hoạt động này là một mô hình thiết kế với các ca sử dụng đã hiện thực hóa ở mức thiết kế. Mục đích của việc thống nhất các lớp và các hệ thống con là để đảm bảo các phần tử thiết kế thể hiện một khái niệm chính xác, không trùng lặp về trách nhiệm, đảm bảo tính đồng nhất và nhất quán trong mô hình.
Thiết kế các hệ thống con
Các phần tử hệ thống con đã được định nghĩa để cài đặt các trách nhiệm của hệ thống con, sự hợp tác giữa các phần tử được mô hình hóa sử dụng các biểu đồ tương tác và cấu trúc bên trong của hệ thống con (quan hệ giữa các phần tử hệ thống con) được mỗ hình hóa sử dụng biểu đồ lớp. Nếu phần tử mô hình kết nối trực tiếp đến một phần tử mô hình trong hệ thống con khác, người thiết kể không thể xóa hoặc phân bố lại hành vi của phần tử mô hình đến các phần tử khác, vì vậy, hệ thống trở nên thiếu chắc chắn.
Thiết kế các lớp
Một thể hiện của lớp CourseOffering có thể có một đối tượng lớp Professor được gắn vào để biểu diễn mối quan hệ dạy học môn này (vì thế số cá thể của lớp Professor là 0,1 trong sự liên kết giữa CourseOffering-Professor). Trong ví dụ trên Hình 520, khi một thể hiện của lớp CourseOffering là Unassigned (nghĩa là Professor không được phân công đi dạy trong học kỳ), và thể hiện nhận sự kiện addProfessor, thể hiện CourseOffering chuyển sang trạng thái Assigned (được phân công giảng dạy trong học kỳ).