THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM - Chương 2 Thiết kế phần mềm potx

THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM
(SOFTWARE DESIGN AND CONSTRUCTION)
Năm học 2008-2009

Giáo viên: PGS.Huỳnh Quyết Thắng
BM Công nghệ phần mềm
Khoa CNTT, ĐHBK HN

1


Chương 2. Thiết kế phần mềm (Software Design)
1.
2.

3.
4.

5.
6.

Các khái niệm căn bản trong thiết kế phần mềm
Thiết kế kiến trúc phần mềm (Software Architectrure
Design)
Các chiến thuật và phương pháp thiết kế phần mềm
Xây dựng các đặc tả thiết kế phần mềm (Software
Design Specification)
Giới thiệu một số tài liệu liên quan đến nội dung chương
Câu hỏi và bài tập

2

2.1. Các khái niệm cơ bản trong thiết kế phần mềm
•
•
•
•

Khái niệm
Nhiệm vụ
Quy trình
Các kỹ thuật trong thiết kế phần mềm

3


2.1. Các khái niệm cơ bản trong thiết kế phần mềm
•

•
•

Khái niệm: Thiết kế phần mềm được định nghĩa trong
IEEE610.12-90 bao gồm: Quá trình xác định kiến trúc,
các thành phần, giao diện và các đặc tính kỹ thuật của
hệ thống hoặc thành phần .
Thiết kế phần mềm sẽ là cơ sỏ cho giai đoạn tiếp theo
là xây dựng phần mềm.
Thiết kế phần mềm đóng vai trị quan trọng trong phát
triển phần mềm:

• Cho phép xem xét, so sánh các phương án kỹ thuật
khác nhau trong thiết kế phần mềm
• Cho phép xác định phương án phù hợp nhất với các
yêu cầu phần mềm
• Cho phép lập các kế hoạch chi tiết cho giai đoạn xây
dựng phần mềm
4


2.1. Các khái niệm cơ bản trong thiết kế phần mềm
•

Nhiệm vụ: Theo IEEE/EIA 12207 Software Life

Cycle Processes và [IEEE12207.0-96], Thiết kế
phần mềm có hai nhiệm vụ chính:

•

•

Thiết kế kiến trúc phần mềm - Software architectural
design (Một số tài liệu phân tích thiết kế cịn gọi
nhiệm vụ này là Thiết kế phần mềm mức cao Toplevel design): Xác định mô hình mức cao của
phần mềm, xác định các thành phần của mơ hình.
Thiết kế chi tiết phần mềm - Software detailed design:
thiết kế chi tiết từng thành phần, xác định đầy đủ các
thông tin tương ứng cho từng thành phần để có thể
tiến hành xây dựng phần mềm.
5

2.1. Các khái niệm cơ bản trong thiết kế phần mềm
•

Quy trình: Thiết kế phần mềm được chia

làm hai tiến trình cơng việc:

•
•

Thiết kế kiến trúc phần mềm - Architectural
Design mục đích xác định mơ hình kiến trúc và
các thành phần trong kiến trúc IEEEP1471-00
Thiết kế chi tiết - Detailed Design mục đích xác
định các đặc tính kỹ thuật và đặc tả các thành
phần của kiến trúc phần mềm. IEEE1016-98

6


2.1. Các khái niệm cơ bản trong thiết kế phần mềm
•

Các kỹ thuật trong thiết kế phần mềm:

•
•
•

•
•
•

Abstraction
Coupling and cohesion
Decomposition and modularization
Encapsulation/information hiding
Separation of interface and implementation
Sufficiency, completeness and primitiveness

7


2.1. Các khái niệm cơ bản trong thiết kế phần mềm
•

Các kỹ thuật trong thiết kế phần mềm:

•

Abstraction: is “the process of forgetting
information so that things that are different can be
treated as if they were the same”. [Lis01] In the
context of software design, two key abstraction
mechanisms
are
parameterization
and
specification. Abstraction by specification leads to

three major kinds of abstraction: procedural
abstraction, data abstraction and control
(iteration) abstraction.

8


2.1. Các khái niệm cơ bản trong thiết kế phần mềm
•

Các kỹ thuật trong thiết kế phần mềm:

•
•

Coupling and cohesion: Coupling is defined as the
strength of the relationships between modules,
whereas cohesion is defined by how the elements
making up a module are related.
Decomposition and modularization: Decomposing and
modularizing large software into a number of smaller
independent ones, usually with the goal of placing
different functionalities or responsibilities in different
components.

9


2.1. Các khái niệm cơ bản trong thiết kế phần mềm
•

Các kỹ thuật trong thiết kế phần mềm:

•

•

Separation of interface and implementation:
Separating interface and implementation involves
defining a component by specifying a public interface,
known to the clients, separate from the details of how
the component is realized.
Sufficiency,
completeness
and
primitiveness:
Achieving
sufficiency,
completeness,
and
primitiveness means ensuring that a software
component captures all the important characteristics
of an abstraction, and nothing more.

10


Chương 2. Thiết kế phần mềm (Software Design)
1.
2.

3.
4.

