CHƯƠNG 2. PHÂN TÍCH, THIẾT KẾ HTTT QUẢN LÝ HỘI NGHỊ
1.2 CƠ SỞ LÝ THUYẾT PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG VỚI UML 2.0
Phương pháp phân tích thiết kế hướng đối tượng đã rất phổ biến nhiều năm này bởi vì phù hợp và dễ dàng chuyển giao từ ngôn ngữ mô hình sang ngôn ngữ lập trình hướng đối tượng. Ngôn ngữ mô hình hóa được sử dụng phổ biến hiện này là UML (Unified Modeling language) và gần đây nhất là phiên bản 2.0, UML 2.0 được bổ sung nhiều ngôn ngữ cập nhật hơn để mô tả các kiến trúc phần mềm hiện đại như SOA (Service-oriented architecture) mà được sử dụng cho phát triển các hệ thống ERP (Enterprise Resource Planning) hay điện toán đám mây. Tuy nhiên, để xây dựng tài liệu phân tích thiết kế hoàn chỉnh, ngoài kiến thức cơ sở về hướng đối tượng, ngôn ngữ mô hình UML, thì nhà phân tích thiết kế cần có kiến thức và kinh nghiệm về các quy trình phát triển phần mềm như thác nước (Waterfall), Agile hay RUP…
thì mới phù hợp, gắn liền được với các đội phát triển. Tóm lại, để ra một bản thiết kế phần mềm đúng, nhà thiết kế cần phải có kiến thức đa dạng và kinh nghiệm nhất định. Do vậy, phần này, học viên sẽ tóm lược một số kiến thức cơ bản cần thiết để thực hiện trong luận văn.
2.1.1. Tổng quan ngôn ngữ mô hình UML 2.0 Mô hình hóa để làm gì?
Mô hình là một sự đơn giản hóa của hiện thực. Nó là một mô tả đầy đủ của một hệ thống theo một khía cạnh/góc nhìn cụ thể. Chúng ta xây dựng các mô hình để có thể hiểu rõ hơn về hệ thống đang xây dựng. Chúng ta xây dựng các mô hình cho các hệ thống phức tạp vì chúng ta không thể nào lĩnh hội được tổng thể hệ thống.
Mô hình hóa rất quan trọng vì nó giúp nhóm phát triển trực quan hóa, xác định, xây dựng, tài liệu hóa cấu trúc và hành vi kiến trúc hệ thống. Sử dụng một ngôn ngữ mô hình hóa tiêu chuẩn như UML, các thành viên khác nhau của nhóm phát triển có thể truyền đạt ý định của họ một cách rõ ràng với nhau.
Sử dụng các công cụ mô hình hóa giúp dễ dàng quản lý các mô hình, cho phép ẩn hoặc hiển thị chi tiết khi cần thiết. Mô hình hóa cũng giúp duy trì tính nhất quán giữa các thành phần (artifact) về hệ thống: các yêu cầu, thiết kế
21
và lập trình. Nói tóm lại, mô hình hóa giúp cải thiện khả năng làm việc nhóm để quản lý độ phức tạp của phần mềm.
Ngôn ngữ mô hình UML
UML cung cấp một ngôn ngữ đồ họa để biểu diễn các mô hình nhưng cung cấp ít hoặc không có hướng dẫn về khi nào và như thế nào khi sử dụng các đồ hình này. Do đó, luận văn này tuân thủ theo quy trình phần mềm RUP (Rational Unified Process). RUP mô tả các loại thành phẩm (artifact) dự án cần thiết, bao gồm các đồ hình (diagram), và đưa chúng trong nội dung của một kế hoạch dự án tổng thể.
Trong việc xây dựng một mô hình trực quan của một hệ thống, cần có nhiều đồ hình khác nhau để thể hiện các góc nhìn khác nhau của hệ thống.
UML cung cấp các ký hiệu phong phú để trực quan hóa các mô hình. Các đồ hình chính sau đây, Hình 1.5:
Đồ hình tác vụ (Use-case diagrams): để minh họa các tương tác của người dùng với hệ thống
Đồ hình lớp (Class diagrams): để minh họa cấu trúc logic
Đồ hình đối tượng (Object diagrams): để minh họa các đối tượng và liên kết
Đồ hình thành phần (Component diagrams): để minh họa cấu trúc vật lý của phần mềm
Đồ hình triển khai (Deployment diagrams): để hiển thị ánh xạ phần mềm đến cấu hình phần cứng
Đồ hình hoạt động (Activity diagrams): để minh họa các luồng sự kiện
Đồ hình máy trạng thái (State Machine diagrams): để minh họa hành vi
Đồ hình tương tác (Interaction diagrams): gồm đồ hình Giao tiếp và Trình tự (Communication và Sequence diagrams) để minh họa hành vi.
22
Hình 2.1: Các đồ hình UML 2.0 sử dụng phân tích thiết kế hệ thống Đây không phải là tất cả các đồ hình UML mà chỉ là một mẫu đại diện.
2.1.2. Phân tích thiết kế hướng đối tượng với quy trình RUP và UML Mục đích của Phân tích và Thiết kế là:
Chuyển đổi các yêu cầu thành một thiết kế hệ thống.
Phát triển một kiến trúc mạnh mẽ cho hệ thống.
Điều chỉnh thiết kế để phù hợp với môi trường lập trình, và cho hiệu suất hệ thống.
Quy trình Phân tích và Thiết kế có liên quan đến các quy trình RUP khác để xây dựng phần mềm.
Quy trình mô hình hóa kinh doanh (Business modeling): cung cấp hoạt động tổ chức cho hệ thống.
Quy trình Yêu cầu (Requirements): cung cấp đầu vào chính cho Phân tích và Thiết kế.
Quy trình kiểm tra: kiểm tra hệ thống được thiết kế trong quá trình Phân tích và Thiết kế.
23
Quy trình Môi trường (Environment): phát triển và duy trì các thành phẩm được sử dụng trong Phân tích và Thiết kế.
Quy trình quản lý: lên kế hoạch cho dự án và mỗi lần lặp (được mô tả trong Kế hoạch lặp).
Hình 2.2: Mô hình RUP sử dụng để mô tả kiến trúc phần mềm
Hình [2.2] là mô hình RUP sử dụng để mô tả kiến trúc phần mềm. Kiến trúc gồm nhiều nhiều phần cho những bên quan tâm khác nhau. Trên một dự án cụ thể, thường có nhiều bên liên quan, mỗi bên có mối quan tâm và quan điểm riêng về hệ thống sẽ được phát triển. Mục tiêu của mô hình là cung cấp cho mỗi bên liên quan một cái nhìn về hệ thống để phù hợp các mối quan tâm của họ.
Để giải quyết các nhu cầu khác nhau này, RUP đã định nghĩa mô hình kiến trúc “4 + 1 view” (góc nhìn), Hình 2.3. Một góc nhìn kiến trúc là một mô tả đơn giản hóa của một hệ thống từ một khía cạnh cụ thể, bao gồm các mối quan tâm cụ thể và bỏ qua các thực thể không liên quan đến khía cạnh này.
Góc nhìn là những lát cắt của các mô hình.
Không phải tất cả các hệ thống đều yêu cầu tất cả các góc nhìn.
24
Hình 2.3: Các góc nhìn chính được sử dụng trong quy trình RUP
View Trách nhiệm Mục đích
Use case view (Tác vụ)
Thiết kế hệ thống và người dùng cuối
Mô tả Actor, use case và các yêu cầu khác
Logical view
(Logic) Thiết kế hệ thống Mô tả các liên kết và các gói, lớp, mô hình dữ liệu trong Use case Process view (xử
lý luồng) Kỹ sư hệ thống
Mô tả các yêu cầu nhiều luồng để tăng hiệu năng, tốc độ, hiệu xuất…
Implementation view (thực hiện lập trình)
Lập trình viên Kiến trúc, thư viện, mã phần mềm…
Deployment view
(triển khai) Kỹ sư Hệ thống Triển khai phần mềm, CSDL, Server, kết nối
Bảng 2.1: diễn giải trách nhiệm và mục đích các góc nhìn