PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

v Giảng viên: ThS. Nguyễn Đức Hiếu

v Khoa: Công nghệ thông tin
v Bộ môn: Khoa học máy tính
v Email: nguyenduchieu247@gmail.com
v Mobile: 0968.240.787
 Nội dung

v Các khái niệm hướng đối tượng

v Quy trình phát triển hướng đối tượng

v Tổng quan về phân tích và thiết kế hướng đối tượng

2
 Các khái niệm hướng đối tượng

v 4 nguyên tắc chính trong mô hình hoá hướng đối tượng

• Sự trừu tượng hoá

• Tính đóng gói

• Tính mô-đun hoá

• Sự phân cấp

v Tính đa hình

v Tổng quát hoá và kế thừa

3
4 nguyên tắc chính trong mô hình hoá
hướng đối tượng

4
 Trừu tượng hoá

v Mô hình hoá là quá trình trừu tượng hoá các đối tượng trong thế giới thực vào
ngữ cảnh của hệ thống.
v Trừu tượng hoá có thể được định nghĩa là các đặc điểm cần thiết của một
thực thể để phân biệt nó với tất cả các loại thực thể khác.
v Trong mô hình hoá hướng đối tượng, trừu tượng hoá là việc xây dựng
một mô hình chỉ bao gồm các đặc điểm quan trọng, cần thiết để phân biệt
nó với tất cả các loại mô hình khác.
• Tạo ra mô hình có các đặc tính riêng biệt.
• Cho phép quản lý sự phức tạp của mô hình.
v Sự trừu tượng hoá theo các mức độ khác nhau là nguyên tắc cơ bản để
xây dựng các khái niệm hướng đối tượng.
5
Ví dụ về sự trừu tượng hoá

Professor
Student

6
 Tính đóng gói

v Tính đóng gói là sự quy tụ các tính chất (các thuộc tính và các hành
vi) của một thực thể vào trong một hộp đen trừu tượng.
v Cho phép người sử dụng dùng đối tượng mà không biết bên trong
đối tượng có những gì.
v Tính đóng gói -> khái niệm che dấu thông tin.
v Tính đóng gói dữ liệu của OOP:
• Cho phép che dấu sự cài đặt bên trong các phương thức.
• Cho phép che dấu dữ liệu bên trong các đối tượng.
• Cho phép giảm thiểu việc viết lại mã nguồn chương trình.

7
 Tính đóng gói (tt.)

v Trong OOP, dữ liệu luôn được tổ chức thành các thuộc tính của lớp
đối tượng.
• Việc truy nhập vào dữ liệu phải thông qua các phương thức cho phép
của đối tượng tương ứng.
v Cho phép che dấu sự cài đặt bên trong các client.
• Các client phụ thuộc vào interface.

8
 Tính mô-đun hoá

v Sự phân rã về mặt vật lý hoặc logic một thứ gì đó phức tạp thành các
phần nhỏ hơn, cấu trúc đơn giản hơn và có thể quản lý được.
v Phân rã các hệ thống phần mềm lớn và phức tạp thành các mô-đun
nhỏ hơn, các mô-đun này được phát triển độc lập và có thể tương tác
được với nhau.

9
 Sự phân cấp

v Sự sắp xếp thứ tự hoặc phân hạng sự trừu tượng hoá của các đối
tượng theo một cấu trúc cây.
v Sự phân cấp là một cách tổ chức theo kiểu phân loại.
• Phân cấp lớp.
• Phân cấp sự kế thừa.
• Phân cấp theo kiểu của đối tượng.
v Trong kỹ thuật hướng đối tượng, sự phân cấp được sử dụng
để tổ chức các đối tượng trong hệ thống.

10
Ví dụ về sự phân cấp

v Các phần tử cùng cấp bậc trong hệ thống phân cấp sẽ

có cùng mức độ trừu tượng hoá. 11
 Tính đa hình

