1
THI
THI
Ế
Ế
T K
T K
Ế
Ế
V
V
À
À
XÂY D
XÂY D
Ự
Ự
NG PH
NG PH
Ầ
Ầ
N M
N M
Ề
Ề
M
M
(SOFTWARE DESIGN AND CONSTRUCTION)
(SOFTWARE DESIGN AND CONSTRUCTION)
Năm
Năm

• Các kỹ thuậttrongthiếtkế phầnmềm
44
2.1. Các khái niệmcơ bảntrongthiếtkế phầnmềm
• Khái niệm: Thiếtkế phầnmề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ệnvàcácđặc tính kỹ thuậtcủa
hệ thống hoặc thành phần .
• Thiếtkế phầnmềmsẽ là cơ sỏ cho giai đoạntiếptheo
là xây dựng phầnmềm.
• Thiếtkế phầnmềm đóng vai trò quan trọng trong phát
triểnphầ
nmềm:
• Cho phép xem xét, so sánh các phương án kỹ thuật
khác nhau trong thiếtkế phầnmềm
• Cho phép xác định phương án phù hợpnhấtvớicác
yêu cầuphầnmềm
• Cho phép lậpcáckế hoạch chi tiết cho giai đoạnxây
dựng phầnmềm
55
2.1. Các khái niệmcơ bảntrongthiếtkế phầnmềm
• Nhiệmvụ: Theo IEEE/EIA 12207 Software Life
Cycle Processes và [IEEE12207.0-96], Thiếtkế
phầnmềm có hai nhiệmvụ chính:
• Thiếtkế kiếntrúcphầnmềm - Software architectural
design (Mộtsố tài liệu phân tích thiếtkế còn gọi
nhiệmvụ này là Thiếtkế phầnmềmmứccao-
Toplevel design): Xác định mô hình mứccaocủa
phầnmềm, xác định các thành phầncủamôhình.
• Thiếtkế chi tiếtphầnmềm-Software detailed design:

specification. Abstraction by specification leads to
three major kinds of abstraction: procedural
abstraction, data abstraction and control
(iteration) abstraction.
99
2.1. Các khái niệmcơ bảntrongthiếtkế phầnmềm
• Các kỹ thuật trong thiếtkế phầnmề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.
1010
2.1. Các khái niệmcơ bảntrongthiếtkế phầnmềm
• Các kỹ thuật trong thiếtkế phầnmề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.
1111

phầnmềm
1414
2.2. Thiếtkế kiếntrúcphầnmềm
• Định nghĩaKiếntrúcphầnmềm: Kiếntrúcphần
mềmbaogồmhệ thống các thành phần
(components) và các mối quan hệ (relations). Thuật
ngữ thành phầncóthể là hệ thống con (subsystems),
các quy trình (processes), các mô đun phầnmềm
(software modules), các thành phầnphầncứng
(hardware components)… Các mối quan hệ gồm
luồng dữ liệu (data flows), luồng điềukhiển(control
flows), các mối quan hệ triệugọi (call-relation)…
1515
2.2. Thiếtkế kiếntrúcphầnmềm
• Định nghĩakiếntrúcphầnmề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]
1616
2.2. Thiếtkế kiếntrúcphầnmềm
Prospectus

(system developer), ngườibảotrìhệ thống (system maintainer),
ngườiquảnlýviệc bán (sales manager) …
z Domain Knowledge: vùng kiếnthức để giải quyếtmộtvấn đề
nào đó.
z Requirement Specification: xác định việcmôtả các yêu cầu
cho kiếntrúcđượcpháttriển.
z Artifact: mô tả cho mộtphương thứcnàođó (Class, Operation,
Attribute )
z …
20
Meta-Model for Architecture Design Approaches(3/3) Domain
Knowledge
21
Artifact-driven Architecture Design (1/2) Mô hình mức
khái niệm
22
Artifact-driven Architecture Design (2/2)
Problems
z “Textual requirements are imprecise, ambiguous or incomplete
and are less useful as a source for deriving architectural
abstractions”(các yêu cầumơ hồ, nhậpnhằng, hoặc không đầy
đủ và ít khi hữuích)
z Subsystems have poor semantics to serve as architectural
components (các hệ thống con nghèo nàn ngữ nghĩa để phụcvụ
như là các thành phầnkiếntrúc)
z Composition of subsystems is not well-supported (kếtcấucủahệ
thống con không đượchỗ trợ tốt)
23
Use-Case driven Architecture Design (1/2)
Mô hình mứckháiniệm