5.
6.

Các khái niệm căn bản trong thiết kế phần mềm
Thiết kế kiến trúc phần mềm (Software Architectrure
Design)
Các chiến thuật và phương pháp thiết kế phần mềm
Xây dựng các đặc tả thiết kế phần mềm (Software
Design Specification)
Giới thiệu một số tài liệu liên quan đến nội dung chương
Câu hỏi và bài tập

11


2.2. Thiết kế kiến trúc phần mềm

•
•
•

•
•
•
•

Định nghĩa Kiến trúc phần mềm
Xác định các yêu cầu đối với kiến trúc phần mềm
Xây dựng kiến trúc phần mềm
• Phần cứng
• Phần mềm
• Các phần mềm tiện ích trợ giúp
Một số kỹ thuật tiêu biểu thiết kế kiến trúc phần mềm
Đánh giá và kiểm thử kiến trúc phần mềm
Các phương pháp kiểm thử kiến trúc phần mềm
Các tiêu chí đánh giá chất lượng kiến trúc phần mềm

12


2.2. Thiết kế kiến trúc phần mềm

•
•
•
•
•

Định nghĩa Kiến trúc phần mềm
Một số kỹ thuật tiêu biểu thiết kế kiến trúc
phần mềm
Đánh giá và kiểm thử kiến trúc phần mềm
Các phương pháp kiểm thử kiến trúc phần
mềm
Các tiêu chí đánh giá chất lượng kiến trúc
phần mềm

13


2.2. Thiết kế kiến trúc phần mềm

•

Định nghĩa Kiến trúc phần mềm: Kiến trúc phần
mềm bao gồm hệ thống các thành phần
(components) và các mối quan hệ (relations). Thuật
ngữ thành phần có thể là hệ thống con (subsystems),
các quy trình (processes), các mô đun phần mềm
(software modules), các thành phần phần cứng
(hardware components)… Các mối quan hệ gồm
luồng dữ liệu (data flows), luồng điều khiển (control
flows), các mối quan hệ triệu gọi (call-relation)…

14


2.2. Thiết kế kiến trúc phần mềm
•

Định nghĩa kiến trúc phần mềm:

•
•
•

"The logical and physical structure of a system, forged
by all the strategic and tactical design decisions
applied during development" [Booch 91]
The
structure
of
the
components
of
a
program/system,
their
interrelationships,
and
principles and guidelines governing their design and
evolution over time. [Garlan 95]
"The software architecture of a program or computing
system is the structure or structures of the system,
which comprise software components, the externally
visible properties of those components, and the
relationships among them." [Bass 98]
15


2.2. Thiết kế kiến trúc phần mềm
Planning and
Architecture Phase

Prospectus

Requirements

Discovery
Review

Architecture
High-Level
Design

Source:
Joe Maranzano
ATT Bell Labs

Architecture
Review

Low-Level
Design
16


2.2. Thiết kế kiến trúc phần mềm
Một số kỹ thuật tiêu biểu thiết kế kiến trúc phần mềm (Meta-Model
for Architecture Design Approaches):
Artifact-driven Architecture Design
Use-Case driven Architecture Design
Domain-driven Architecture Design
Pattern-driven Architecture Design

17

Meta-Model for Architecture Design Approaches(1/3)

18


Meta-Model for Architecture Design Approaches(2/3)
Client: những người được quan tâm trong phát triển của một
thiết kế kiến trúc phần mềm gồm: khách hàng (customer),
người sử dụng cuối (end-user), người phát triển hệ thống
(system developer), người bảo trì hệ thống (system maintainer),
người quản lý việc bán (sales manager) …
Domain Knowledge: vùng kiến thức để giải quyết một vấn đề
nào đó.
Requirement Specification: xác định việc mô tả các yêu cầu
cho kiến trúc được phát triển.
Artifact: mô tả cho một phương thức nào đó (Class, Operation,
Attribute )
…

19


Meta-Model for Architecture Design Approaches(3/3) Domain
Knowledge

20

Artifact-driven Architecture Design (1/2) Mơ hình mức
khái niệm

21


Artifact-driven Architecture Design (2/2)
Problems
“Textual requirements are imprecise, ambiguous or incomplete
and are less useful as a source for deriving architectural
abstractions”(các yêu cầu mơ hồ, nhập nhằng, hoặc khơng đầy
đủ và ít khi hữu ích)
Subsystems have poor semantics to serve as architectural
components (các hệ thống con nghèo nàn ngữ nghĩa để phục vụ
như là các thành phần kiến trúc )
Composition of subsystems is not well-supported (kết cấu của hệ
thống con không được hỗ trợ tốt)

22


Use-Case driven Architecture Design (1/2)
Mơ hình mức khái niệm

23


Use-Case driven Architecture Design (2/2)
Problems

Leveraging detail of domain model and business model is
difficult
Selecting architecturally relevant use-cases is not
systematically supported
Use-cases do not provide a solid basis for architectural
abstractions
Package construct has poor semantics to serve as an
architectural component

24


Domain-driven Architecture Design (1/3)
Mơ hình mức khái niệm

25