v Trong kỹ thuật hướng đối tượng, tính đa hình có thể được định nghĩa là
khả năng mang nhiều kiểu khác nhau của đối tượng.
v Tính đa hình cho phép cùng một thông điệp gửi đi, có thể được xử lý
theo các cách khác nhau tuỳ thuộc vào đối tượng nhận nó.
v Tính đa hình cho phép che dấu nhiều sự cài đặt khác nhau đằng sau
một giao diện duy nhất.

Manufacturer A Manufacturer B Manufacturer C

12
 Tính đa hình (tt.)

v Trong lập trình hướng đối tượng:

• Đa hình phương thức: Phương thức trùng tên, phân biệt bởi
danh sách tham số (Overload và Override).
• Đa hình đối tượng:
• Nhìn nhận đối tượng theo nhiều kiểu khác nhau (Upcasting và
Downcasting).
• Các đối tượng khác nhau thực hiện cùng một thông điệp nhưng
giải nghĩa thông điệp đó theo những cách thức khác nhau.

13
 Tổng quát hoá

v Tổng quát hoá (generalization) là một mối quan hệ giữa các lớp (hoặc các ca
sử dụng), trong đó tồn tại một lớp (hoặc một ca sử dụng) sẽ chia sẻ cấu trúc
và/hoặc hành vi cho một hoặc nhiều lớp (ca sử dụng) khác.
v Xác định một sự phân cấp mức độ trừu tượng hoá, trong đó tồn tại một
lớp con kế thừa từ một hoặc nhiều lớp cha.
• Đơn kế thừa.
• Đa kế thừa.
v Mối quan hệ kiểu “is a kind of”.
v Phân biệt hai thuật ngữ “Tổng quát hoá” và “Kế thừa”?

14
Ví dụ về đơn kế thừa

Ancestor
Account
- balance
Superclass - name
(parent) - number

+ withdraw()
+ createStatement()

Generalization
Relationship

Subclasses Savings Checking

(children)

Descendents 15
 Ví dụ về đa kế thừa

v Cơ chế đa kế thừa được sử dụng để mô tả chính xác thế giới quan và làm
giảm độ phức tạp trong các mô hình hướng đối tượng.

16
 Quy trình phát triển hướng đối tượng
v 3 đặc trưng chính của việc phát triển các HTTT theo phương pháp
hướng đối tượng
• Định hướng bởi các ca sử dụng
• Lấy kiến trúc làm trung tâm
• Phát triển lặp và gia tăng
v Một số vấn đề trong phát triển phần mềm
• Triệu chứng
• Căn nguyên
• Hướng giải quyết
v Quy trình phát triển RUP (Rational Unified Process)
• Giới thiệu
• Các pha
• Các hoạt động
• Bộ kinh nghiệm thực tiễn 17
 3 đặc trưng chính của việc phát triển các HTTT
theo phương pháp hướng đối tượng

v Định hướng bởi các ca sử dụng:

• Một ca sử dụng là một chuỗi các hành động mà hệ thống sẽ thực hiện
để đạt được một kết quả có thể quan sát được bởi một tác nhân cụ
thể. Nó định nghĩa một chức năng có thể sử dụng được từ hệ thống.
• Đặc tả ca sử dụng mô tả cách người dùng tương tác với hệ thống.
• Các ca sử dụng là công cụ mô hình hoá chính.
• Các ca sử dụng được dùng để xác định hành vi của hệ thống.

18
 3 đặc trưng chính của việc phát triển các HTTT
theo phương pháp hướng đối tượng (tt.)

v Lấy kiến trúc làm trung tâm:

