Bài giảng Phân tích và thiết kế hệ thống thông tin - Phần 1: Nguyên lý - Nguyễn Anh Hào

c thêm tùy biến cho dịch vụ.
 Ở góc độ hệ thống (lắp ghép các đối tượng): chỉ cần biết dịch 
vụ & cách giao tiếp của đối tượng để sử dụng nó mà không 
cần biết cách cài đặt bên trong của nó.
30
Nguyên lý hướng đối tượng (3)
3. Đối tượng được nhận biết từ lớp của nó.
• Sự xếp lớp cho đối tượng là cách đơn giản nhất để biết về đối 
tượng, giống như cách phát triễn nhận thức của loài người.
ví dụ: Bob là một con chó, vậy nó có thể sủa vì loài chó sủa 
được (trừ khi Bob không thích sủa hoặc bị tắt tiếng).
• Trong cách mô hình hóa, mọi thuộc tính và hành vi của các 
đối tượng thuộc lớp đều giống nhau, và đó là các thuộc tính và 
hành vi của lớp đối tượng (lớp đối tượng là cái “khuông” để 
đúc ra các đối tượng).
• Lớp đối tượng cũng được xếp lớp vào lớp tổng quát hơn (lớp 
cha); đây là khái niệm tổng quát hóa.
ví dụ: bác sỹ là nhân viên của BV, nhân viên là công dân (vậy 
bác sỹ cũng là công dân).
31
Nguyên lý hướng đối tượng (4)
4. Lớp đối tượng có quyền thừa kế.
• Mọi lớp đối tượng con đều có quyền thừa kế mọi thứ từ lớp đối 
tượng cha; kể cả các quan hệ của lớp đối tượng cha.
• Một lớp đối tượng con có thể kế thừa từ nhiều lớp đối tượng 
cha: đó là tính đa kế thừa (multi-inheritance). Ví dụ: một lớp 
lập trình viên kế thừa từ 2 lớp: người nhân viên (có tên, tuổi) 
và nghề lập trình (viết được code).
• Sự kế thừa trong phần mềm hổ trợ tối đa cho việc sử dụng lại.
• Các hành vi được kế thừa có thể được thay đổi ở lớp đối tượng 
con để hành vi đó trở thành tinh vi hơn, đó là tính đa hình 
(polymorphism) trong cách thừa kế.
32
Nguyên lý hướng đối tượng (5)
5. Hành vi của đối tượng phụ thuộc trạng thái của nó
• Giá trị cụ thể của thuộc tính quyết định trạng thái của đối 
tượng. Một trạng thái của đối tượng là một bộ giá trị thuộc tính 
của nó, ví dụ: đối tượng có 2 thuộc tính A và B, a và b là 2 giá 
trị dữ liệu của A và B thì 1 trạng thái của đối tượng này là (a,b)
Đối tượng có nhiều trạng thái khác nhau. Ví dụ: 1 cột đèn điều 
khiển giao thông có 3 trạng thái: Xanh, Vàng, Đỏ.
• Sự thay đổi trạng thái của đối tượng là do đối tượng tự phản 
ứng với các sự kiện kích hoạt (ở cột đèn là tín hiệu timeout 
của mỗi màu). Sự chuyển sang trạng thái mới (S2) được quyết 
định bởi 2 yếu tố: trạng thái hiện tại (S1), và sự kiện kích hoạt 
e: S2 =  (S1,e),  được gọi là một hàm chuyển trạng thái.
33
OMT-Các loại mô hình
1. Object & Object Relation Ship model
– Diển tả các đặc tính tĩnh trong miền đối tượng được mô hình hóa.
– Mô tả các lớp: thuộc tính và hành vi riêng, các quan hệ: liên kết 
(association), kết tập (aggregation) và tổng quát hóa (generalization).
2. Functional model
– Diễn tả cách phối hợp hoạt động của các đối tượng trong hệ thống
– Mô tả dòng thông điệp: lđ tuần tự, hợp tác; dòng xử lý: lđ hoạt động
– Các tình huống tương tác với bên ngoài của hệ thống: use-cases
3. Dynamic model
– Diễn tả trạng thái và sự thay đổi trạng thái trong mô hình.
– Mô tả trạng thái, sự chuyễn trạng thái, sự kiện kích hoạt chuyễn trạng 
thái và các hành động gây ra sự chuyển trạng thái (lđ trạng thái)
• Ngữ pháp cho OMT: UML (UML Reference Manual 2nd.pdf)
34
OMT-Các công đoạn
1. Phân tích hệ thống (xác định yêu cầu → đặc tả)
– Coi toàn bộ hệ thống là 1 đối tượng lớn, chỉ ra các tương 
tác hữu ích của nó đối với môi trường (use-case).
– Phân biệt biên & vai trò của đối tượng trong môi trường
2. Thiết kế hệ thống (kiến trúc liên kết của hệ thống)
– Xem xét, tìm các đối tượng liên kết nhau thành hệ thống 
– Object Relationship, Dynamic model, Functinal model
3. Thiết kế đối tượng (đặc tả nội dung chi tiết)
– Dựa trên các models, định nghĩa dịch vụ & tương tác được 
mong đợi từ đối tượng thuộc hệ thống
4. Hiện thực (cài đặt ý tưởng của thiết kế)
35
Mô hình phát triễn hệ thống phần mềm
• SDLC chuẩn (water-fall) là phương pháp xây dựng hệ 
thống cổ điển nhất áp dụng trực tiếp phương pháp luận 
giải quyết vấn đề, gồm các công đoạn và cũng là giai 
đoạn: Khảo sát, Phân tích, Thiết kế, Hiện thực, Kiễm thử, 
Bảo trì.
• Khó thực hiện đúng trình tự này, chỉ vì các yêu cầu bị thay 
đổi do nhận thức mới gây ra làm lại khá nhiều.
• Thay vì dùng mô hình water-fall đòi hỏi sự bất biến cao đ/v 
yêu cầu ban đầu, SE tìm các mô hình mới linh hoạt hơn, 
cho phép cải tiến dần hệ thống, như mô hình làm mẫu thử, 
tiến hóa (xoắn ốc), đối tượng, hợp nhất,
36
Ý nghĩa của các mô hình làm PM
• Các mô hình phát triễn phần mềm là một tập hợp các công 
đoạn hổ trợ với nhau để qua đó, sản phẩm phần mềm được làm 
ra theo cách tối ưu và có kiễm soát (tránh thiếu sót).
• Phần mềm không chỉ áp dụng một lần; nó còn phải tiếp tục 
phát triễn trong khi ứng dụng (ie, cách làm phải hổ trợ cho các 
thay đổi * lên phần mềm). Như vậy, có 2 mục tiêu chính mà các 
mô hình hướng đến:
1. Chuyễn giao được phần mềm đạt chất lượng
2. Tạo điều kiện thuận lợi cho phần mềm phát triễn liên tục sau 
khi chuyển giao (ie, làm thêm, không làm lại)
37
* Hổ trợ thay đổi trong cách làm PM
• Sự thay đổi của PM là sự sửa đổi trên các ấn phẩm của 
phần mềm (bản đặc tả yêu cầu, thiết kế, mã nguồn,) 
• Như vậy, quá trình phát triễn PM thực chất là quá trình 
nhận biết và thực hiện các thay đổi cần thiết cho tất cả các 
ấn phẩm đang sử dụng cho PM; trong đó, một dự định 
thay đổi cần được xem xét nhiều khía cạnh, ví dụ:
1. Nó sẽ gây ra sự khác biệt gì lên PM ? (ie, phiên bản hiện tại)
2. Nó có đáng làm hay không ? (lợi ích/thiệt hại)
3. Nó được hiện thực vào PM như thế nào ? (khó hay dể)
• Sự xem xét và thực hiện các thay đổi đưa đến nhu cầu 
hợp tác trong nhóm phát triễn: trao đổi thông tin, và có 
công nghệ hổ trợ (phương pháp, kỹ thuật, công cụ, kinh 
nghiệm,).
38
Mô hình thác nước (tuyến tính)
Có ấn phẩm ở từng 
công đoạn do người 
phát triễn tạo ra và 
chuyển giao.
Người sử dụng chỉ 
tiếp cận được với sản 
phẩm sau khi nó đã 
được làm theo yêu 
cầu ban đầu.
Khảo sát
Phân tích
Thiết kế
Hiện thực
Kiễm thử
Bảo trì
Sửa lại (rework)
(User)
(User)
(Developer)
39
Mô hình làm mẫu thử (mô hình lặp)
Yêu cầu cải tiến mẫu
Mẫu đã cải tiến
Tạo mẫu
(Developer)
Mẫu 
ban 
đầu
Ứng dụng 
mẫu
Mẫu 
hoàn 
chỉnh
Kiễm thử mẫu
(User)
Cải tiến mẫu
(Developer)
Yêu cầu
(User)
Người sử dụng điều 
khiển quá trình phát 
triễn mẫu, dựa trên 
yêu cầu và kết quả 
thực hiện yêu cầu 
(mẫu).
Mô hình không yêu 
cầu tạo ra các bản đặc 
tả để truyền đạt cách 
làm.
40
Mô hình xoắn ốc (mô hình tiến hóa)
40
 Customer 
