Thiết kế phần mềm
(Software Design)
†CƠ SỞ CỦA THIẾT KẾ PHẦN MỀM
†GIAO DIỆN & TƯƠNG TÁC NGƯỜI DÙNG
†PHƯƠNG PHÁP THIẾT KẾ CỔ ĐIỂN
†PHƯƠNG PHÁP THIẾT KẾ OOP


Thiết kế phần mềm
† Thiết kế phần mềm là công việc đầu tiên của
giai đoạn phát triển
† Thiết kế tạo ra các biểu diễn và dữ kiện của hệ
thống phần mềm cần xây dựng từ kết quả
phân tích yêu cầu để có thể dễ dàng hiện thực
sau đó
† Thiết kế tạo ra phương thức và quy trình
tương tác giữa người dùng với hệ thống phần
mềm cũng như tương tác giữa các hệ thống
khác với phần mềm.
Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

2


Principles for software design
† The design process should not suffer from “tunnel
vision.”
„ A good designer should consider alternative approaches, judging
each based on the requirements of the problem, the resources
available to do the job, and the design concepts presented in next

sections

† The design should be traceable to the analysis model.
„ Because a single element of the design model often traces to
multiple requirements, it is necessary to have a means for tracking
how requirements have been satisfied by the design model.

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

3


Principles for software design (cont.)
† The design should not reinvent the wheel.
† The design should “minimize the intellectual distance”
between the software and the problem as it exists in
the real world.
„ That is, the structure of the software design should (whenever
possible) mimic the structure of the problem domain

† The design should exhibit uniformity and integration
„ A design is uniform if it appears that one person developed the entire
thing. Rules of style and format should be defined for a design team
before design work begins.
„ A design is integrated if care is taken in defining interfaces between
design components.
Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –


4


Principles for software design (cont.)
† The design should be structured to accommodate
change
† The design should be structured to degrade gently,
even when aberrant data, events, or operating
conditions are encountered
† Design is not coding, coding is not design
„ Even when detailed procedural designs are created for program
components, the level of abstraction of the design model is higher
than source code.

† The design should be assessed for quality as it is being
created, not after the fact
† The design should be reviewed to minimize conceptual
(semantic) errors
Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

5


Trừu tượng hóa
Quá trình thiết kế trải qua nhiều mức trừu tượng hoá khác
nhau
† Mức cao nhất: vấn đề cần thiết kế được mô tả một
cách tổng quát sử dụng thuật ngữ hướng vấn đề
† Các mức thấp hơn: hướng đến thủ tục xử lý chi tiết;

kết hợp các thuật ngữ hướng đến hiện thực
† Mức thấp nhất: vấn đề được mô tả theo cách có thể
hiện thực trực tiếp
† Phân loại trừu tượng hoá: thủ tục và dữ liệu

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

6


Trừu tượng hóa
† Trừu tượng hoá thủ tục: là chuỗi các lệnh liên tiếp
thực hiện chức năng nào đó.
Ví dụ: mở cửa (bao gồm đi đến cửa, cầm lấy tay nắm, xoay tay
nắm, kéo cánh cửa, đi vào…); thêm một phần tử vào danh sách
có thứ tự (xác định vị trí, chèn phần tử mới)

† Trừu tượng hoá dữ liệu: là tổ hợp dữ liệu mô tả một
đối tượng dữ liệu (liên hệ tới đối tượng thực thể trong
UML). Ví dụ: hàng, chồng, cánh cửa...
† Một số ngôn ngữ lập trình hỗ trợ kiểu ADT và
template

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

7



Trừu tượng hóa (tt.)
† Control abstraction:
„ Like procedural and data abstraction, control abstraction implies a
program control mechanism without specifying internal details.
„ An example of a control abstraction is the synchronization
semaphore used to coordinate activities in an operating system.

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

8


Tinh chế
† Tinh chế là quá trình làm rõ vấn đề
† Tinh chế và trừu tượng hoá là hai khái niệm bù trừ
nhau: càng tinh chế thì càng hạ thấp mức trừu tượng
hoá
† Thiết kế phần mềm: trừu tượng hóa rồi tinh chế hoá.
† Tại sao?
† Note: Abstraction and Refinement concepts aid the
designer in creating a complete design model as the
design evolves.

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

9



Thiết kế giao diện người dùng
† Phần mềm cần có giao diện thân thiện với người sử
dụng
† Một số tiêu chuẩn giao diện
„ Thời gian đáp ứng của hệ thống: giá trị trung bình và độ
lệch
„ Phương tiện trợ giúp người sử dụng: tích hợp + add-on
„ Kiểm soát thông tin lỗi: hiện thị cả nguyên nhân lỗi và
cách khắc phục
„ Đặt tên nhãn: ngắn gọn và gợi nhớ
„ Read more in Software Engineering – A Pratitioner
Approach. Chapter 15
† Thường dùng các công cụ thiết kế giao diện
Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

10


The User Interface Design Process

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

11


The User Interface Design Process
(cont.)
† The initial analysis activity focuses on the profile of the users who

will interact with the system. Skill level, business understanding,
and general receptiveness to the new system are recorded; and
different user categories are defined. For each user category,
requirements are elicited
† Once general requirements have been defined, a more detailed
task analysis is conducted
„
„
„
„

Where will the interface be located physically?
Will the user be sitting, standing, or performing other tasks unrelated to the
interface?
Does the interface hardware accommodate space, light, or noise constraints?
Are there special human factors considerations driven by environmental
factors?

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

12


The User Interface Design Process
(cont.)
† The information gathered above as part of the analysis
activity is used to create an analysis model for the
interface. Using this model as a basis, the design
activity commences.