• Kiến trúc phần mềm chứa đựng một tập các quyết định thiết yếu về
thiết kế và tổ chức hệ thống phần mềm. Kiến trúc phần mềm phản
ánh các khía cạnh cấu trúc (khía cạnh tĩnh), hành vi (khía cạnh động)
và cách tổ chức phân cấp trong hệ thống.
• Kiến trúc có thể được xem như là các ràng buộc cho khâu thiết kế và
xây dựng hệ thống.
• Lấy kiến trúc làm nền tảng cho đặc tả, thiết kế, xây dựng và tài
liệu hoá hệ thống.
• Việc tạo ra và hợp lệ kiến trúc sớm là mục tiêu chính trong các
lần lặp đầu của hoạt động phân tích và thiết kế.
19
 3 đặc trưng chính của việc phát triển các HTTT
theo phương pháp hướng đối tượng (tt.)
v Phát triển lặp và gia tăng:
• Phát triển lặp là một kỹ thuật được sử dụng để chuyển các chức năng của hệ thống
vào một chuỗi liên tục các phiên bản hoàn thiện tăng dần.
• Mỗi phiên bản được phát triển trong một khoảng thời gian xác định -> vòng lặp.
• Mỗi vòng lặp tập trung vào định nghĩa, phân tích, thiết kế, xây dựng, tích hợp và
kiểm thử một tập các yêu cầu -> một phiên bản thực thi được.
• Mỗi vòng lặp sẽ đưa hệ thống ngày càng gần hơn với mong đợi sau cùng của user.
• Các vòng lặp đầu tiên hướng đến các rủi ro có mức độ ưu tiên cao nhất.
• Lựa chọn một tập con các chức năng (hoặc một tập tối thiểu các ca sử dụng liên
quan) để phát triển -> kiểm chứng (thông qua một tập các ca kiểm thử thực hiện
được -> gia tăng.
• Việc thử nghiệm các phiên bản (thực thi được) sẽ được diễn ra liên tục trong
suốt vòng đời phát triển của hệ thống.
20
 Một số vấn đề trong phát triển phần mềm
Triệu chứng

v Trong kỹ thuật phần mềm, triệu chứng là biểu hiện về sự tồn tại các vấn đề
xấu trong vòng đời phát triển phần mềm.
v Các triệu chứng điển hình:
• Yêu cầu không được đáp ứng.
• Yêu cầu thay đổi quá nhanh.
• Các mô-đun không lắp ghép được.
• Bảo trì khó.
• Phát hiện lỗi muộn.
• Chất lượng kém.

v Hạn chế các triệu chứng -> phát triển phần mềm chất lượng cao theo định
hướng phát triển lặp.
21
 Một số vấn đề trong phát triển phần mềm
Căn nguyên

v Xử lý những căn nguyên -> hạn chế được các triệu chứng.

Yêu cầu không được Các mô-đun không lắp Phát hiện lỗi muộn -
đáp ứng ghép được Chất lượng kém

Định nghĩa yêu cầu phần Giao tiếp nhập nhằng Ít được kiểm thử
mềm không chính xác.
Thu thập yêu cầu thiếu. Tồn tại phi nhất quán Đánh giá chủ quan

22
 Một số vấn đề trong phát triển phần mềm
Hướng giải quyết

v Định nghĩa yêu cầu phần mềm không chính xác -> Phát triển lặp.
v Thu thập yêu cầu thiếu -> Quản lý yêu cầu.
v Giao tiếp nhập nhằng -> Mô hình hoá trực quan (UML).
v Tồn tại phi nhất quán -> Kiểm tra liên tục.
v Ít được kiểm thử -> Kiểm tra chất lượng thường xuyên.
• Kiểm thử chức năng.
• Kiểm thử tính khả dụng.
• Kiểm thử độ tin cậy.
• Kiểm thử hiệu năng.
• Kiểm thử tính hỗ trợ.
23
 Giới thiệu quy trình phát triển RUP
(Rational Unified Process)

v Quy trình phát triển hướng đối tượng, được áp dụng rộng rãi.
v RUP được mô tả từ 3 khung nhìn:
• Khung nhìn động -> chỉ ra các pha của mô hình RUP theo chiều thời gian.
• Khung nhìn tĩnh -> chỉ ra các hoạt động trong quy trình RUP.
• Khung nhìn thực tiễn -> đề xuất bộ kinh nghiệm thực hành tốt được sử
dụng trong quy trình RUP.

24
 Các pha của quy trình phát triển RUP

v H

v Pha khởi đầu (Inception): Định nghĩa phạm vi, xác định tất cả các tác
nhân và các ca sử dụng có thể có, đánh giá các ca sử dụng nào là cần
thiết nhất. Sau đó, phát triển một bản kế hoạch để nghiên cứu, đánh giá
tính khả thi (sự đóng góp mà hệ thống có thể tạo ra cho doanh nghiệp,
sự phù hợp về kinh phí phát triển …).
25
 Các pha của quy trình phát triển RUP (tt.)

v Pha chi tiết (Elaboration): Phát triển khâu nắm bắt yêu cầu, thiết lập
một khung kiến trúc cho hệ thống và xác định các rủi ro chính. Đầu ra
của pha này là một mô hình yêu cầu cho hệ thống, một tài liệu mô tả
kiến trúc và một bản kế hoạch phát triển phần mềm.
v Pha xây dựng (Construction): Thiết kế hệ thống, lập trình và kiểm thử.
Các thành phần của hệ thống được phát triển song song và được tích
hợp trong pha này. Đầu ra của pha này là một hệ thống phần mềm chạy
được và các tài liệu liên quan.
v Pha chuyển giao (Transition): Bàn giao hệ thống tới người dùng cuối,
hỗ trợ cài đặt và sử dụng.
26
 Các hoạt động trong quy trình phát triển RUP

v Các hoạt động diễn ra trong quá trình phát triển (khung nhìn tĩnh của
RUP) được gọi là luồng công việc trong mô tả RUP:
• Mô hình hoá nghiệp vụ (Business Modeling): Các quy trình nghiệp vụ
được mô hình hoá bằng cách sử dụng các trường sử dụng nghiệp vụ.
• Yêu cầu (Requirements): Định nghĩa những gì hệ thống cần làm.
• Phân tích và thiết kế (Analysis and Design): Chỉ ra làm thế nào các ca
sử dụng của hệ thống được cài đặt.
• Cài đặt (Implementation): Mã hoá các thành phần phần mềm đáp ứng bộ
tiêu chí chất lượng.
• Kiểm thử (Testing): Tích hợp và kiểm thử hệ thống.

27
 Các hoạt động trong quy trình phát triển RUP (tt.)

• Triển khai (Deployment): Cung cấp sản phẩm phần mềm đến tay người
sử dụng.
• Quản lý thay đổi và cấu hình (Configuration and change
management): Hỗ trợ quản lý các thay đổi đối với hệ thống.
• Quản lý dự án (Project Management): Đảm bảo tất cả các công việc
được lên lịch, quản lý việc phát triển hệ thống.
• Môi trường (Environment): Quản lý môi trường mà hệ thống được phát
triển trên đó.
v RUP được thiết kế để có thể kết hợp với UML -> mô tả các hoạt động
trong quy trình RUP được định hướng xoay quanh các mô hình UML
(các biểu đồ tuần tự, các biểu đồ đối tượng).
28
 Bộ kinh nghiệm thực hành tốt của RUP

1. Phát triển phần mềm qua các lần lặp: Lập kế hoạch phát triển gia
tăng cho hệ thống dựa trên mức độ ưu tiên từ phía khách hàng,
phát triển các tính năng của hệ thống có độ ưu tiên cao nhất ngay
từ những giai đoạn ban đầu trong quy trình phát triển.
2. Quản lý các yêu cầu: Tài liệu hoá một cách rõ ràng về các yêu
cầu của khách hàng và theo dõi những thay đổi đối với các yêu cầu
này. Phân tích tác động của những thay đổi đó với hệ thống trước
khi chấp nhận chúng.
3. Sử dụng kiến trúc dựa trên thành phần: Cấu trúc hoá kiến trúc
hệ thống thành các thành phần.
29
 Bộ kinh nghiệm thực hành tốt của RUP (tt.)

4. Mô hình hoá trực quan phần mềm: Sử dụng các mô hình đồ hoạ
UML để biểu diễn các khung nhìn tĩnh và động của phần mềm.
5. Kiểm tra chất lượng phần mềm: Đảm bảo rằng phần mềm đáp
ứng các tiêu chuẩn chất lượng.
6. Kiểm soát các thay đổi đối với phần mềm: Quản lý các thay đổi
đối với phần mềm bằng cách sử dụng một hệ thống quản lý thay
đổi và các công cụ hỗ trợ khác.

30
 Tổng quan về phân tích và thiết kế
hướng đối tượng

v Tầm quan trọng của OOAD

v Mục đích của OOAD

v Phương pháp OOAD

OOAD (Object-Oriented Analysis and Design): Phân tích và thiết kế hướng đối tượng.

31
 Tầm quan trọng của OOAD

v Nhiều kỹ sư phần mềm:

• Nhìn nhận phần mềm chủ yếu được xây dựng bằng cách viết chương trình.
• Không dành đủ thời gian cho quá trình phân tích và thiết kế phần mềm.
-> Khó hoàn thành chương trình do:
• Không hiểu hoặc hiểu sai yêu cầu.
• Giao tiếp, trao đổi giữa các thành viên trong team dev không tốt.
• Không tích hợp được với mô-đun của đồng nghiệp.
…

32
 Tầm quan trọng của OOAD (tt.)

v Cần một cơ chế hiệu quả để nắm bắt các yêu cầu, phân tích và
thiết kế.
v Cơ chế này phải giống như một ngôn ngữ thống nhất để giúp cho
quá trình cộng tác giữa các thành viên trong nhóm phát triển phần
mềm trở nên hiệu quả hơn.
-> Phân tích và thiết kế hướng đối tượng.

33
 Mục đích của OOAD

v Chuyển các yêu cầu của bài toán thành một bản thiết kế của hệ
thống sẽ được xây dựng.
v Đảm bảo mục đích và các yêu cầu của hệ thống phải được tài liệu hoá
một cách hợp lý trước khi bắt đầu xây dựng hệ thống.
v Tập trung vào quá trình phân tích các yêu cầu của hệ thống và thiết kế
các mô hình cho hệ thống đó trước giai đoạn lập trình.
v Hình thành kiến trúc chắc chắn cho hệ thống.
v Đưa ra giải pháp thiết kế nhằm tương thích với môi trường cài đặt và
các yêu cầu phi chức năng.
v Cung cấp cho người dùng, khách hàng, kỹ sư phân tích, kỹ sư thiết kế
nhiều khung nhìn khác nhau về hệ thống. 34
Phương pháp OOAD

35
 Phân tích hướng đối tượng

v Phân tích là hoạt động chuyển tiếp từ khâu nắm bắt yêu cầu sang
thiết kế hệ thống trong quy trình phát triển phần mềm.
v Phân tích hướng đối tượng là phương pháp phân tích dựa trên
các lược đồ hướng đối tượng.
• Hai hoạt động chính trong OOA là phân tích kiến trúc và phân tích ca
sử dụng.

36
 Thiết kế hướng đối tượng

v Quá trình làm mịn các kết quả của mô hình phân tích để xây dựng
mô hình thiết kế (mô hình sát với các chương trình sẽ được viết).
• Xác định các phần tử thiết kế.
• Thiết kế các ca sử dụng.
• Thiết kế các hệ thống con.
• Thiết kế các lớp.
• Thiết kế cơ sở dữ liệu.

Note: Có thể vận dụng các mẫu thiết kế.

37