Communication
 Planning
 Customer 
Evaluation 
Ước lượng rủi ro
Kiểm tra
Đánh giá
Lập kế hoạch
Xây dựng
 Risks 
 Construction
Yêu cầu & các 
thay đổi
Tạo mẫu thử
Cài đặt
Thiết kế 
 Design
41
Đặc điểm của mô hình xoắn ốc
• Là mô hình kết hợp giữa thác nước và làm mẫu thử
– Mô hình thác nước: Hổ trợ nhóm người phát triễn hệ 
thống cùng làm việc chung với nhau trên các tài liệu 
đặc tả.
– Mô hình mẫu thử: Hổ trợ người sử dụng cùng tham gia 
(tư vấn) vào quá trình phát triễn sản phẩm ngay từ đầu.
• Là mô hình hổ trợ cho nhận thức từ bản chất đến chi 
tiết (từ bất biến đến tùy biến)
– Cho phép cập nhật ấn phẩm của mỗi công đoạn ở chu 
kỳ trước, thay vì phải tạo mới
– Cho phép tiếp tục phát triễn sản phẩm phần mềm trong 
giai đoạn ứng dụng.
41
42
Mô hình hướng đối tượng (mô phỏng)
Khảo sát hệ 
thống
Phân tích yêu cầu 
& tương tác
Tìm đối 
tượng
Xây dựng 
phần mềm
Phát triễn đối 
tượng mới
Yes
Thư viện
Kiễm thử
Ứng dụng
Passed
Obj
Obj Obj
Có sẵn ?
No
Obj
Fail
43
Đặc điểm của mô hình hướng đối tượng
• Mô hình này mô phỏng các đối tượng thực tế và giải pháp từ 
thực tế, để tạo ra phần mềm.
– Dùng UML (Unified Modeling Language) để lập mô hình
• Bản chất của mô hình là xây dựng thư viện các đối tượng được 
mô phỏng từ thực tế, để sử dụng lại cho việc cập nhật, nâng 
cấp phần mềm.
– Việc cập nhật phần mềm = tháo lắp các đối tượng.
• Mô hình có tính trực quan cao (dể hiểu, dể truyền đạt) vì các 
bản đặc tả rất gần gủi với thực tế. 
• Sự thay đổi trong thực tế đã có giải pháp thực tế trên các đối 
tượng, nên rất dể mô phỏng (tháo lắp).
44
Chu kỳ phát triễn
Mô hình hợp nhất (UP/RUP)
Luồng công việc
(Introduction to RUP.pdf)
45
Các giai đoạn của mô hình UP
• Có 4 giai đoạn chính để phát triễn 1 version của PM
– Inception (nhận thức): xác định vai trò của PM, cách làm
– Elaboration(tinh chỉnh): mô tả chi tiết cho PM
– Construction(xây dựng): làm ra một phiên bản PM
– Transistion(chuyễn giao): đánh giá để sử dụng phiên bản đã làm
• Mỗi giai đoạn gồm có một vài chu kỳ phát triễn 
– Mỗi chu kỳ có thể dùng mô hình thác nước/mẫu thử/hướng đối 
tượng, ; kết thúc bằng một mẫu thử (hoặc phần mềm) cho 
người sử dụng xem xét đánh giá hoặc sử dụng.
– Mỗi chu kỳ đưa ra vấn đề, giải pháp, và biện pháp ứng xử rủi ro 
cho các chu kỳ tiếp theo.
46
Luồng công việc của UP
• UP có 2 loại luồng công việc (work-flow): tạo ấn phẩm (6 
luồng đầu) và quản lý (3 luồng cuối).
• Mỗi luồng công việc là một chuỗi hành động nhận thức, hiệu 
chỉnh, xây dựng và chuyễn giao cho mỗi công đoạn làm phần 
mềm (6 luồng đầu), hoặc hổ trợ (3 luồng cuối)
– Mỗi luồng công việc không nằm gọn trong một giai đoạn, mà nó trãi 
rộng suốt quá trình phát triễn 1 version
– Mỗi chu kỳ phát triễn trong mỗi giai đoạn sẽ tiếp tục thực hiện, bổ sung 
thêm hoặc hiệu chỉnh cho 9 luồng công việc này.
47
Đặc điểm của mô hình UP
• UP là sự cải tiến linh hoạt của mô hình xoắn ốc
– 4 giai đoạn hổ trợ từ nhận thức đến thực tiễn
– 9 công đoạn (luồng công việc) cùng phát triễn song song
– Sử dụng tiếp cận hướng đối tượng
• Mô hình này giúp nhận thức sớm được nhiều vấn đề 
phát triễn hệ thống để chuẩn bị trước
– Bằng cách phân tích nguyên nhân-hậu quả của từng vấn đề 
thực tế và minh họa giải pháp bằng mẫu thử (demo) để test
– Ví dụ: từ việc đánh giá mẫu thử, mô hình giúp người phát 
triễn nhận biết trước các vấn đề sẽ xuất hiện trong việc thiết 
kế, cài đặt, vận hành, để định nghĩa thêm các xử lý trong 
các luồng công việc.