ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Trần Lệ Huyền TÌM HIỂU VỀ TIẾP CẬN THEME
VÀ ỨNG DỤNG CỦA CÁCH TIẾP CẬN VÀO XÂY
DỰNG HỆ THỐNG ĐIỆN THOẠI
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công Nghệ Thông Tin HÀ NỘI - 2010
2
3Lời cảm ơn
Lời đầu tiên, em xin được bày tỏ lòng biết ơn sâu sắc tới thầy Đặng Văn Hưng-
Người đã trực tiếp hướng dẫn, tận tình giúp đỡ em trong thời gian thực hiện khóa luận.
Em xin được bày tỏ lòng biết ơn tới các thầy, cô trong khoa Công Nghệ Thông
Tin, trường Đại Học Công Nghệ, ĐHQGHN. Các thầy cô đã nhiệt tình dạy bảo và tạo
mọi điều kiện học tập tốt nhất cho chúng em trong những năm học tập tại ĐHCN
Tôi xin cảm ơn các bạn sinh viên lớp K51CC và K51CNPM Trường Đại học
Công nghệ, những người bạn đã cùng tôi học tập và rèn luyện trong suốt những năm
học đại học.
Hà Nội, ngày 19 tháng 5 năm 2010
Trần Lệ Huyền 4Tóm tắt
Lập trình hướng khía cạnh (Aspect Oriented Programming - AOP) là một kiểu
lập trình mới nhanh chóng thu hút được các nhà phát triển trong giới công nghệ thông
tin. AOP là một mô hình lập trình tách biệt các chức năng phụ với logic nghiệp vụ của
chương trình chính. Các chức năng phụ rải rác nằm xuyên suốt trong hệ thống được
tách thành các đơn vị duy nhất, gọi là aspect( khía cạnh). Một aspect là một đơn vị mô-
đun cho sự thi hành cắt ngang chương trình. Nó đóng gói các hành vi mà ảnh hưởng
đến nhiều lớp vào các mô-đun có khả năng sử dụng lại. Đây là một phương pháp lập
trình phát triển dựa trên lập trình hướng đối tượng.
1.3.2 Mối quan hệ giữa các theme : 8
1.3.3 Áp dụng cách tiếp cận theme: 9
Chương 2 Phân tích 11
2.1 Các khung nhìn Theme/Doc 11
2.1.1 Khung nhìn relationship của theme 11
2.1.2 Khung nhìn crosscutting của Theme 12
2.1.3 Khung nhìn individual 14
2.2 Quá trình xử lý Theme/Doc 14
2.3 Quyết định trên theme 16
2.3.1 Chọn các theme ban đầu 16
2.3.2 Các hoạt động trên theme 19
2.3.3 Hoạt động trên Requirements 21
2.4 Quyết định Theme trách nhiệm 22
2.4.1 Xác định Theme aspect 23
2.4.2 Trì hoãn một số quyết định 25
2.5 Kế hoạch cho thiết kế 25
2.5.1 Xác định các đối tượng 25
2.5.2 Khung nhìn theme base 26
2.5.3 Khung nhìn theme aspect 26
Chương 3 Thiết kế theme 28
3.1 Thiết kế theme base 28
3.2 Thiết kế Theme crosscutting 29
3.2.1 Tổng quan về thiết kế Theme crosscutting 29
3.2.2 Thay đổi với UML 32
Chương 4 Tổng hợp theme 36
4.1 Pick Theme 36
4.2 Xác định các phần tử thiết kế so khớp 37 71
Mở đầu
Lập trình hướng đối tượng (Object Oriented Programming - OOP) là mô hình
phát triển được lựa chọn cho hầu hết các dự án phần mềm. OOP rất hữu hiệu trong
việc lập mô hình hành vi chung của các đối tượng, tuy nhiên nó không giải quyết thỏa
đáng những hành vi liên quan đến nhiều đối tượng. AOP giải quyết được vấn đề này,
và rất có thể sẽ là bước phát triển lớn kế tiếp trong phương pháp lập trình.
Vấn đề cốt lõi của AOP là cho phép chúng ta thực hiện các vấn đề riêng biệt một
cách linh hoạt và kết hợp chúng lại để tạo nên hệ thống sau cùng. AOP bổ sung cho kỹ
thuật lập trình hướng đối tượng bằng việc hỗ trợ một dạng mô-đun khác, cho phép kéo
thể hiện chung của vấn đề đan nhau vào một khối. Khối này được gọi là ‘aspect’ (khía
cạnh), từ chữ ‘aspect’ này chúng ta có tên của phương pháp phát triển phần mềm mới:
aspect-oriented programming. Nhờ mã được tách riêng, vấn đề đan nhau trở nên dễ
kiểm soát hơn. Các aspect của hệ thống có thể thay đổi, thêm hoặc xóa lúc biên dịch
và có thể tái sử dụng.
Aspect-orientation là một hướng tiếp cận mạnh mẽ cho lập trình hệ thống phức
tạp. Áp dụng phương pháp aspect vào mô hình và thiết kế hệ thống có nhiều ưu điểm
so với OOP. Cách tiếp cận Theme (chủ đề) là một ưu điểm quan trọng trong AOP,
cung cấp phương tiện để ứng dụng aspect-orientation.
Bài luận của em tìm hiểu về AOP dựa trên tài liệu “Aspect-Oriented Analysis
and Design: The Theme Approach “ của tác giả Siobhán Clarke và Elisa Baniassad.
Bài luận trình bày về phân tích xây dựng một hệ thống bằng phương pháp AOP.
Bài luận gồm năm chương:
Chương 1: Giới thiệu và trình bày các đặc điểm về AOP.
Chương 2: Phân tích yêu cầu hệ thống để tìm ra tập theme .
Khi độ phức tạp của các bài toán tăng lên, chúng ta cần có những kỹ thuật tốt
hơn là lập trình hướng thủ tục.
Lập trình hướng đối tượng OOP đã trở thành sự lựa chọn chính khi phát triển và
xây dựng hệ thống phần mềm trong nhiều năm qua, mà thay thế hoàn toàn cho cách
tiếp cận hướng thủ tục. Một trong những ưu điểm lớn nhất của hướng đối tượng là hệ
thống phần mềm có thể được xem như là việc xây dựng một tuyển tập các lớp riêng
biệt. Mỗi một class (lớp) trong tuyển tập các lớp đó chịu trách nhiệm cho một tác vụ
nào đó trong hệ thống. Trong ứng dụng hướng đối tượng, các lớp này sẽ hợp tác lại với
nhau để hoàn thành mục tiêu chung của ứng dụng.
Kỹ thuật OOP thực hiện tốt việc đóng gói các hành vi và chủ thể , miễn là chúng
hoàn toàn riêng biệt. Tuy nhiên, các bài toán thực tế thường có những hành vi đan
nhau liên quan đến nhiều lớp, không thể được xem như là trách nhiệm riêng của một
lớp. Ví dụ như là việc tiến hành locking (khóa) trong các ứng dụng phân tán, xử lí
ngoại lệ, hoặc việc ghi log…Tất nhiên code để mà xử lý các phần này có thể được
thêm vào mỗi lớp một cách riêng biệt, nhưng điều này sẽ dẫn tới sự vi phạm trách
nhiệm chính của mỗi lớp mà ta đã định nghĩa. Theo truyền thống, hầu hết ngôn ngữ 3
lập trình hướng đối tượng như C++ và Java đều không hỗ trợ đóng gói những hành vi
đan nhau, dẫn đến mã chương trình có thể nằm lẫn lộn, rải rác và khó quản lý.
AOP là kỹ thuật lập trình mới cho phép đóng gói những hành vi có liên quan đến
nhiều lớp. Nó tập trung vào các khái niệm cắt ngang hoặc các khía cạnh - phần mã sử
dụng chung cho các đối tượng khác nhau. Nhờ mã được tách riêng, vấn đề đan nhau
trở nên dễ kiểm soát hơn. AOP tách riêng các đặc điểm mà rải rác, đan xen trong hệ
thống thành một mô-đun riêng để xử lý, nhưng nó không phải là sự kết hợp của lập
trình hướng thủ tục và lập trình hướng đối tượng. AOP có thể xem là một sự bổ sung
cho OOP, OOP là cách thức mô-đun hoá các mối quan tâm nói chung và AOP là cách
mô-đun hoá các mối quan tâm đặc biệt chạy xuyên suốt và cắt ngang các đơn vị
Aspect-Oriented Programming còn được gọi là Aspect-Oriented Software
Development (AOSD, phát triển phần mềm hướng khía cạnh) là một nguyên tắc thiết
kế giúp tách rời các yêu cầu hay các vấn đề được quan tâm (gọi là separation of
concerns) trong chương trình thành các thành phần độc lập và từ đó tăng tính uyển
chuyển cho chương trình. “Separation of concerns” là một trong những kĩ thuật được
quan tâm nhất trong ngành kỹ nghệ phần mềm. Người ta cho rằng những vấn đề tương
tự nhau nên được giải quyết trong một “đơn vị code”. Khi lập trình thủ tục, một “unit
of code” là một function, một method. Còn trong lập trình hướng đối tượng thì “unit
of code” là một class.
1.2.3 Những lợi ích “separate of concerns”
Trong AOP, “aspect” chính là vấn đề người lập trình quan tâm và nó xuất hiện
trong rất nhiều class cũng như nhiều method khác nhau. Kĩ thuật AOP thường được sử
dụng để giải quyết các vấn đề như bộ nhớ đệm, lưu vết, và bảo mật. Vì thế, nhiều tài
liệu nói rằng AOP giúp mô-đun hóa ứng dụng, biến chương trình thành các mô-đun
hoạt động độc lập, mỗi mô-đun làm một chức năng riêng, từ đó dễ bảo trì và nâng cấp.
AOP xác định các vấn đề một cách tách biệt, nó hạn chế tối thiểu việc nhập nhằng mã,
cho phép mô-đun hoá các vấn đề liên quan đến nhiều lớp đối tượng.
Ở vai trò của người thiết kế phần mềm, chúng ta nên đưa ra các cách làm đơn
giản nhất. Để thỏa mãn yêu cầu của chương trình, người ta sẽ tạo ra thành phần chính
của chương trình (gồm các class/component/method); các chức năng bổ sung như ghi
(log), tính toán hiệu năng chương trình cũng sẽ được xem xét để tạo ra. Vì do các chức
năng bổ sung này không phải là yêu cầu chính của hệ thống nên người ta sẽ có yêu cầu
bật tắt chúng theo ý muốn. Vậy làm thế nào để có thể tạo ra chương trình có thể linh
hoạt được như thế? Câu trả lời là “Separate of concerns”.
Ở vai trò của người lập trình, chúng ta có hai vấn đề cần quan tâm là xử lý logic
chính của chương trình và các xử lý logic cho những thành phần phụ. Do đó tất nhiên
sẽ phải tạo ra các class/method cho các yêu cầu thực sự, và tạo ra những class/method
khác độc lập để thực hiện các yêu cầu phụ. Tất cả các class/method này có thể được
kết hợp lúc runtime theo ý muốn. Chẳng hạn như trong môi trường test, người ta có
thể bật chức năng log, đo đạc hiệu năng làm việc của chương trình để theo dõi. Nhưng
Chức năng chính sẽ chứa đựng cấu trúc và hành vi phù hợp tới các chức năng
miền của hệ thống. Việc phân tách các aspect khỏi chức năng chính của hệ thống
giống như là việc phân phối các đối tượng trong hệ thống, sự sắp xếp hệ thống đồng
bộ hóa được giao kết với các method thuộc các đối tượng đó, và bao bọc tập hợp các
thao tác vào trong một giao dịch đơn. Tất cả những việc này sẽ được mô tả trong một
mô-đun chuyên biệt (mỗi mô-đun sẽ là một aspect), và được gọi tại một điểm cụ thể
trong khi thực thi các phần chính của một chương trình. 6
Trong mức độ khái niệm, các aspect sẽ có hai thuộc tính quan trọng trong sự phối
hợp này. Đầu tiên, các aspect sẽ chỉ được kích hoạt bởi các điểm thực thi trong các
chức năng chính. Thứ hai, các aspect sẽ bị kích hoạt trong rất nhiều phần của hệ
thống, nhìn chung thì việc phân tách design/code trong một aspect sẽ không hữu dụng
nếu aspect này chỉ được thực thi tại một nơi trong hệ thống.
Bảng 1-1. Định nghĩa về các thuật ngữ trong mẫu phân tách theo hướng asymmetric
Thuật ngữ Mô tả
Crosscutting
Các concern mà hành vi của nó bị kích hoạt trong nhiều tình huống khác
nhau.
Advice Là các hành vi bị kích hoạt
Aspect Sự bao bọc advice và đặc tả cái nơi mà advide bị kích hoạt
Core
Là các phần của hệ thống hướng đối tượng truyền thống nơi mà các aspect
sẽ được ứng dụng vào
Jointpoint Điểm thực thi mà kích hoạt advide
Pointcut Là việc bạn chọn những jointpoint nào để thực thi
Weaving
Các thuật ngữ khi sử dụng với phương pháp này sẽ khác với cách dùng của
phương pháp bất đồng bộ:
-Concern: Vài loại chức năng trong hệ thống. Nó có thể là một đặc điểm (hàm)
hoặc một loại tiến trình xử lí.
-Crosscutting: là một concern bị kích hoạt trong nhiều tình huống hoặc những
cấu trúc và hành vi của concern nào bị giải rác xuyên suốt cac code base và bị rối với
mối liên quan code tới các concern khác.
-Composition: Tổng hợp cài đặt riêng biệt của các concern để hình thành nên một
chức năng của hệ thống.
1.3 Giới thiệu sơ qua về Theme
Approach Theme (tiếp cận chủ đề) là cách để bạn sử dụng AOP trong quá trình
phân tích và thiết kế một dự án phần mềm.
Chúng ta dùng theme chủ yếu là để xác định các aspect trong hệ thống, sử dụng
các mẫu phân tách Asymmetric hoặc Symmetric.
1.3.1 Định nghĩa về Theme
“Theme” sẽ không được coi như là tương đồng với từ aspect. Theme được định
nghĩa tổng quan hơn các aspect và có sự chặt chẽ hơn khi bao bọc các concern như đã
được mô tả cho cách tiếp cận symmetric. Hãy xem với mỗi một chức năng hay một
concern hay một aspect lập trình viên phải coi như là một theme riêng biệt để phục vụ
cho hệ thống . Theo như các thuật ngữ trong cách tiếp cận symmetric thì concern được
định nghĩa là : “vài loại chức năng của hệ thống , các chức năng này có thể là một đặc
điểm hay một kiểu xử lý”. Như vậy theme sẽ được mô tả như “là một sự bao bọc các
concern”. 8
Trong mức độ requirement, một theme là một tập các trách nhiệm được mô tả
trong một tập các requirement. Trong mức độ thiết kế, các theme bao gồm cấu trúc và
hành vi cần phải thực hiện các trách nhiệm trong mức độ các requirement.
1.3.3 Áp dụng cách tiếp cận theme:
Có hai quá trình khi bạn áp dụng phương pháp theme: sử dụng Theme/Doc, giúp
phân tích tài liệu yêu cầu về phần mềm, và sử dụng Theme/UML giúp thiết kế các
theme. Hình 1-2 sẽ mô tả các hoạt động ở mức tổng quan khi bạn ứng dụng cách tiếp
cận theme.
Hình 1-2. Các hoạt động tiếp cận Theme.
1.3.3.1 Phân tích yêu cầu với Theme/Doc
Dùng Theme/Doc để xác định các theme trong tài liệu yêu cầu (requirement
document). Nó cung cấp phương pháp phân tích bằng kinh nghiệm để xác định những
theme nào là theme aspect hay crosscutting.
Quá trình phân tích bằng Theme/Doc có hai hoạt động chính:
+ Xác định các theme chính trong hệ thống 10
+ Xác định trách nhiệm của mỗi theme mà từ đó xác định ra được theme aspect.
Trong quá trình tiến hóa của hệ thống, kiểm định thực tế qua sử dụng, chúng ta
có thể dùng hai hoạt động chính ở trên để lên kế hoạch thiết kế các thay đổi của hệ
thống.
1.3.3.2 Thiết kế các theme với Theme/UML
Theme/UML cho phép thiết kế riêng các mô-đun cho mỗi theme xác định trong
requirement. Nó là một trong những cơ sở quan trọng của AOSD để: mô-đun hóa
theme, chỉ ra mối quan hệ giữa các theme liên quan, và tổng hợp các theme thành một
hệ thống mạch lạc.
Các theme được xác định với theme/doc có thể được thiết kế riêng biệt dù có sự
cắt ngang giữa các theme hay không, hoặc có sự trùng lặp giữa các theme hay không.
Chúng ta sẽ gần như hoàn toàn sử dụng chuẩn UML để thiết kế cho mỗi theme, sẽ có
một vài mở rộng của chuẩn UML để thiết kế cho theme aspect. Tất cả các class,
không nên lạp chồng trong các nhóm yêu cầu của chúng, ta có thể viết lại các
requirement chia sẻ để tránh lạp chồng các hành vi trong theme , hoặc xử lý sự lạp
chồng đó trong thiết kế .
2.1 Các khung nhìn Theme/Doc
Sử dụng Theme/Doc giúp chúng ta thấy các mối quan hệ giữa các chức năng bị
làm rối lẫn một cách trực quan hơn và đưa ra quyết định cách đóng gói trong hệ thống.
Có ba loại khung nhìn Theme/Doc: khung nhìn relationship (khung nhìn quan hệ),
khung nhìn crosscutting (khung nhìn cắt ngang), và khung nhìn individual (khung nhìn
cá nhân).
2.1.1 Khung nhìn relationship của theme
Khung nhìn relationship của theme (có thể gọi ngắn gọn là khung nhìn
relationship) chỉ ra các relationships giữa các theme.
Hình 2-1 ví dụ trừu tượng của một khung nhìn relationship.
Hình 2-1 miêu tả một ví dụ trừu tượng cho khung nhìn relationship. Các theme
được chỉ ra trong các nút hình thoi, nhãn của nút là tên theme. Các requirements được 12
hiển thị trong khung nhìn với các hình chữ nhật bo góc. Các requirements có thể được
đánh nhãn với phần toàn bộ nội dung text của nó hay đơn giản là đánh số requirement,
như là R1, R2…
Khung nhìn relationship không chỉ ra “trực tiếp” mối quan hệ của các theme, nó
sẽ chỉ ra cách các theme liên quan tới các requirement. Nếu đoạn text của requirement
chứa một tham chiếu tới tên một theme, một liên kết được vẽ mô tả kết nối
requirement đó tới theme đó. Nếu một requirement đề cập nhiều hơn một theme, giống
như requirement 1 trong hình 2-1, thì nó sẽ được liên kết tới nhiều hơn một nút
theme. Các requirement mà tham chiếu tới nhiều hơn một theme được gọi là
requirement chia sẻ. Nếu hai theme mà cùng liên kết tới cùng một requirement, chúng
base (requirement chia sẻ chung bây giờ không giao kết với các theme base nữa).
Nếu một requirement được giao kết với một theme aspect thì nó chỉ được liên kết với
theme đó. Các theme khác được tham chiếu trong requirement được liên kết với theme
aspect với mũi tên xám đậm chỉ ra rằng chúng bị cắt ngang bởi theme aspect. Như vậy
trong khung nhìn crosscutting mỗi requirement chỉ giao kết với một theme. Trong
hình 2-2, miêu tả mối quan hệ crosscutting từ First Theme (được xác định là theme
aspect) tới Second Theme (theme base được requirement chia sẻ tham chiếu),
requirement chia sẻ bây giờ chỉ giao kết với duy nhất First theme.
b) Lựa chọn thứ hai là postpone (trì hoãn) quyết định về những theme
chia sẻ chung requirement sẽ được giao kết như thế nào, ta chưa quyết định theme nào
sẽ chịu trách nhiệm cho requirement chia sẻ. Việc postpone được mô tả trong khung
nhìn crosscutting với đường nét đứt, được gán nhãn bằng nhãn (hoặc text) requirement
của giao kết bị trì hoãn. Trong ví dụ hình 2-2, requirement 3 được chia sẻ bởi First
theme và Third Theme, ta chưa xác định được theme nào chịu trách nhiệm cho hành vi
của requirement 3 nên trì hoãn việc giao kết theme của nó lại, và nó được liên kết với
First Theme, Third Theme bằng đường nét đứt, và gán nhãn là text của requirement 3.
Hai khung nhìn relationship và crosscutting thực sự là hai cực của một thể liên
tục. Khung nhìn relationship bao hàm tất cả các mối quan hệ giữa các theme và các
requirements, nhưng nó không bao hàm mối quan hệ relationship crosscutting.
Khung nhìn crosscutting bao gồm các mối quan hệ giao kết giữa các theme và các
requirement, và mô tả các quan hệ giao kết giữa các theme – quan hệ cắt ngang.
Khung nhìn crosscutting sẽ không chứa requirement chia sẻ, các requirement chia sẻ
lúc này đã được giao kết gắn với duy nhất một theme aspect chịu trách nhiệm cho 14
hành vi của nó. Nhưng trong thực tế hai loại khung nhìns này cùng được tích hợp, nên
có thể bạn sẽ thấy một khung nhìn relationship mà có một số crosscutting
relationships, và cũng có một số requirement chia sẻ. Có thể coi rằng khung nhìn
để tìm ra các theme.
Phía dưới bên phải của hình là : Determing Theme Responsible. Hoạt động này
có thể nói là : “Xác định đâu là theme aspect, và đâu là theme base”. Nếu theme
Theme1 có khả năng chịu trách nhiệm cho hành vi mà được kích hoạt trong theme
Theme2 thì Theme1 là một aspect của Theme2. Hoạt động này dựa vào khung nhìn
crosscutting, để xác định trách nhiệm của theme.
Cuối cùng là hoạt động Plan for Design: sẽ xem xét cấu trúc và hành vi của
theme mà sẽ được mô-đun hóa sử dụng Theme/UML. Khung nhìn individual được sử
dụng để đưa ra các kế hoạch cho thiết kế.
Khi bắt đầu chúng ta sẽ áp dụng các hoạt động theo như các bước sắp xếp trong
hình vẽ. Trong những lần xử lý Theme/Doc về sau, để làm mịn các thiết kế theme thì
ta không nhất thiết phải theo thứ tự các bước nữa, có thể lựa chọn pha trộn giữa các
hoạt động. 16Hình 2-5. Các hoạt động trọng tâm khi chọn lựa các theme và quyết định
trách nhiệm của chúng.
Các công việc cụ thể hơn cần làm trong quá trình xử lý Theme/Doc được chỉ ra
trong hình 2-5. Khung nhìn relationship được sử dụng trong cả hai hoạt động : quyết
định theme, và xác định theme trách nhiệm. Khung nhìn individual liên quan nhiều
đến quyết định trên theme. Khung nhìn crosscutting liên quan đến giao kết
requirements (và trì hoãn giao kết), nó sử dụng trong hoạt động xác định theme base
và theme aspect. Tất cả ba khung nhìn đều được sử dụng khi lên kế hoạch thiết kế. Các
hoạt động khi quyết định trên theme: Add - thêm theme, Delete - xóa theme, Split -
phân tách các theme, Group - nhóm các theme, Add requirement mới, Attach - giao
kết requirement với một theme cụ thể, Postpone - trì hoãn giao kết đến khi có thêm
thông tin để quyết định với requirements. Hoạt động xác định theme trách nhiệm là
quan nhau, không có sự xảy ra đi liền với nhau).
2.3.1.2 Bắt đầu với tất cả
Cách này sẽ chọn tất cả các động từ, hoặc các từ chỉ hành động được viết trong
requirement để tìm tập theme ban đầu.
Cách tiếp cận này tiếp kiệm thời gian trong bước đầu đọc qua các requirement và
lựa chọn theme. Tuy nhiên , với cách tiếp cận này sẽ có rất nhiều theme tiềm năng vì
thế mà quá trình làm mịn theme sẽ xem những theme nào thực sự sẽ tồn tại và phù hợp
trong ứng dụng của mình để loại bỏ đi những theme không mong muốn, và nhóm các
động từ để hình thành những theme thực tế lớn hơn.
2.3.1.3 Kết hợp cả hai hướng tiếp cận
Bình thường, bạn sẽ kết hợp cả hai cách trên để quá trình tìm theme được hiệu
quả. Khi đọc qua tài liệu về requirement, bạn nhặt ra tất cả những gì giống như một
hành vi, concern, hay đặc điểm. Sự kết hợp này sẽ thu hẹp danh sách theme hơn so với
cách lựa chọn bất kì động từ nào có trong tập requiremnent, và nó cũng lựa chọn thoải
mái hơn so với cách chỉ chọn ra các khái niệm mà có triển vọng cao sẽ trở thành
theme. Với cách đầu tiên, sẽ có những theme chắc chắn sẽ được cài đặt trong hệ thống
nhưng sẽ có rất nhiều requirement là “mồ côi”, còn với cách thứ hai thì sẽ có quá 18
nhiều theme riêng lẻ, làm cho khung nhìn mối quan hệ sẽ vô cùng lớn, có thể trong số
những theme đó có theme sẽ chẳng chịu trách nhiệm gì trong hệ thống của bạn. Vì thế
kết hợp cả hai cách để giảm thiểu số lượng các requirement là “mồ côi” và giảm thiểu
những theme không cần thiết.
Xét một hệ thống đánh giá biểu thức đơn giản- expression evaluation system
(EES), tập requirements của nó gồm:
1- An evaluation capability, which determines the result of evaluating an
expression (khả năng đánh giá xác định kết quả đánh giá một biểu thức ).
2- A display capability, which depicts expressions textually ( khả năng hiển thị mô
Copyright: Tài liệu đại học ©