Bài giảng Công nghệ phần mềm - Bài 3: Phân tích và thiết kế hệ thống thông tin - Lê Nguyễn Tuấn Thành

Công nghệ Phần mềm
Phân tích và Thiết kế
Hệ thống thông tin
Giảng viên: Lê NguyễnTuấnThành
Email: thanhlnt@tlu.edu.vn
Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT
Trường Đại Học Thủy Lợi
Nội dung
2
} Phân tích và thiết kế kiến trúc
} Phân tích và thiết kế hướng đối tượng
} Phân tích và thiết kế giao diện
Bài giảng có sử dụng hình vẽ trong cuốn sách “Software Engineering, Ian Sommerville, 8th Edition, 2007”
1. Thiết kế kiến trúc
Architectural design
3
Mục tiêu
4
} Giới thiệu thiết kế kiến trúc và thảo luận tầm quan trọng
của nó
} Giới thiệu ba phong cách thiết kế kiến trúc:
} Tổ chức (organisation),
} Chia nhỏ (decomposition),
} Kiểm soát (control)
Chủ đề được đề cập
(Topics covered)
5
} Phong cách tổ chức hệ thống (System organisation)
} Phong cách chia nhỏ (Decomposition styles)
} Phong cách kiểm soát (Control styles)
1.1. Thiết kế Kiến trúc Phần mềm
(Software architecture)
6
} Là quá trình thiết kế để xác định những hệ thống
con tạo nên một hệ thống và khung làm việc
(framework) giúp kiểm soát và giao tiếp giữa các hệ
thống con này.
} Đầu ra của quá trình thiết kế này là một mô tả về Kiến
trúc Phần mềm.
} Đây là giai đoạn đầu của quá trình thiết kế hệ thống.
} Biểu thị mối liên hệ giữa đặc tả yêu cầu và quá trình
thiết kế.
} Thường được thực hiện song song với một số hoạt
động đặc tả yêu cầu.
Ưu điểm của một kiến trúc rõ ràng
(Advantages of explicit architecture)
7
} Giao tiếp của các bên liên quan (Stakeholder)
} Kiến trúc có thể được sử dụng trong các cuộc thảo luận
giữa các bên liên quan đến hệ thống.
} Phân tích hệ thống
} Kiến trúc giúp phân tích xem liệu hệ thống có đáp ứng các
yêu cầu không chức năng của nó hay không.
} Tái sử dụng quy mô lớn (Large-scale reuse)
} Kiến trúc có thể được tái sử dụng trên một dải các hệ
thống tương tự.
} Các hệ thống trong cùng một miền thường có các kiến
trúc tương tự phản ánh khái niệm miền.
Hệ thống Kiểm soát robot đóng gói
(Packing robot control system)
8
1.2. Những phong cách kiến trúc
(Architectural styles)
9
} Kiến trúc của một hệ thống có thể phù hợp với một mô
hình hoặc một kiểu kiến trúc chung.
} Nhận thức về những kiểu kiến trúc này giúp đơn giản
hóa vấn đề định nghĩa kiến trúc hệ thống.
} Tuy nhiên, hầu hết các hệ thống lớn đều không đồng
nhất và không chỉ theo một kiểu kiến trúc đơn nào.
Các mô hình kiến trúc
(Architectural models)
10
} Được sử dụng để tài liệu hóa một thiết kế kiến trúc.
} Mô hình cấu trúc tĩnh thể hiện các thành phần hệ
thống chính.
} Mô hình quy trình động thể hiện cấu trúc quy trình
của hệ thống.
} Mô hình giao diện định nghĩa các giao diện hệ
thống con.
} Mô hình mối quan hệ như mô hình luồng dữ liệu
thể hiện các mối quan hệ giữa các hệ thống con.
} Mô hình phân phối thể hiện cách các hệ thống con
được phân phối trên máy tính.
1.2.1. Phong cách tổ chức hệ thống
(System organisation)
11
} Phản ánh chiến lược cơ bản được sử dụng để cấu
trúc một hệ thống.
} Ba mô hình tổ chức được sử dụng rộng rãi:
1. Kiểu kho dữ liệu chia sẻ;
2. Kiểu máy chủ và dịch vụ chia sẻ;
3. Kiểu tầng và máy trừu tượng.
Mô hình kho lưu trữ chia sẻ
(Repository model)
12
} Các hệ thống con phải trao đổi dữ liệu. Điều này có
thể được thực hiện theo 2 cách:
1. Dữ liệu chia sẻ được lưu trữ trong cơ sở dữ liệu trung
tâm hoặc kho lưu trữ và có thể được truy cập bởi tất cả
các hệ thống con; hoặc
2. Mỗi hệ thống con tự duy trì cơ sở dữ liệu riêng của nó
và truyền dữ liệu một cách tường minh tới các hệ thống
con khác.
} Khi số lượng lớn dữ liệu được chia sẻ, mô hình kho
dữ liệu chia sẻ thường được sử dụng.
VD Mô hình Kho lưu trữ: 
Kiến trúc bộ công cụ CASE
13
Những đặc điểm của mô hình kho lưu trữ
(Repository model characteristics)
14
} Ưu điểm
} Cách hiệu quả để chia sẻ số lượng lớn dữ liệu;
} Các hệ thống con không cần phải liên quan đến cách dữ 
liệu được tạo ra
} Quản lý tập trung, ví dụ: sao lưu, an ninh, v.v. 
} Mô hình chia sẻ được công bố như giản đồ kho lưu trữ.
} Nhược điểm
} Các hệ thống con phải đồng ý về một mô hình dữ liệu kho 
lưu trữ. 
} Việc tiến hóa dữ liệu là khó khăn và tốn kém; 
} Khó phân bố hiệu quả.
Mô hình Máy khách-Máy chủ
(Client-server model)
15
} Mô hình hệ thống phân tán biểu diễn cách dữ liệu và
việc xử lý được phân phối trên một khoảng các
thành phần.
} Tập các máy chủ độc lập cung cấp các dịch vụ cụ
thể như in ấn, quản lý dữ liệu, v.v.
} Tập các máy khách gọi đến các dịch vụ này.
} Mạng cho phép máy khách truy cập máy chủ.
Thư viện phim và hình ảnh
(Film and picture library)
16
Đặc điểm của Mô hình Máy khách-Máy chủ
(Client-server characteristics)
17
} Ưu điểm
} Sự phân phối của dữ liệu là minh bạch
} Sử dụng hiệu quả các hệ thống mạng
} Dễ dàng thêm các máy chủ mới hoặc nâng cấp các máy
chủ hiện có.
} Nhược điểm
} Không có mô hình dữ liệu được chia sẻ nên các hệ thống
con tự tổ chức dữ liệu khác nhau.
} Trao đổi dữ liệu có thể không hiệu quả;
} Quản lý dự phòng trong mỗi máy chủ
Mô hình tầng/máy trừu tượng
18
} Được sử dụng để mô hình hóa giao diện của các hệ
thống con.
} Tổ chức hệ thống thành một tập các tầng (hoặc các
máy trừu tượng), mỗi tầng cung cấp một tập các
dịch vụ.
} Hỗ trợ sự phát triển gia tăng của các hệ thống con
trong các tầng khác nhau. Khi một tầng giao diện
thay đổi, chỉ có các tầng lân cận bị ảnh hưởng.
VD: Hệ thống quản lý phiên bản
(Version management system)
19
1.2.2. Phong cách chia nhỏ thành các Mô-đun
20
} Phong cách chia nhỏ hệ thống con thành các mô-đun.
} Hệ thống con là một hệ thống có quyền riêng của nó
} Hoạt động độc lập với các dịch vụ được cung cấp bởi các hệ thống
con khác.
} Mô-đun là một thành phần hệ thống cung cấp các dịch vụ cho
các thành phần khác
} Thường sẽ không được xem như một hệ thống riêng biệt.
} 2 mô hình chia nhỏ mô-đun:
} Mô hình đối tượng: hệ thống được phân chia thành đối tượng
tương tác;
} Mô hình đường ống (pipeline) hay mô hình luồng dữ liệu
(data-flow): hệ thống được phân chia thành các mô-đun chức
năng để chuyển đổi từ đầu vào đến đầu ra.
Mô hình đối tượng
(Object models)
21
} Cấu trúc hệ thống thành một tập hợp các đối tượng
lỏng lẻo với các giao diện được định nghĩa rõ ràng.
} Sự phân chia hướng đối tượng liên quan đến việc
xác định các lớp đối tượng, các thuộc tính và hoạt
động của chúng.
} Khi được cài đặt, các đối tượng được tạo ra từ các
lớp này và một vài mô hình điều khiển được sử dụng
để phối hợp các hoạt động của đối tượng.
VD: Hệ thống Xử lý Hoá đơn
(Invoice processing system)
22
Ưu điểm của Mô hình Đối tượng
23
} Đối tượng được kết hợp lỏng lẻo vì thế cài đặt của
chúng có thể được thay đổi mà không ảnh hưởng
đến các đối tượng khác.
} Ngôn ngữ lập trình hướng đối tượng được sử dụng
rộng rãi.
} Tuy nhiên, giao diện đối tượng thay đổi có thể gây ra
nhiều vấn đề và các thực thể phức tạp có thể khó
biểu diễn thành các đối tượng.
Mô hình Đường ống hướng Chức năng
(Function-oriented pipelining)
24
} Là quá trình biến đổi chức năng, xử lý đầu vào của
chúng để tạo ra kết quả đầu ra.
} Còn được gọi là mô hình đường ống và bộ lọc (như shell
UNIX).
} Các biến thể của cách tiếp cận này rất phổ biến.
} Khi sự chuyển đổi là tuần tự, đây là một mô hình tuần tự
theo lô (batch) được sử dụng rộng rãi trong các hệ thống
xử lý dữ liệu.
} Không thực sự phù hợp với các hệ thống tương tác.
VD: Hệ thống xử lý hoá đơn
(Invoice processing system)
25
Lợi ích của mô hình đường ống
(Pipeline model advantages)
26
} Hỗ trợ tái sử dụng chuyển đổi.
} Tổ chức trực quan cho việc giao tiếp giữa các bên liên
quan.
} Dễ dàng thêm các biến đổi mới.
} Tương đối đơn giản để cài đặt như một hệ thống
đồng thời hoặc tuần tự.
} Tuy nhiên, mô hình này yêu cầu một định dạng chung
cho việc truyền dữ liệu dọc theo đường ống và khó
khăn để hỗ trợ sự tương tác dựa trên sự kiện.
1.2.3. Phong cách điều khiển
(Control styles)
27
} Liên quan đến luồng điều khiển giữa các hệ thống
con.
} Điều khiển tập trung (Centralised control)
} Một hệ thống con có trách nhiệm kiểm soát chung và có
quyền khởi động và ngừng các hệ thống con khác.
} Điều khiển dựa trên sự kiện (Event-based control)
} Mỗi hệ thống con có thể phản ứng các sự kiện bên ngoài
từ các hệ thống con khác hoặc từ môi trường của hệ
thống.
Điều khiển tập trung
(Centralised control)
28
} Một hệ thống con kiểm soát có trách nhiệm quản lý việc
thực hiện của các hệ thống con khác.
} Mô hình Gọi-Trả_về (Call-return model)
} Mô hình chương trình con điều khiển từ trên xuống dưới.
} Mô hình Nhà quản lý (Manager model)
} Một thành phần hệ thống điều khiển việc dừng, khởi động
và điều phối các hệ thống khác.
Mô hình Gọi-Trả_về
(Call-return model)
29
VD: Mô hình Nhà quản lý
Hệ thống thời gian thực
30
Điều khiển dựa trên hướng sự kiện
31
} Được kích hoạt bởi các sự kiện bên ngoài
} 2 mô hình hướng sự kiện chính:
1. Mô hình quảng bá (broadcast models). Sự kiện được
truyền tới tất cả các hệ thống con. Bất kỳ hệ thống con
nào có thể xử lý sự kiện này đều có thể thực hiện nó;
2. Mô hình hướng ngắt (interrupt-driven models). Được sử
dụng trong các hệ thống thời gian thực nơi mà các ngắt
được phát hiện bởi một trình xử lý ngắt và được truyền
cho một số thành phần khác để xử lý.
Mô hình Quảng bá
(Broadcast models)
32
} Các hệ thống con đăng ký sự quan tâm của mình
đến các sự kiện cụ thể.
} Khi những sự kiện này xảy ra, quyền kiểm soát
được chuyển cho hệ thống con có thể xử lý sự kiện
này.
} Tuy nhiên, các hệ thống con không biết liệu hay khi
nào một sự kiện sẽ được xử lý.
Quảng bá chọn lọc
(Selective broadcasting)
33
Hệ thống hướng ngắt
(Interrupt-driven systems)
34
} Được sử dụng trong các hệ thống thời gian thực khi
mà việc phản ứng nhanh với một sự kiện là điều tối
cần thiết.
} Mỗi loại ngắt được liên kết với một vị trí bộ nhớ và
một chuyển đổi phần cứng gây ra việc chuyển giao
cho trình xử lý của nó.
Điều khiển hướng ngắt
(Interrupt-driven control)
35
Tóm tắt các điểm chính 
(Key points)
36
} Kiến trúc phần mềm là khung nền tảng (fundamental
framework) để cấu trúc hệ thống.
} Các quyết định thiết kế kiến trúc bao gồm các quyết định
về kiến trúc ứng dụng, sự phân bố và các phong cách
kiến trúc được sử dụng.
} Các phong cách kiến trúc khác nhau như: phong cách tổ
chức hệ thống, phong cách chia nhỏ và phong cách điều
khiển có thể được phát triển.
} Các mô hình tổ chức hệ thống bao gồm: mô hình kho
lưu trữ, mô hình máy khách-máy chủ và mô hình
tầng/máy trừu tượng.
} Mô hình phân chia mô-đun bao gồm: mô hình đối tượng
và mô hình đường ống.
} Các mô hình điều khiển bao gồm: mô hình điều khiển tập
trung và mô hình điều khiển hướng sự kiện.
2. Thiết kế hướng đối tượng
Object-oriented design
37
Mục tiêu
38
} Giải thích cách một thiết kế phần mềm có thể được
biểu diễn bằng một tập các đối tượng tương tác để
quản lý trạng thái và hoạt động của chúng
} Miêu tả các hoạt động trong quá trình thiết kế hướng
đối tượng
} Giới thiệu các mô hình khác nhau có thể được sử
dụng để miêu tả một thiết kế hướng đối tượng
} Chỉ ra cách UML có thể được sử dụng để biểu diễn
cho các mô hình này
Chủ đề được đề cập
(Topics covered)
39
} Đối tượng và Lớp đối tượng
} Một quy trình thiết kế hướng đối tượng
Phát triển hướng đối tượng
(Object-oriented development)
40
} Phân tích, thiết kế và lập trình hướng đối tượng có
liên quan nhưng khác biệt
} OOA liên quan đến việc phát triển một mô hình đối
tượng của miền ứng dụng.
} OOD liên quan đến việc phát triển một mô hình hệ
thống hướng đối tượng để cài đặt các yêu cầu.
} OOP liên quan đến việc thực hiện một OOD bằng
cách sử dụng một ngôn ngữ lập trình OO như Java
hay C ++.
Đặc điểm và Ưu điểm của OOD
(Characteristics & Advantages of OOD)
41
} Đặc điểm:
} Đối tượng là khái niệm trừu tượng của thực thể tổ chức
hoặc trong thực tế và chúng tự quản lý chính mình.
} Đối tượng là độc lập và đóng gói thông tin miêu tả và
trạng thái.
} Chức năng của hệ thống được thể hiện dưới dạng các
dịch vụ của đối tượng.
} Các đối tượng giao tiếp bằng việc truyền thông điệp.
} Ưu điểm:
} Bảo trì dễ dàng hơn.
} Đối tượng là các thành phần tái sử dụng tiềm năng.
Đối tượng tương tác
(Interacting objects)
42
Đối tượng và Lớp đối tượng
(Objects and object classes)
43
} Đối tượng là một thực thể trong một hệ thống phần
mềm biểu diễn các trường hợp cụ thể của các thực
thể trong thế giới thực và hệ thống.
} Lớp đối tượng là các khuôn mẫu cho các đối tượng.
Chúng có thể được sử dụng để tạo ra đối tượng.
} Lớp đối tượng có thể kế thừa các thuộc tính và dịch vụ từ
các lớp đối tượng khác.
UML
(Unified Modeling Language)
44
} Nhiều ký hiệu khác nhau để miêu tả thiết kế hướng
đối tượng đã được đề xuất trong những năm 1980
và 1990.
} UML là một tích hợp của các ký hiệu này
} Miêu tả ký hiệu cho một số mô hình khác nhau có thể
được tạo ra trong quá trình phân tích và thiết kế OO.
} Bây giờ nó là một tiêu chuẩn trên thực tế (de facto) cho
mô hình hóa OO.
VD: Lớp đối tượng Nhân viên - UML
(Employee object class)
45
Giao tiếp giữa Đối tượng
(Object communication)
46
} Về mặt lý thuyết, các đối tượng giao tiếp bằng việc
truyền thông điệp.
} Thông điệp (messages)
} Tên của dịch vụ được yêu cầu bởi đối tượng gọi;
} Bản sao của thông tin được yêu cầu để thực hiện dịch vụ
và tên của đối tượng giữ cho kết quả của dịch vụ.
} Trong thực tế, thông điệp thường được cài đặt bằng
các lời gọi hàm
} Tên = tên hàm;
} Thông tin = danh sách tham số.
VD: Thông điệp
47
// Gọi một phương thức kết hợp với một đối tượng
// bộ đệm trả về giá trị tiếp theo trong bộ đệm
v = circularBuffer.Get();
// Gọi phương thức liên kết với một đối tượng điều
// chỉnh nhiệt để đặt nhiệt độ duy trì ở mức 20
thermostat.setTemp(20);
Tổng quát hóa và Kế thừa
(Generalisation and inheritance)
48
} Các lớp có thể được sắp xếp trong một hệ thống cấp
bậc của lớp,
} Trong đó một lớp (một siêu lớp – lớp cha) là sự tổng quát
của một hoặc nhiều lớp khác (các lớp con).
} Một lớp con kế thừa các thuộc tính và hành động từ
lớp cha của nó và có thể thêm các phương thức
hoặc thuộc tính mới của riêng nó.
} Sự tổng quát hóa trong UML được cài đặt bằng khái
niệm thừa kế trong các ngôn ngữ lập trình OO.
VD: Một Hệ thống Phân cấp
49
Ưu điểm và Nhược điểm của Kế thừa
50
} Ưu điểm
} Là một cơ chế trừu tượng có thể được sử dụng để phân
loại thực thể.
} Là một cơ chế tái sử dụng ở cả mức thiết kế và lập trình.
} Đồ thị thừa kế là một nguồn kiến thức tổ chức về các lĩnh vực
và hệ thống.
} Nhược điểm
} Các lớp đối tượng không thể hiểu được mà không tham
khảo đến các lớp cha.
} Đồ thị thừa kế của quá trình phân tích, thiết kế và cài đặt
có các chức năng khác nhau và cần được duy trì riêng
biệt.
Liên kết trong UML
(UML associations)
51
} Đối tượng và lớp đối tượng tham gia vào các
mối quan hệ với đối tượng và lớp đối tượng
khác.
} Trong UML, một mối quan hệ tổng quát được
biểu diễn bằng một liên kết.
} Các liên kết có thể được chú thích với thông tin
miêu tả về liên kết đó.
VD: Mô hình liên kết
52
Mối Quan hệ giữa các Lớp đối tượng
53
Quy trình Thiết kế hướng đối tượng
(Object-oriented design process)
54
1. Xác định bối cảnh và phương thức sử dụng
của hệ thống;
2. Thiết kế kiến trúc hệ thống;
3. Xác định các đối tượng hệ thống chính;
4. Phát  ... iết
(Weather station architecture)
63
Q3. Nhận dạng Đối tượng
(Object identification)
64
} Xác định đối tượng (hoặc các lớp đối tượng) là phần
khó nhất của thiết kế hướng đối tượng.
} Không có 'công thức kỳ diệu' để nhận dạng đối
tượng.
} Nó dựa vào các kỹ năng, kinh nghiệm và kiến thức miền
của những nhà thiết kế hệ thống.
} Nhận dạng đối tượng là một quá trình lặp. Bạn
không thể làm cho nó đúng ngay trong bước đầu
tiên.
Phương pháp tiếp cận để nhận dạng
(Approaches to identification)
65
} Sử dụng cách tiếp cận ngữ pháp dựa trên mô tả
ngôn ngữ tự nhiên của hệ thống (sử dụng trong
phương pháp Hood OOD).
} Dựa trên việc nhận dạng các vật hữu hình trong miền
ứng dụng.
} Sử dụng cách tiếp cận hành vi và xác định các đối
tượng dựa trên những ai tham gia vào hành vi nào.
} Sử dụng một phân tích dựa trên kịch bản. Các đối
tượng, thuộc tính và phương pháp trong từng kịch
bản được xác định.
Xét Mô tả về Trạm thời tiết
(Weather station description)
66
Một trạm thời tiết là một gói các công cụ phần mềm
điều khiển để thu thập dữ liệu, thực hiện một số xử
lý dữ liệu và truyền dữ liệu này cho các bước xử lý
tiếp theo. Các thiết bị bao gồm nhiệt kế không khí và
mặt đất, máy đo nhiệt độ, cánh gió, áp kế và đo
mưa. Dữ liệu được thu thập định kỳ.
Khi một lệnh được phát ra để truyền dữ liệu thời tiết,
trạm thời tiết xử lý và tóm tắt dữ liệu thu thập được.
Dữ liệu tóm tắt được truyền tới máy tính lập bản đồ
khi nhận được yêu cầu phát sinh từ máy tính đó.
Các lớp đối tượng của trạm thời tiết (1/2)
(Weather station object classes)
67
} Nhiệt kế mặt đất, Phong kế, Phong vũ biểu (Ground
thermometer, Anemometer, Barometer)
} Các đối tượng miền ứng dụng là các đối tượng 'phần
cứng' liên quan đến các thiết bị trong hệ thống.
} Trạm thời tiết
} Giao diện cơ bản của trạm khí tượng với môi trường của
nó. Do đó nó phản ánh các tương tác được định nghĩa
trong mô hình use-case.
} Dữ liệu thời tiết
} Đóng gói dữ liệu tóm tắt từ các thiết bị.
Các lớp đối tượng của trạm thời tiết (2/2)
(Weather station object classes)
68
Q4. Các mô hình thiết kế
(Design models)
69
} Mô hình thiết kế hiển thị đối tượng và lớp đối tượng
và mối quan hệ giữa các thực thể này.
} Mô hình tĩnh miêu tả cấu trúc tĩnh của hệ thống dưới
dạng các lớp đối tượng và các mối quan hệ.
} Mô hình động miêu tả sự tương tác động giữa các
đối tượng.
VD Các Mô hình Thiết kế
(Examples of design models)
70
} Mô hình hệ thống con (Sub-system models): thể hiện
các nhóm lô gic của các đối tượng trong các hệ
thống con mạch lạc.
} Mô hình trình tự (Sequence models): thể hiển chuỗi
tương tác giữa các đối tượng.
} Mô hình trạng thái: thể hiển cách đối tượng đơn
thay đổi trạng thái của chúng để phản ứng với các
sự kiện.
} Các mô hình khác bao gồm mô hình use-case, mô hình
tập hợp (aggregation), mô hình tổng quát (generalisation),
v.v.
Mô hình hệ thống con
(Sub-system models)
71
} Chỉ ra cách thiết kế được tổ chức thành các nhóm
đối tượng liên quan.
} Trong UML, chúng được thể hiển bằng các gói
(packages) - một cấu trúc đóng gói. Đây là một mô
hình logic. Việc tổ chức thực sự của các đối tượng
trong hệ thống có thể khác nhau.
Hệ thống con trạm thời tiết
(Weather station subsystems)
72
Mô hình trình tự
(Sequence models)
73
} Các mô hình trình tự hiển thị chuỗi tương tác giữa các
đối tượng xảy ra:
} Các đối tượng được sắp xếp ở hàng ngang trên cùng;
} Thời gian được biểu diễn theo chiều dọc vì vậy các mô
hình được đọc từ trên xuống dưới;
} Tương tác được biểu diễn bằng mũi tên có nhãn, Các
kiểu mũi tên khác nhau biểu thị các loại tương tác khác
nhau;
} Một hình chữ nhật mỏng trên vòng đời của đối tượng biểu
diễn thời gian khi đối tượng là thực thể đang kiểm soát
trong hệ thống.
Trình tự thu thập dữ liệu
(Data collection sequence)
74
Biểu đồ trạng thái
(Statecharts)
75
} Chỉ ra cách đối tượng phản ứng với các yêu cầu
dịch vụ khác nhau và sự chuyển tiếp trạng thái được
kích hoạt bởi các yêu cầu này
} Nếu trạng thái đối tượng là Shutdown thì nó trả lời một
thông báo Startup();
} Trong trạng thái chờ đợi, đối tượng đang chờ các thông
điệp về sau;
} Nếu reportWeather() thì sau đó hệ thống di chuyển đến
trạng thái tổng kết;
} Nếu calibrate() hệ thống sẽ chuyển sang trạng thái hiệu chỉnh;
} Một trạng thái thu thập được kích hoạt khi nhận được một
tín hiệu đồng hồ.
Sơ đồ trạng thái trạm thời tiết
(Weather station state diagram)
76
Q5. Đặc tả giao diện đối tượng
(Object interface specification)
77
} Giao diện đối tượng phải được xác định sao cho các
đối tượng và các thành phần khác có thể được thiết
kế song song.
} Đối tượng có thể có một số giao diện về quan điểm
với các phương pháp được cung cấp.
} UML sử dụng sơ đồ lớp cho các đặc tả giao diện
nhưng ngôn ngữ Java cũng có thể được sử dụng.
Giao diện trạm thời tiết
(Weather station interface)
78
Tóm tắt các điểm chính 
(Key points)
79
} OOD là một cách tiếp cận để thiết kế các thành phần có
trạng thái và hoạt động riêng của chúng.
} Đối tượng phải có các hoạt động khởi tạo và kiểm tra.
Chúng cung cấp dịch vụ cho các đối tượng khác.
} Đối tượng có thể được cài đặt tuần tự hoặc đồng thời.
} UML cung cấp các ký hiệu khác nhau để định nghĩa các
mô hình đối tượng khác nhau.
} Một khoảng các mô hình khác nhau có thể được sản
xuất trong quá trình thiết kế hướng đối tượng. Chúng
bao gồm các mô hình hệ thống tĩnh và động.
} Giao diện đối tượng phải được định nghĩa chính xác, có
thể bằng cách sử dụng một ngôn ngữ lập trình như Java.
3. Thiết kế
Giao diện người dùng
User interface design
80
Mục tiêu
81
} Đề xuất một số nguyên tắc thiết kế chung cho thiết
kế giao diện người dùng
} Giải thích các phong cách tương tác khác nhau và
cách sử dụng của chúng
} Giải thích khi nào sử dụng biểu diễn thông tin dạng
đồ họa và văn bản
} Giải thích các hoạt động chính trong quá trình thiết
kế giao diện người dùng
} Giới thiệu các thuộc tính khả dụng và cách tiếp cận
để đánh giá hệ thống
Các chủ đề được đề cập
(Topics covered)
82
} Quá trình thiết kế giao diện người dùng
} Phân tích người dùng
} Nguyên mẫu giao diện người dùng
} Đánh giá giao diện
Giao diện người dùng
83
} Giao diện người dùng nên được thiết kế để phù hợp
với kỹ năng, kinh nghiệm và mong đợi của những
người dùng dự kiến.
} Người dùng hệ thống thường đánh giá một hệ thống
qua giao diện hơn là chức năng của nó.
} Một giao diện được thiết kế tồi có thể khiến người
dùng tạo ra một lỗi thảm họa.
} Thiết kế giao diện người dùng kém là lý do tại sao
rất nhiều hệ thống phần mềm không bao giờ được
sử dụng.
Yếu tố con người trong thiết kế giao diện
(Human factors in interface design)
84
} Bộ nhớ ngắn hạn (Limited short-term memory)
} Mọi người có thể ngay lập tức nhớ khoảng 7 thông tin.
Nếu bạn trình bày nhiều hơn số này, họ thường mắc sai
lầm nhiều hơn.
} Con người dễ mắc sai lầm
} Khi mọi người mắc sai lầm và hệ thống xử lý sai, các báo
động và thông điệp không thích hợp có thể làm tăng căng
thẳng và do đó lại khiến khả năng mắc nhiều lỗi hơn.
} Mọi người là khác nhau
} Con người có nhiều khả năng thể chất vật lý. Người thiết
kế nên không chỉ thiết kế cho khả năng của bản thân
mình.
} Mọi người có sở thích tương tác khác nhau
} Một số giống như hình ảnh, một số giống như văn bản.
Nguyên tắc thiết kế giao diện người dùng (1/2)
(UI design principles)
85
} Thiết kế UI phải tính đến nhu cầu, kinh nghiệm và
khả năng của người sử dụng hệ thống.
} Người thiết kế nên nhận thức được những hạn chế
về thể chất và tinh thần của con người (ví dụ như bộ
nhớ ngắn hạn) và phải nhận ra rằng mọi người đều
mắc phải sai lầm.
Nguyên tắc thiết kế giao diện người dùng (2/2)
(UI design principles)
86
Nguyên tắc Miêu tả
Thân thiện người dùng
(User familiarity)
Giao diện nên sử dụng thuật ngữ và khái niệm
được rút ra từ kinh nghiệm của những người chính
của hệ thống.
Tính nhất quán
(Consistency)
Giao diện phải nhất quán trong đó, nếu có thể, các
hoạt động giống nhau phải được kích hoạt theo cùng
một cách.
Ít gây ngạc nhiên
(Minimal surprise)
Người dùng không nên bị ngạc nhiên trước một
hành vi của hệ thống
Khả năng phục hồi
(Recoverability)
Giao diện nên bao gồm các cơ chế để cho phép
người dùng khôi phục lại từ các lỗi.
Hướng dẫn người dùng
(User guidance)
Giao diện nên cung cấp phản hồi có ý nghĩa khi xảy
ra lỗi và cung cấp các phương tiện trợ giúp người
dùng.
Đa dạng người dùng
(User diversity)
Giao diện nên cung cấp các phương tiện tương tác
thích hợp với từng loại người dùng hệ thống.
Phong cách tương tác
(Interaction styles)
87
Phong cách
tương tác
Ưu điểm 
chính
Nhược điểm chính Ví dụ
ứng dung
Thao tác 
trực tiếp
Tương tác nhanh và
trực quan
Dễ học
Có thể khó cài đặt.
Chỉ thích hợp khi có phép ẩn dụ
trực quan cho các tác vụ và đối
tượng.
Trò chơi điện tử
Hệ thống CAD
Lựa chọn 
menu
Tránh lỗi người dùng
Yêu cầu phải gõ ít
Chậm với người dùng có kinh
nghiệm.
Có thể trở nên phức tạp nếu có
nhiều lựa chọn trong menu.
Hầu hết các hệ thống 
mục đích chung
Điền vào biểu 
mẫu
Nhập dữ liệu đơn
giản
Dễ học
Kiểm tra được
Chiếm nhiều không gian màn
hình.
Gây ra vấn đề khi các tùy chọn
người dùng không khớp với các
trường biểu mẫu.
Kiểm soát chứng khoán, 
xử lý khoản vay cá nhân
Ngôn ngữ
mệnh lệnh
Mạnh mẽ và linh hoạt Khó học.
Quản lý lỗi kém.
Hệ điều hành, Hệ thống 
chỉ huy và điều khiển
Ngôn ngữ tự
nhiên
Khả dụng cho người
dùng bình thường
Dễ dàng mở rộng
Yêu cầu gõ nhiều hơn.
Hệ thống hiểu biết ngôn ngữ tự
nhiên không đáng tin cậy.
Hệ thống thu thập thông 
tin
Giao diện nhiều người dùng
(Multiple user interfaces)
88
Tương tác với hệ thống LIBSYS
(LIBSYS interaction)
89
} Tìm kiếm tài liệu
} Người dùng cần có khả năng sử dụng các tính năng tìm
kiếm để tìm các tài liệu họ cần.
} Yêu cầu tài liệu
} Người dùng yêu cầu một tài liệu được gửi đến máy của
họ hoặc đến một máy chủ để in.
Giao diện mẫu cho chức năng tìm kiếm LIBSYS
(LIBSYS search form)
90
Biểu diễn thông tin (1/3)
(Information presentation)
91
} Biểu diễn thông tin liên quan đến việc trình bày thông
tin hệ thống cho người dùng.
} Thông tin có thể được trình bày trực tiếp (ví dụ: văn
bản trong bộ xử lý văn bản) hoặc có thể được
chuyển đổi theo cách nào đó để biểu diễn (ví dụ: ở
dạng đồ hoạ).
} Cách tiếp cận Mô_hình-Góc_nhìn-Điều_khiển
(Model-View-Controller) là một cách để hỗ trợ nhiều
kiểu biểu diễn cho dữ liệu.
Biểu diễn thông tin (2/3)
(Information presentation)
92
Biểu diễn thông tin (3/3)
(Information presentation)
93
} Thông tin tĩnh
} Được khởi tạo vào đầu phiên (session). Nó không thay đổi
trong phiên.
} Thông tin động
} Thay đổi trong phiên và những thay đổi phải được thông
báo cho người sử dụng hệ thống.
Một số phương pháp biểu diễn dữ liệu (1/2) 
94
Một số phương pháp biểu diễn dữ liệu (2/2)
95
Hiển thị màu sắc
(Colour displays)
96
} Màu sắc bổ sung thêm thông tin cho một giao diện
và có thể giúp người sử dụng hiểu các cấu trúc
thông tin phức tạp.
} Màu sắc có thể được sử dụng để làm nổi bật các sự
kiện đặc biệt.
} Sai lầm phổ biến trong việc sử dụng màu sắc trong
thiết kế giao diện bao gồm:
} Sử dụng quá mức màu sắc trong hiển thị.
} Hướng dẫn sử dụng màu sắc:
} Hạn chế số lượng màu được sử dụng.
} Sử dụng sự thay đổi màu sắc để hiển thị thay đổi trạng
thái hệ thống.
Thông báo lỗi
(Error messages)
97
} Thiết kế thông báo lỗi rất quan trọng. Thông báo lỗi
tồi có thể khiến người dùng từ chối hệ thống.
} Nền tảng và kinh nghiệm của người sử dụng nên là
yếu tố quyết định trong thiết kế thông báo.
} Thông báo phải: lịch sự, súc tích, nhất quán và xây dựng.
} Các nhân tố thiết kế trong cách diễn đạt thông báo:
} Ngữ cảnh (context)
} Kinh nghiệm (experience)
} Kỹ năng (skill)
} Phong cách (style)
} Văn hóa (culture)
Ví dụ về Lỗi người dùng
(User error)
98
} Giả sử một y tá đánh sai tên của một bệnh nhân mà
cô ta đang cố gắng để tìm hồ sơ
Thiết kế thông điệp tồi và tốt
(Good and bad message design)
99
Quá trình thiết kế giao diện người dùng
(UI design process)
100
} Thiết kế giao diện người dùng là một quá trình lặp
liên quan đến mối quan hệ chặt chẽ giữa người
dùng và nhà thiết kế.
} 3 hoạt động cốt lõi trong quá trình này là:
} Phân tích người dùng. Hiểu được những gì người dùng
sẽ làm với hệ thống;
} Tạo nguyên mẫu hệ thống. Phát triển một loạt các
nguyên mẫu để thử nghiệm;
} Đánh giá giao diện. Thử nghiệm với những nguyên mẫu
này với người dùng.
Quá trình thiết kế giao diện người dùng
(Design process)
101
Phân tích người dùng
(User analysis)
102
} Các phân tích của người dùng phải được miêu tả
theo cách mà cả người dùng và nhà thiết kế khác
đều có thể hiểu.
} Các kịch bản mà bạn miêu tả các giai đoạn sử dụng
tiêu biểu là một cách để miêu tả các phân tích này.
} Một vài kỹ thuật phân tích
} Phân tích tác vụ: Mô hình các bước liên quan đến việc
hoàn thành một tác vụ
} Phỏng vấn và bảng câu hỏi: Hỏi người dùng về công việc họ
làm.
} Nhân chủng học:Quan sát người dùng tại nơi làm việc.
Tạo nguyên mẫu giao diện người dùng
(User interface prototyping)
103
} Mục đích của việc tạo nguyên mẫu là cho phép
người dùng có được kinh nghiệm trực tiếp với giao
diện.
} Nếu không có kinh nghiệm trực tiếp như vậy, không
thể đánh giá khả năng sử dụng của một giao diện.
} Tạo nguyên mẫu có thể là một quá trình hai giai
đoạn:
} Ban đầu, nguyên mẫu trên giấy có thể được sử dụng;
} Thiết kế sau đó được tinh chế và các nguyên mẫu tự
động tinh vi hơn được phát triển.
Đánh giá giao diện người dùng
(User interface evaluation)
104
} Đánh giá quy mô đầy đủ là rất tốn kém và không
thực tế đối với hầu hết các hệ thống.
} Lý tưởng nhất là một giao diện nên được đánh giá
dựa trên một đặc tả tính khả dụng.
} Các thuộc tính khả dụng:
} Tính dễ học
} Tốc độ hoạt động
} Độ bền (robustness)
} Khả năng phục hồi (recoverability )
} Khả năng thích ứng (adaptability )
Tóm tắt các điểm chính 
(Key points)
105
} Các nguyên tắc thiết kế giao diện người dùng sẽ giúp hướng dẫn
thiết kế các giao diện người dùng.
} Các kiểu tương tác bao gồm: thao tác trực tiếp, các hệ thống menu,
điền vào mẫu, ngôn ngữ lệnh và ngôn ngữ tự nhiên.
} Hiển thị đồ họa nên được sử dụng để biểu thị các xu hướng và các
giá trị gần đúng.
} Màu sắc nên được sử dụng một cách tiết kiệm và nhất quán.
} Quá trình thiết kế giao diện người dùng liên quan đến: việc phân
tích người dùng, tạo nguyên mẫu hệ thống và đánh giá nguyên
mẫu.
} Mục đích của việc phân tích người dùng là để các nhà thiết kế hiểu
cách người dùng thực sự làm việc.
} Việc tạo mẫu giao diện người dùng phải là một quy trình được phân
đoạn với các nguyên mẫu giấy ban đầu được sử dụng làm cơ sở
cho nguyên mẫu tự động của giao diện.
} Mục tiêu của việc đánh giá giao diện người dùng là lấy thông tin
phản hồi về cách cải tiến thiết kế giao diện và đánh giá xem giao
diện có đáp ứng các yêu cầu về tính hữu dụng của nó hay không.
Tài liệu Tham khảo
106
} Giáo trình chính: Software Engineering, Ian
Sommerville, 8th Edition, 2007
} Tham khảo:
} Object-Oriented Software Engineering Practical Software
Development using UML and Java, Lloseng.com,
Lethbridge/Laganièr, 2001
} Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm,
PhạmThị Quỳnh