† The goal of interface design is to define a set of
interface objects and actions (and their screen
representations) that enable a user to perform all
defined tasks in a manner that meets every usability
goal defined for the system

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

13


The User Interface Design Process
(cont.)
† The implementation activity normally begins with the
creation of a prototype that enables usage scenarios to
be evaluated. As the iterative design process
continues, a user interface tool kit may be used to
complete the construction of the interface.
† Validation focuses on
„ the ability of the interface to implement every user task
correctly, to accommodate all task variations, and to achieve
all general user requirements;
„ the degree to which the interface is easy to use and easy to
learn;
„ the users’ acceptance of the interface as a useful tool in their
work.
Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –


14


The User Interface Design Process
(cont.)

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

15


INTERFACE DESIGN ACTIVITIES
† Establish the goals and intentions for each task
† Map each goal and intention to a sequence of specific actions
† Specify the action sequence of tasks and subtasks, also called a
user scenario, as it will be executed at the interface level
† Indicate the state of the system; that is, what does the interface
look like at the time that a user scenario is performed?
† Define control mechanisms; that is, the objects and actions
available to the user to alter the system state
† Show how control mechanisms affect the state of the system.
† Indicate how the user interprets the state of the system from
information provided through the interface

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

16



Công cụ thiết kế giao diện
Công cụ thiết kế giao diện nên có những tính năng sau
† Quản lý thiết bị nhập (bàn phím, chuột)
† Hiệu chỉnh thông tin input
† Kiểm soát lỗi và hiển thị thông báo lỗi
† Cung cấp trợ giúp và hiển thị thông báo nhắc nhở
† Cung cấp feedback (ví dụ như tự động hiển thị ký tự đánh vào)
† Kiểm soát cửa sổ và vùng, khả năng cuộn
† Thiết lập giao tiếp giữa chương trình với giao diện (vd: hàm đáp ứng)
† Cách ly chương trình với các hàm quản lý giao diện
† Cho phép tuỳ biến giao diện: màu sắc, kích thước,..
†

Note: These functions can be implemented using either a languagebased or graphical approach.

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

17


Một số định hướng về thiết kế giao diện
Một số hướng dẫn chung
† Nên đồng nhất (menu, lệnh, hiển thị...)
† Nên cung cấp feedback cho người dùng
† Yêu cầu xác nhận những tác vụ mang tính phá hoại (xoá file,
account)
† Nên hỗ trợ UNDO, REDO
† Hạn chế lượng thông tin phải ghi nhớ giữa 2 tác vụ liên tiếp

† Tối ưu trong trình bày hộp thoại và di chuyển mouse
† Chấp nhận lỗi từ phía người sử dụng
† Cung cấp trợ giúp trực tuyến
† Dùng động từ đơn giản và ngắn gọn để đặt tên các lệnh

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

18


Một số định hướng về thiết kế giao diện
Đối với thông tin hiển thị
† Chỉ hiển thị những thông tin phù hợp với ngữ cảnh
hiện tại
† Dùng tên, từ viết tắt và màu gợi nhớ
† Cho phép tương tác trực quan
† Tạo thông báo lỗi có ý nghĩa
† Hiển thị dữ liệu ở nhiều dạng khác nhau trong cửa sổ
† Thiết lập biểu diễn tương tự
† Sử dụng không gian màn hình một cách tối ưu

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

19


Một số định hướng về thiết kế giao diện
Đối với thông tin input

† Hạn chế input trực tiếp (có thể chọn lựa từ một số dữ
liệu có sẵn)
† Nên đồng nhất giữa thông tin input và hiển thị
† Nên cho phép tuỳ biến input
† Cấm các chức năng không thích hợp trong ngữ cảnh
hiện tại
† Cho phép input ở nhiều dạng khác nhau
† Để cho người sử dụng kiểm soát dòng sự kiện tương
tác
† Tự động tính các giá trị input cho người sử dụng nếu
có thể
Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

20


Thiết kế phần mềm

Phương pháp lập trình cấu trúc

Module hoá chương trình
Phân chia module
Kiến trúc phần mềm
Thiết kế dữ liệu


Thiết kế phần mềm cổ điển

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin

Copyright 2004 – Th.S Nguyễn Cao Trí –

22


Thiết kế phần mềm cổ điển
† Các công đoạn trong thiết kế phần mềm cổ
điển
„
„
„
„
„

Phân chia module
Thiết kế dữ liệu
Thiết kế kiến trúc
Thiết kế thủ tục
Thiết kế giao diện

† Phần mềm phát triển theo mô hình cổ điển:
quan tâm đến cấu trúc và giải thuật của các module

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

23


PHÂN CHIA MODULE

† Module là gì?
† Khái niệm module đã xuất hiện khoảng 4 thập niên trở lại
đây.
† Phần mềm được xây dựng bằng cách phân chia thành nhiều
module, sau đó sẽ được tích hợp lại
† Phân chia module làm cho việc quản lý phần mềm khoa học
hơn
† Giả sử C(x): độ phức tạp của x, E(x): công sức để thực hiện
x. Rõ ràng: nếu C(p1) > C(p2) thì E(p1) > E(p2).
† Nếu phân chia p = p1 + p2 ta thấy (một cách trực quan):
C(p1 + p2) > C(p1) + C(p2) Æ E(p1 + p2) > E(p1) + E(p2)

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

24


Công sức bỏ ra

Phân chia module như thế nào?

Công sức tích hợp

† Số lượng
module phụ
thuộc vào độ
Tổng công sức phát triển phức tạp của
hệ thống
phần mềm

Vùng tối ưu
cần xây
dựng
† Quá ít hoặc
quá nhiều
module đều
không tốt
Tổng công sức từng module
Số lượng module

Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí –

25