Phân tích các tiêu chí và quy trình kiến trúc phần mềm

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƢỜNG ĐẠI HỌC SƢ PHẠM HÀ NỘI 2

LƢU THÀNH SƠN

PHÂN TÍCH CÁC TIÊU CHÍ VÀ QUY
TRÌNH KIẾN TRÚC PHẦN MỀM

LUẬN VĂN THẠC SĨ MÁY TÍNH

.................................................................................................................

1
HÀ NỘI, 2014


BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƢỜNG ĐẠI HỌC SƢ PHẠM HÀ NỘI 2

LƢU THÀNH SƠN

PHÂN TÍCH CÁC TIÊU CHÍ VÀ QUY
TRÌNH KIẾN TRÚC PHẦN MỀM
Chuyên ngành: KHOA HỌC MÁY TÍNH
Mã số: 60 48 01 01
LUẬN VĂN THẠC SĨ MÁY TÍNH

............... Người hướng dẫn khoa học: PGS,TSKH: Nguyễn Xuân Huy

2
HÀ NỘI, 2014

LỜI CẢM ƠN
Xin chân thành cảm ơn Thầy giáo, GS.TSKH. Nguyễn Xuân Huy đã tận
tình chỉ dạy, hướng dẫn tôi trong suốt thời gian nghiên cứu và thực hiện luận
văn. Tôi cũng xin chân thành cảm ơn các Thầy giáo Viện Công nghệ Thông
tin và các Thầy giáo Trường Đại học sư phạm Hà Nội 2 đã giảng dạy, giúp đỡ
trong suốt thời gian học tập.
Xin cảm ơn tất cả các anh chị em học viên Cao học khóa 16 – Khoa học máy
tình, cảm ơn các cán bộ công chức, giảng viên Trường Đại học sư phạm Hà
Nội 2 đã tạo điều kiện tốt cho tôi trong suốt hai năm học qua.
Xin cảm ơn các bạn bè, đồng nghiệp, gia đính đã tạo mọi điều kiện thuận lợi
cũng như đã chỉ bảo tôi rất nhiều trong thời gian thực hiện luận văn này để tôi
có được kết quả như ngày hôm nay.
Hà Nội, tháng

/2014

Người viết luận văn

Lƣu Thành Sơn

3


LỜI CAM ĐOAN
Tôi xin cam đoan rằng số liệu và kết quả nghiên cứu trong luận văn này
là hoàn toàn trung thực và không trùng lặp với các đề tài khác. Tôi cũng xin
cam đoan rằng mọi sự giúp đỡ cho việc thực hiện luận văn này đã được cảm
ơn và các thông tin trìch dẫn trong luận văn đã được chỉ rõ nguồn gốc.

Vĩnh Phúc, ngày

tháng

Tác giả

Lƣu Thành Sơn

4

năm 2014


MỤC LỤC
LỜI CẢM ƠN
LỜI CAM ĐOAN
MỞ ĐẦU ......................................................................................................... 1
1. Lý do chọn đề tài ............................................................................... 1
2. Mục đìch nghiên cứu ........................................................................ 2
3. Nhiệm vụ nghiên cứu ........................................................................ 2
4. Đối tượng và phạm vi nghiên cứu ................................................... 2
5. Phương pháp nghiên cứu .................................................................. 2
6. Những đóng góp mới của đề tài ........................................................ 3
7. Cấu trúc luận văn .............................................................................. 3

Chƣơng 1: Tổng quan về kiến trúc phần mềm ........................... 4
1.1 Khái niệm kiến trúc phần mềm ....................................................... 4
1.2 Các quyết định trong thiết kế kiến trúc ........................................... 7
1.3 Các quan điểm trong kiến trúc phần mềm .............................. …..14
1.4 Kết luận chương 1 ................................................................... …..16

Chƣơng 2: Quy trình phát triển phần mềm và các tiêu chí chất
lƣợng của sản phẩm phần mềm ............................................. ….17
2.1 Mô hính phát triển phần mềm ................................................. ….17
2.1.1 Xác định từ một mô hính mẫu có sẵn ........................ ….17
2.1.2 Xác định từ mô hính phát triển phần mềm ................ ….20
2.1.3 Phương pháp phát triển phần mềm Agile .................. ….22
2.2 Hoạt động trong các quá trính ................................................ ….24
2.2.1 Đặc tả phần mềm ....................................................... ….25
2.2.2 Thiết kế và triển khai phần mềm ............................... ….27
5


2.2.3 Xác nhận phần mềm .................................................. ….33
2.2.4 Nâng cấp phần mềm .................................................. ….37
2.3 Các tiêu chì chất lượng của sản phẩm phần mềm .................. ….38
2.4 Kết luận chương 2 ................................................................... ….42

Chƣơng 3: Kỹ thuật xử lý yêu cầu và đối phó với sự thay đổi.43
3.1 Yêu cầu chức năng và phi chức năng ..................................... ….43
3.1.1 Yêu cầu chức năng .................................................... ….44
3.1.3 Yêu cầu phi chức năng .............................................. ….45
3.2 Đặc tả yêu cầu ......................................................................... ….51
3.2.1 Đặc tả bằng ngôn ngữ tự nhiên.................................. ….54
3.2.2 Đặc tả theo cấu trúc ................................................... ….56
3.3 Thu thập và phân tìch yêu cầu ................................................ ….59
3.4 Xác nhận yêu cầu .................................................................... ….62
3.5 Đối phó với sự thay đổi .......................................................... ….64
3.5.1 Xây dựng nguyên mẫu .............................................. ….65
3.5.2 Chuyển giao từng phần .............................................. ….69

3.6 Phân tìch và thiết kế chương trính quản lý danh bạ điện thoại…72
3.6.1 Đặt vấn đề .................................................................. ….72
3.6.2 Đặc tả chức năng........................................................ ….73
3.6.3 Phương án giải quyết cụ thể ...................................... ….73
3.6.4 Xây dựng sơ đồ phân rã chức năng, phân tìch đầu vào
và đầu ra ............................................................................. ….75
3.6.5 Demo ứng dụng ......................................................... ….78
3.7 Kết luận chương 3 ................................................................... ….82
KẾT LUẬN ............................................................................................. ….83
DANH MỤC TÀI LIỆU THAM KHẢO ................................................ ….84
6


DANH MỤC CÁC HÌNH
Hình 1.1: Một kiến trúc hệ thống yếu kém
Hình 1.2: Một phương án cải tiến
Hình 2.1: Kỹ thuật phần mềm theo hướng sử dụng lại
Hình 2.2: Mô hình phát triển tăng tiến
Hình 2.3: Quá trình kỹ thuật lấy yêu cầu
Hình 2.4: Mô hình chung của quá trình thiết kế
Hình 2.5: Các giai đoạn kiểm thử
Hình 2.6: Các giai đoạn kiểm thử trong một quy trình phần mềm hướng kế hoạch
Hình 2.7: Nâng cấp phần mềm
Hình 3.1: Các dạng yêu cầu phi chức năng.
Hình 3.2: Số liệu cụ thể cho các yêu cầu phi chức năng
Hình 3.3: Một số cách viết đặc tả yêu cầu hệ thống
Hình 3.4: Ví dụ về yêu cầu cho hệ thống phần mềm bơm insulin
Hình 3.5: Một đặc tả yêu cầu có cấu trúc cho hoạt động bơm Insulin
Hình 3.6: Đặc tả dạng bảng tính toán việc bơm Insulin
Hình 3.7: Quy trình thu thập và phân tích yêu cầu

Hình 3.8: Quá trình xây dựng một nguyên mẫu
Hình 3.9: Chuyển giao từng phần
Hình 3.10: Sơ đồ phân rã chức năng
Hình 3.11: Sơ đồ luồng dữ liệu
Hình 3.12: Sơ đồ quản lý danh bạ
Hình 3.13: Sơ đồ quản lý tìm kiếm
Hình 3.14 – 3.15 – 3.16: Giao diện tìm kiếm và Kết quả tìm kiếm
Hình 3.17: Khi thêm số liên lạc vào danh bạ
Hình 3.18: Khi sửa thông tin số liên lạc
Hình 3.19: Khi xóa số liên lạc

7


MỞ ĐẦU
1. Lý do chọn đề tài
Cùng với sự ra đời và phát triển của công nghệ thông tin, công nghệ phần
mềm đã được hính thành như một nguyên lì khoa học và phát triển ngày càng
mạnh mẽ. Có thể hiểu công nghệ phần mềm là lĩnh vực của công nghệ thông
tin nhằm nghiên cứu và đề xuất các nguyên lì, qui trính công nghệ, phương
pháp và công cụ trợ giúp các quá trính thiết kế, cài đặt và bảo trí sản phẩm
phần mềm đáp ứng được các chỉ tiêu và chất lượng: tình đúng, tình khoa học,
tình tin cậy, tình vững vàng, tình dễ chuyển mang, tình dễ sử dụng, dễ phát
triển và hoàn thiên.
Kiến trúc phần mềm chình là một nhánh của công nghệ phần mềm có nhiệm
vụ quyết định cấu hính hệ thống thông qua việc mô tả các cấu phần và các mối
liên quan giữa các cấu phần trong hệ thống phần mềm.
Do nhu cầu thị trường, các hệ thống phần mềm phức tạp ngày càng tăng
trưởng. Cùng với nó, các nguyên lì và công cụ trợ giúp thiết kế và phát triển hệ
thống ngày càng gánh thêm trách nhiệm nặng nề và chuyên nghiệp. Có thể nói,

ngày nay, mỗi mô hính phát triển phần mềm quyết định một vài qui trính sản
xuất phần mềm, mỗi quy trính sản xuất phần mềm lại quyết định một vài loại
hính kiến trúc hiệu quả tương ứng.
Khi xây dựng và phát triển phần mềm nếu thực hiện đúng và đầy đủ
theo các giai đoạn của mô hính phần mềm đã lựa chọn, đặc biệt là giai đoạn thiết
kế, phần mềm sẽ tránh được sự rủi ro và có chất lượng tốt. Trên thực tế chúng
ta thường làm việc không có kế hoạch cụ thể, làm tới đâu nghĩ tới đó, xem nhẹ
bước thiết kế, coi trọng cài đặt mã nguồn. Kết quả mà chúng ta thu được thường
là một khối mã nguồn rối rắm hoặc nếu có thí cũng chỉ là một chương trính
nhỏ với vài chức năng cần thiết, rất khó cho bảo trí và tái sử dụng. Đôi khi,
chúng ta làm việc có phần chủ quan và mang tình tự phát, nhưng nếu bính tĩnh

1


nghiên cứu, làm việc có kế hoạch và áp dụng các tiến trính thiết kế phần
mềm vào trong bài toán của mính, chúng ta có thể thấy được nhiều hướng
đi, nhiều cách giải quyết, mà có thể đó là những lời giải tối ưu mà trước đó
chúng ta không thấy hoặc đã bỏ qua. Điều quan trọng hơn cả là chúng ta có
thể theo dõi và kiểm soát được những gí đang xảy ra. Thiết kế là đồng nghĩa
với việc tiết kiệm thời gian và tiền bạc. Nếu không có bản thiết kế hoặc thiết
kế không tốt, khi có thay đổi yêu cầu một vài chức năng trong phần mềm
hoặc nâng cấp, cải tiến các chức năng đó, chúng ta phải làm lại một chương
tính hoàn toàn mới hoặc phải nghiên cứu lại toàn bộ mã nguồn, điều đó đồng
nghĩa với việc tiêu tốn của chúng ta khá nhiều thời gian và tiền bạc. Ví thế tôi
chọn đề tài “ Phân tích các tiêu chí và quy trình kiến trúc phần mềm” nhằm
bổ sung thêm vào lì thuyết kiến trúc phần mềm được đầy đủ hơn. Mặt khác
dưới một góc nhín rộng và bao quát hơn, thông qua việc phản ánh các kết quả
của quá trính phân tìch, thiết kế thường xác định cho chúng ta nhiều hướng đi,
nhiều cách thức giải quyết trên cùng một bài toán, từ đó cho phép chúng ta

chọn được cách thức tốt nhất và con đường ngắn nhất để đi tới đìch
2. Mục đích nghiên cứu
Phân tìch các tiêu chì và quy trính kiến trúc phần mềm nhằm giúp chúng ta
nắm được các nguyên lì, cách thức tổ chức thiết kế kiến trúc phần mềm hay
có thể tái sử dụng phần mềm.
Hiểu được vai trò quan trọng của thiết kế kiến trúc phần mềm.
3. Nhiệm vụ nghiên cứu
Tím hiểu về kiến trúc phần mềm. Mô hính phát triển phần mềm, các hoạt
động trong quá trính phát triển phần mềm.
Đưa ra cách thức giải quyết bài toán của việc thiết kế kiển trúc phần mềm.
4. Đối tƣợng và phạm vi nghiên cứu
Đối tượng nghiên cứu của luận văn là tập trung tím hiểu một số tiêu chì và
quy trính xây dựng kiến trúc phần mềm.
2


Cách thức tổ chức, xác định xây dựng kiến trúc cho một phần mềm.
5. Phƣơng pháp nghiên cứu
Nghiên cứu tài liệu trong nước và quốc tế để tím hiểu, phân tìch, suy luận,
tổng hợp, đánh giá. Từ đó đề xuất nghiên cứu phân tìch các tiêu chì và quy
trính kiến trúc phần mềm.
6. Những đóng góp mới của đề tài
Đưa ra được cách thức tổ chức, xác định xây dựng kiến trúc cho một phần
mềm và xây dựng chương trính ứng dụng.
7. Cấu trúc luận văn
Luận văn gồm: Lời mở đầu, ba chương nội dung, phần kết luận và sau
cùng là tài liệu tham khảo.
Chương 1: Tổng quan về kiến trúc phần mềm
Chương 2: Quy trình phát triển phần mềm và các tiêu chì chất lượng của
sản phẩm phần mềm

Chương 3: Kỹ thuật xử lì yêu cầu và đối phó với sự thay đổi.

3


CHƢƠNG 1
TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM
1.1 Khái niệm kiến trúc phần mềm
Cùng với sự ra đời và phát triển của công nghệ thông tin, công nghệ phần
mềm đã được hính thành như một nguyên lì khoa học và phát triển ngày
càng mạnh mẽ. Có thể hiểu công nghệ phần mềm là lĩnh vực của công nghệ
thông tin nhằm nghiên cứu và đề xuất các nguyên lì, qui trính công nghệ,
phương pháp, và công cụ trợ giúp các quá trính thiết kế, cài đặt và bảo trí sản
phẩm phần mềm đáp ứng được các chỉ tiêu về chất lượng: tình đúng, tình
khoa học, tình tin cậy, tình vững vàng, tình dễ chuyển mang, tình dễ sử dụng,
dễ phát triển và hoàn thiện.
Kiến trúc phần mềm chình là một nhánh của công nghệ phần mềm có nhiệm
vụ quyết định cấu hính hệ thống thông qua việc mô tả các cấu phần và các
mối liên quan giữa các cấu phần trong hệ thống phần mềm.
Khoảng những năm sáu mươi của thế kỉ 20 đã bùng nổ một cuộc tranh luận về
toán tử đầy nghi vấn – toán tử GOTO trong ngôn ngữ lập trính. Chình cuộc
tranh luận này đã làm nảy sinh các ý tưởng và nguyên lì đầu tiên về công
nghệ phần mềm. Điều thú vị là, ngay từ những ngày đầu sơ khởi và chập
chững của công nghệ phần mềm, các phương pháp hính thức đã ra đời và phát
triển nhanh chóng. Hàng loạt công trính nghiên cứu có ý nghĩa của các nhà tin
học đầu đàn như Dijkstra, Dahl, Hoare, Boëhm đã nâng kĩ thuật lập trính
lên một tầm cao, mang tình chặt chẽ và hoàn thiện, rất gần với các ngành
khoa học chình xác [9]. Dahl và Dijkstra đã đề xuất nguyên lý lập trính theo
đặc tả hính thức, Hoare xây dựng hệ tiên đề chứng minh tình đúng của
chương trính thông qua các phương pháp toán học và suy luận logic, Boëhm

và Dijkstra chứng minh tình đủ của hai cấu trúc điều khiển tuần tự và lặp
4


while, trên cơ sở đó đề xuất khái niệm D-cấu trúcvới lời khuyên lập trính
viên chỉ nên sử dụng ba cấu trúc điều khiển một cách trong sáng và tao nhã
là cấu trúc tuần tự, cấu trúc rẽ nhánh và cấu trúc lặp điều kiện trước [6].
Do nhu cầu thị trường, các hệ thống phần mềm phức tạp ngày càng
tăng trưởng. Cùng với nó, các nguyên lì và công cụ trợ giúp thiết kế và phát
triển hệ thống ngày càng gánh thêm trách nhiệm nặng nề và chuyên
nghiệp. Nếu như trước đây, lập trính viên thường đảm đương luôn nhiệm vụ
của kiến trúc sư hệ thống thí ngày nay, việc đó là không thể, chưa nói
đến khả năng không được khuyến khìch. Các khái niệm và công nghệ mới
được hính thành và phát triển rất đa dạng. Có thể nói, ngày nay, mỗi mô hình
phát triển phần mềm quyết định một vài qui trính sản xuất phần mềm.
Đến lượt mính, mỗi qui trính sản xuất phần mềm lại quyết định một vài
loại hính kiến trúc hiệu quả tương ứng.
Thiết kế kiến trúc phần mềm là qui trính xác định các cấu phần và các
mối liên hệ giữa các cấu phần trong hệ thống phần mềm. [2]
Thiết kế kiến trúc đòi hỏi sự thấu hiểu về hệ thống. Mục tiêu cuối cùng
là xây dựng một cấu trúc tổng thể cho hệ thống. Trong mô hình qui trình phát
triển phần mềm, thiết kế kiến trúc là pha đầu tiên của quá trình thiết kế phần
mềm.
Có một mối liên hệ chặt chẽ giữa thiết kế và kĩ nghệ yêu cầu vì chúng
cùng chỉ rõ các cấu phần chính của hệ thống và các mối liên hệ giữa các cấu
phần đó.
+ Đầu vào : các yêu cầu đối với hệ thống.
+ Đầu ra : mô hình kiến trúc phản ánh tổ chức của hệ thống như một
tập các cấu phần có liên hệ với nhau. Toàn bộ sản phẩm đầu ra tạo thành một
bộ hồ sơ thiết kế kiến trúc.

5


Theo tiếp cận linh lợi, thiết kế kiến trúc nhín chung được thừa nhận là
pha sớm nhất của qui trình phát triển phần mềm. Nhiệm vụ chính của pha này
là khởi tạo được một kiến trúc tổng thể của hệ thống phần mềm.
Việc phát triển kiến trúc theo kiểu tăng trưởng nói chung là không hiệu
quả. Điều dễ hiểu là sửa đổi một cấu phần, một module hay một thủ tục trong
hệ thống là khá dễ, nhưng sửa đổi kiến trúc hệ thống trong quá trình phát triển
sẽ kéo theo nhiều phiền toái, nếu như có thể nói rằng là không thể.
Trong thực tế, có một phần giao nhau giữa hai quá trính: kĩ nghệ yêu
cầu và thiết kế kiến trúc. Về mặt lì tưởng, đặc tả hệ thống không nên chứa bất
kì thông tin kiến trúc nào của hệ thống, ngoại trừ các hệ thống nhỏ.
Kĩ nghệ yêu cầu bao gồm hai bước chính:
 Lấy yêu cầu.
 Đặc tả yêu cầu.
Phân rã kiến trúc hệ thống thường đòi hỏi sự phối hợp tinh tế giữa hai
tiến trình:
+ Viết đặc tả: chuyển các yêu cầu thường là dưới dạng ngôn ngữ tự nhiên
sang dạng chặt chẽ, không nhập nhằng.
+ Thiết kế cấu trúc: xác định các cấu phần và quan hệ giữa các cấu phần.
Do đó, như là một phần trong qui trính kĩ nghệ yêu cầu, ta cần tổ chức
trước hết, một kiến trúc trừu tượng (hiểu theo nghĩa bao quát), trong đó ta liên
kết các chức năng hoặc công cụ thành từng cấu phần hoặc hệ thống con. Sau
đó, ta có thể dựa trên kiến trúc khởi thuỷ này để thảo luận với những người có
thẩm quyền về các yêu cầu và công cụ cho hệ thống.
Hai kĩ thuật quan trọng nhất thường được vận dụng trong thiết kế cấu
trúc là trừu tượng hoá và phân rã.
-Trừu tượng hoá: Bỏ qua các chi tiết để tập trung vào những yếu tố chung

nhất,quan trọng nhất.

6


Thí dụ: để thiết kế kiến trúc cho phần mềm quản lí học tập cho học sinh tiểu
học ta trừu tượng hoá theo phương pháp đi lên từ mức cụ thể như sau:
+ Mức 0 (mức cụ thể). Phần mềm quản lí học tập cho học sinh tiểu học
+ Mức trừu tượng 1: Phần mềm quản lí học tập cho học sinh trung học cơ sở
(cấp 2)
+ Mức trừu tượng 2: Phần mềm quản lí học tập cho học sinh trung học phổ
thông (cấp 3)
+ Mức trừu tượng 3: Phần mềm quản lí học tập cho học sinh phổ thông
+ Mức trừu tượng 4: Phần mềm quản lí học tập cho học viên nói chung.
- Phân rã: Chia một cấu phần thành các cấu phần nhỏ hơn dựa theo chức
năng, thao tác hoặc tổ chức dữ liệu.
Tiêu chì cơ bản của phân rã là: bước sau làm chi tiết hơn bước trước, trong
khi vẫn bảo lưu khung của các bước trước.
Thiết kế kiến trúc phần mềm theo 2 cấp độ: nhỏ và lớn.
+ Kiến trúc nhỏ: liên quan đến các kiến trúc của chương trính máy tình riêng
biệt. Tại mức này ta quan tâm phân rã một chương trính cụ thể thành các
thành phần.
+ Kiến trúc lớn: liên quan đến các hệ thống phức hợp chứa các hệ thống khác,
các chương trính và các cấu phần của chương trính. Các hệ thống này phân
tán trên nhiều máy tình được nhiều đơn vị khác nhau quản lí.
1.2 Các quyết định trong thiết kế kiến trúc
Thiết kế kiến trúc là một quá trình sáng tạo trong đó bạn thiết kế cơ cấu
cho một hệ thống đáp ứng được các yêu cầu chức năng và phi chức năng của
hệ thống.
Các hoạt động diễn ra trong hệ thống phụ thuộc vào đặc thù của hệ thống

mà ta phát triển, phụ thuộc vào kiến thức nền và kinh nghiệm của kiến trúc
sư. Do đó, sẽ là tốt nếu ta tư duy về kiến trúc hệ thống như là một chuỗi các
quyết định cần thực hiện hơn là như một dãy hoạt động cần hoàn thành.
7


Trong quá trình thiết kế kiến trúc, các kiến trúc sư thường đối mặt với hàng
loạt quyết định cấu trúc ảnh hưởng đến hệ thống và quá trình phát triển hệ
thống. Dựa trên kiến thức và kinh nghiệm của mình các kiến trúc sư hệ thống
cần xem xét các vấn đề sau đây:
1. Ta có thể xuất phát từ một hình mẫu có sẵn?
2. Có thể phân rã hệ thống thành một số qui trình hoặc hạt nhân quen thuộc?
3. Có thể tái sử dụng các mẫu hoặc kiểu loại?
4. Tiếp cận nào là cơ bản?
5. Cấu phần nào cần làm mịn tiếp theo?
6. Chiến lược nào sẽ được sử dụng để điều khiển các thao tác trên các cấu
phần hệ thống?
7. Tổ chức kiến trúc nào là tốt nhất cho các yêu cầu phi chức năng?
8. Đánh giá bản thiết kế kiến trúc ra sao?
9. Lập hồ sơ kiến trúc ra sao?
Mỗi hệ thống phần mềm thường là duy nhất đối với một ứng dụng cụ
thể nên các hệ thống thuộc cùng một lĩnh vực ứng dụng thường có cùng một
kiến trúc thể hiện các quan niệm cơ bản của lĩnh vực ứng dụng đó. Ví dụ, các
ứng dụng của một dòng sản phẩm nào đó được thiết kế trên cơ sở ứng dụng
hạt nhân ban đầu với một số biến thể nhỏ nhằm đáp ứng các yêu cầu nâng cao
của người sử dụng. Sau khi khảo sát và phân tích các hạt nhân ban đầu, ta
chọn ra một vài hạt nhân có kiến trúc và chức năng gần nhất với hệ thống cần
thiết kế. Ta tiếp tục liệt kê các cấu phần và chức năng của các hạt nhân này
trong một bảng kiểm mục, trong đó ghi chú rõ chức năng nào là phù hợp,
chức năng nào cần loại bỏ, chức năng nào có thể được chỉnh sửa lại để tái sử

dụng...
Việc này có thể được lặp lại nhiều lần cho đến khi nhận được một phiên bản
mới về nguyên tắc và phù hợp với các yêu cầu cơ bản của hệ thống ta đang
cần thiết kế. [2]
8


Thí dụ:
1. Chúng ta cần thiết kế một hệ thống phần mềm (nhúng) cho một dòng điện
thoại di động mới M có màn hình cảm ứng thuộc hãng X.
Sau khi xác định được các yêu cầu cho hệ thống M, bạn có thể tìm hiểu các
phiên bản điện thoại di động có màn hình cảm ứng mới nhất trước đó, chẳng
hạn bạn chọn được hai sản phẩm là L và T của chính hãng X.
Bạn cần xác định cái gì là chung, là kế thừa, cái gì là mới, … các ưu và nhược
điểm của từng chức năng đó. Tiếp đến bạn quyết định xem có thể tái sử dụng
các cấu phần nào từ L và T.
2. So với các phần mềm cho máy tính cá nhân thì phần mềm nhúng chỉ sử
dụng một bộ xử lì do đó không cần đến khái niệm phân tán. Tuy nhiên nhiều
hệ thống lớn hiện nay lại là phân tán trên nhiều máy nên việc quyết định lựa
chọn một kiến trúc phân tán cho các thiết bị di động là khôn ngoan ví nó đáp
ứng được hiệu năng và độ tin cậy trong giao dịch, trong tương tác.
3. Khi cần thiết kế kiến trúc cho một hệ thống phân tán ta có thể khảo sát và
lựa chọn các mẫu kiến trúc và topo mạng máy tính: kiến trúc hình sao, kiến
trúc vòng, client-server, …
Để lựa chọn một cấu phần đưa vào hệ thống hoặc phân rã một thành
phần hoặc một cấu phần của hệ thống, kiến trúc sư hệ thống cần được trang bị
các kiến thức và chiến lược trong lý thuyết hệ thống.
Phần mềm nhúng: phần mềm cài trong các thiết bị, chủ yếu là các thiết
bị điều khiển, thiết bị di động chuyên dụng.
Đặc điểm chung:

+ Không cài đặt cho các máy tính lớn và máy tính cá nhân (nhưng
thường được thiết kế và sản xuất trên các máy tính có môi trường mô phỏng
thiết bị);
+ Thường dùng một bộ xử lí;
+ Nhỏ gọn;
9


+ Được nhúng (ghi dưới dạng mã máy, mã đích) trong các vi mạch
điện tử.
+ Hiện đang có nhu cầu thị trường rất lớn.
Dưới đây là một minh hoạ gồm các phân tích ngắn gọn một số tiêu chí
mang tính chỉ đạo cho việc xây dựng kiến trúc cho một hệ phân tán:
1. Hiệu năng là đòi hỏi quan trọng nhất. Kiến trúc được xây dựng để phục vụ cho
các thao tác địa phương trong một nhóm nhỏ các cấu phần sẽ thực thi trên một
máy tình (địa phương) chứ không thực thi trên mạng. Do đó bạn cần lưu ý đến
nguyên tắc: hạn chế liên kết vì liên kết đòi hỏi thêm chi phí xử lì đồng bộ hoá và
tổ chức thời gian thực…
Hiệu năng của hệ thống: thể hiện mức độ hiệu quả và khả năng phục vụ
của hệ thống, thí dụ tốc độ xử lí hay số đơn vị dữ liệu được xử lí trong một đơn
vị thời gian.
2. Tính bảo mật. Gần như mọi hệ thống phân tán đều đòi hỏi cơ chế bảo mật.
Vậy là bạn phải chọn một kiến trúc theo lớp, phân tầng để có thể tổ chức được
các thủ tục và qui trình bảo mật cho hệ thống;
3. An toàn và toàn vẹn. Các thao tác liên quan đến tính an toàn (và toàn vẹn)
được gói vào một cấu phần hoặc một nhóm nhỏ các cấu phần. Tổ chức kiểu này
sẽ làm giảm chi phì săn sóc, theo dõi và bảo vệ cho hệ thống và dữ liệu được an
toàn và toàn vẹn. Thí dụ, trong các hệ thống thường có chế độ thực hiện sao lưu
tự động và các cơ chế cảnh báo trước khi người sử dụng định thực hiện các thao
tác có thể vi phạm tính toàn vẹn như xoá (delete) dữ liệu, chuyển dịch (move) dữ

liệu, huỷ bỏ (cancel, stop), tái khởi động (reset, uninstall) hệ thống hoặc tiến
trình, chuyển đổi hoặc tạo lại (format) khuôn dạng thiết bị...
Tính an toàn và toàn vẹn: dữ liệu và chương trính không bị biến dạng, sai
lệch sau các thao tác của người sử dụng. Có cơ chế ngăn chặn, cảnh báo và khôi
phục lại hệ thống và dữ liệu sau các sự cố như mất điện, treo máy hoặc các thao
tác vô tình hoặc cố ý làm sai lệch dữ liệu và hệ thống.

10


4. Sẵn sàng: Để đảm bảo tính sẵn sàng, hệ thống của bạn nên có thêm các cấu
phần dư thừa để thay thế khi cần. Ngoài ra, hệ thống của bạn nên có cơ chế sao
lưu hoặc tổ chức bộ nhớ cache để khi cần có thể làm việc trong chế độ gián
tuyến (offline)
Tính sẵn sàng của hệ thống: hệ thống có khả năng phục vụ trong nhiều
trạng thái và ngữ cảnh. Thí dụ, khi một phần của mạng bị hỏng hệ thống vẫn làm
việc với phần còn lại của mạng và sau đó, khi sự cố đã được khắc phục, hệ thống
có thể cập nhật lại các cấu hình, trạng thái và dữ liệu cho các điểm mạng thuộc
phạm vi quản lí của mình.
5. Khả năng duy tu: Nếu có yêu cầu bắt buộc về khả năng duy tu hệ thống, bạn
nên quan tâm đến những thành phần hạt nhân đủ nhỏ và độc lập có khả năng tổ
hợp cao nhằm đáp ứng được những yêu cầu mới. Bạn cũng nên tách hai cơ chế
phát sinh / lưu trữ dữ liệu (thuộc về người quản trị hệ thống) và khai thác dữ liệu
(dành cho người sử dụng hệ thống).

Online: hoạt động trực tuyến. Khách và chủ giao lưu trực tiếp theo thời
gian thực. Thí dụ, từ máy tính của mình bạn đang nhập vào một hệ thống dịch
vụ nào đó, bán hàng trên mạng chẳng hạn, và làm việc, trao đổi với hệ thống
đó.
Off-line: hoạt động gián tuyến. Khách làm việc trong chế độ không kết

nối với chủ.Thí dụ, sau khi lấy được thông tin về một số mặt hàng cần mua,
bạn tạm ngắt kết nối với hệ thống bán hàng trên mạng để suy nghĩ, trao đổi
với mọi người và điền các thông tin vào các file mẫu.
Hệ thống có khả năng duy tu là hệ thống được thiết kế để khi cần thiết
có thể nâng cấp hoặc có đủ cơ chế linh hoạt để đáp ứng được các yêu cầu
mới, khó dự đoán trước. Thí dụ, khi xây dựng hệ thống làm việc trên mạng thế
hệ 2 ta nên nghĩ ngay đến khả năng sau này hệ thống sẽ được nâng cấp để có
thể làm việc trên mạng thế hệ 3.

11


Thành phần hạt nhân: thành phần cơ sở của hệ thống, làm nền, làm hạ
tầng để từ đó xây dựng toàn bộ hệ thống.
Thí dụ, hạt nhân của hệ điều hành thực thi các chức năng cơ bản của hệ điều
hành ở mức thấp, giao diện đơn giản.
Dĩ nhiên là có một số tiêu chí có thể đối kháng nhau trong các kiến trúc
trên. Thí dụ, các cấu phần lớn được trang bị cơ chế tối ưu hoá thường trợ giúp
tính hiệu quả, ngược lại, các cấu phần cơ sở và nhỏ thường dễ duy tu. Nếu hai
yêu cầu về tính hiệu quả và tình duy tu đều phải được coi trọng thì kiến trúc
sư hệ thống cần phải theo đuổi một chình sách dung hoà. Điều này cắt nghĩa lì
do vì sao kiến trúc sư hệ thống thường sử dụng vài loại hình mẫu khác nhau
cho các hệ thống khác nhau.
Thành phần độc lập (thành phần dễ chuyển mang): một module (đơn
thể) chương trính có thể chuyển từ hệ thống này sang hệ thống khác. Module
đó có thể hoạt động trong nhiều chủng loại máy tình và môi trường khác
nhau.
Thí dụ, lớp các thủ tục vào/ra, lớp các hàm toán học, lớp đồ hoạ được thiết kế
để dùng chung cho nhiều ngôn ngữ và môi trường lập trình.
Hình mẫu: Một kiến trúc có thể dùng chung cho một lớp các hệ thống.

Thí dụ: Kiến trúc hệ điều hành, kiến trúc giao diện đồ hoạ, kiến trúc xử lí giao
dịch.
1. Có thể thực hiện kiểm định logic cho phác thảo kiến trúc ban đầu.
Kiểm định hệ thống là hoạt động xác định:
 Hệ thống có đáp ứng đầy đủ và chính xác các yêu cầu đã đề ra?
 Hệ thống có hoạt động đúng như ta mong muốn không?
Kiểm định logic quan tâm chủ yếu đến tính hợp lí, phi mâu thuẫn trong
cấu trúc và hoạt động của hệ thống.
Kiến trúc ban đầu thường rất đơn giản, nhưng không ví thế mà bạn có thể bỏ
qua việc kiểm tra. Lý do là như sau:
12


Nguyên lý lỗi nặng : Lỗi nặng nhất thường sinh ra tại các pha ban đầu.
Thí dụ
Ta phân tích một thí dụ đơn giản.
Giả sử ta cần xây dựng một hệ thống dịch vụ đa năng trên mạng.
Thiết kế ban đầu của ta được biểu diễn dưới dạng một sơ đồ khối đơn
giản gồm có bốn khối thể hiện trình tự đón khách và phục vụ theo 4 bước như
sau:

Hình 1.1: Một kiến trúc hệ thống yếu kém
Bước 1. Khách đăng nhập hệ thống: Điền trực tuyến (online) theo mẫu
sau đó trả phí dịch vụ.
Bước 2. Hệ thống tự trình diễn: giới thiệu về công ti và các dịch vụ hệ
thống đảm nhiệm.
Bước 3. Hướng dẫn khách lựa chọn dịch vụ cần thiết.
Bước 4. Phục vụ khách theo dịch vụ đã chọn.
Điều bất tiện ở kiến trúc này là gì?
Hãy tưởng tượng, một vị khách mới, chưa hề biết gì về công ti dịch vụ này.

Vị khách muốn xem thông tin giới thiệu công ty. Nhu cầu này chỉ được đáp
ứng sau khi khách đã đăng nhập vào hệ thống. Mà việc đang nhập này đòi hỏi
phải trả phí. Dĩ nhiên, khi trao đổi với những người có thẩm quyền ta có thể
phát hiện ra một số điểm bất hợp lí dựa trên các gợi ý về mặt nguyên tắc như
sau:

13


+ Danh có chính, ngôn mới thuận: Việc tiên quyết là giới thiệu về công
ty.
+ Sử dụng dịch vụ nào thì trả phí riêng cho dịch vụ đó.
Như vậy là phải tách cấu phần đầu tiên thành hai cấu phần riêng biệt, độc lập
nhau là đăng nhập và thu phí. Cấu phần thu phí sẽ được đặt sau cấu phần phục
vụ.
Nếu kiến trúc sư hệ thống chịu khó khảo sát các mẫu thông dụng trên
thị trường thì có thể đề xuất được ngay một kiến trúc khá hợp lệ như sau:
Kiến trúc này có thêm pha dùng thử. Tuỳ theo mục đìch cung ứng, nhà cung
ứng có thể giới hạn thời gian hoặc / và chức năng được dùng thử.

Hình 1.2: Một phương án cải tiến
2. Sau mỗi bước phân rã, làm mịn kiến trúc hệ thống rất nên thực hiện kiểm
định. Nhận định này được trình bày chi tiết trong giáo trình "Kiểm định phần
mềm".
3. Đánh giá kiến trúc là việc khó, đặc biệt là đối với các yêu cầu phi chức
năng ví hệ thống chưa thực thi, mới nằm trên giấy. Thí dụ minh hoạ nói trên
chỉ liên quan đến các yêu cầu về chức năng. Từ nhận định này ta thấy việc
trao đổi thường xuyên các phương án kiến trúc với những người có thẩm

14

quyền là rất quan trọng. Ngoài ra, để giảm nhẹ gánh nặng và áp lực, kiến trúc
sư hệ thống nên khảo sát và đánh giá các hệ thống và các mẫu hiện hành.
1.3 Các quan điểm trong kiến trúc phần mềm
Các mô hình kiến trúc của một hệ thống phần mềm rất cần và có thể được
sử dụng để thảo luận về các yêu cầu giữa nhóm thiết kế, phát triển phần mềm
và những người có thẩm quyền. Hơn nữa, các mô hình này còn có thể được sử
dụng để lập hồ sơ kiến trúc trong các bước làm mịn sau này. Có hai vấn đề
quan trọng sau đây:
1. Khi thiết kế và lập hồ sơ cho kiến trúc hệ thống ta vận dụng các quan điểm
nào và dự đoán viễn cảnh của hệ thống ra sao?
2. Khái niệm nào cần thiết cho mô tả kiến trúc hệ thống? Không thể biểu diễn
mọi thông tin về kiến trúc hệ thống với một tập các mô hính đơn giản và tổng
qúat lúc đầu, vì mỗi mô hình chỉ phản ánh một quan điểm và một viễn cảnh của
hệ thống. Chẳng hạn, nó chỉ có thể cho biết rằng hệ thống sẽ được làm mịn, phân
rã thành các đơn thể nào, cũng như các tiến trình thời gian thực sẽ tương tác với
nhau ra sao hoặc vận dụng các phương thức nào để phân bố các cấu phần của hệ
thống đối với mô hình phân tán. Chúng ta luôn luôn cần cả một lớp các quan
điểm cho các bước tiếp theo.

Krutchen (1995), đề xuất mô hính (4+1) quan điểm cho kiến trúc phần
mềm. Đó là:
Nguyên lí khung nhìn: Có thể và nên quan sát, xem xét, phân tích và xử lí sự
vật và hiện tượng theo các góc nhìn và khung nhìn khác nhau. Xét theo quan
điểm nào thì phải xử lì theo phương thức tương ứng.
1.Quan điểm logic
Quan điểm này giúp chúng ta thể hiện các đối tượng và lớp trừu tượng
cơ bản trong hệ thống, thể hiện các yêu cầu về thực thể dưới dạng các quan
niệm logic.

2. Quan điểm tiến trình
15


Vào thời điểm hệ thống hoạt động ta phải hình dung rõ các qui trình
tương tác của hệ thống. Khi tuân thủ quan điểm tiến trính, điều quan trọng là
phải hiểu được các yêu cầu phi chức năng như tình hiệu năng hoặc tính hữu
dụng.
3. Quan điểm phát triển
Theo quan điểm phát triển, ta giải thìch được hệ thống sẽ được phân rã
ra sao trong quá trình phát triển. Quan điểm phát triển là hữu ìch đối với các
nhân viên quản trị và lập trình viên.
4. Quan điểm vật lí
Quan điểm vật lì giúp ta xác định được phần cứng và phần mềm tương
ứng trong hệ thống. Quan điểm này rất quen thuộc đối với các kĩ sư hệ thống.
Khung quan điểm hay khung nhìn chính là khung trừu tượng làm cơ sở
cho quá trình phân rã các yêu cầu mức cao thành các đặc tả chi tiết giúp cho
các nhân viên quyết định chọn các cấu phần dùng lại và thể hiện các dòng sản
phẩm.
Trong thực tiễn, khung nhín được sử dụng với tần suất cao. Nó cũng là cơ sở
để trao đổi giữa nhóm phát triển phần mềm và những người có thẩm quyền.
Thí dụ, Có nhiều quan điểm khác nhau về khả năng sử dụng UML (Unified
Modeling Language - Ngôn ngữ mô hình hóa thống nhất) và các môi trường
đặc tả khác nhau trong thiết kế kiến trúc .
Nếu ta tiếp cận theo hướng đối tượng thì nên sử dụng UML. Ngoài ra ta
có thể sử dụng các công cụ khác như các ngôn ngữ mô tả chuyên dụng
(Specialized Architectural Description Languages, ADLs) với các phần tử cơ
sở là các thành phần và các đường nối.
1.4 Kết luận chƣơng 1
Chương 1 trính bày tóm lược về khái niệm cơ sở lì thuyết hệ thống kiến

trúc phần mềm, các quan điểm, quyết định trong thiết kế kiến trúc phần mềm,
phát triển phần mềm.
16


CHƢƠNG 2
QUY TRÌNH PHÁT TRIỂN PHẦN MỀM VÀ CÁC TIÊU CHÍ
CHẤT LƢỢNG CỦA SẢN PHẨM PHẦN MỀM
2.1 Mô hình phát triển phần mềm
Mô hình phát triển phần mềm là một hệ thống các quan niệm, phương
pháp, qui trình, kỹ thuật vận dụng trong phát triển phần mềm. Tên gọi mô
hình thường trùng với tên của qui trình phát triển phần mềm.
Một số mô hình phát triển phần mềm
 Mô hình tuyến tính.
 Mô hính thác nước.
 Mô hính tăng trưởng.
 Mô hình xoắn ốc.
 Mô hình bậc thang.
Các mô hình nói chung có những thành phần tương tự nhau, chúng
khác nhau ở trình tự tổ hợp, lắp ghép các thành phần. Điểm khác biệt nổi trội
hơn cả giữa các mô hình là các vòng lặp thể hiện qui trình làm mịn tại các pha
của qui trình.
2.1.1 Xác định từ một mô hình mẫu có sẵn
Trong phần lớn các dự án phần mềm, có một số phần mềm được tái sử
dụng. Điều này thường xảy ra khi những người làm dự án biết những thiết kế
hoặc mã nào tương tự như những gí được yêu cầu. Họ sẽ tím chúng, sửa đổi
khi cần thiết, và sáp nhập chúng vào hệ thống của họ.
Tái sử dụng không theo quy định này diễn ra không phân biệt việc sử
dụng quy trính phát triển nào. Tuy nhiên, trong thế kỉ 21, quy trính phát triển
phần mềm tập trung vào tái sử dụng các phần mềm hiện có được sử dụng rộng

rãi. Phương pháp hướng tái sử dụng các phần mềm hiện có được sử dụng rộng
17


rãi. Phương pháp hướng tái sử dụng dựa trên một lượng lớn các thành phần
phần mềm tái sử dụng và nền tảng tìch hợp các thành phần.
Một mô hính chung của quy trính phát triển dựa trên sử dụng lại được
thể hiện trong hình 2.1. Mặc dù các yêu cầu ban đầu trong giai đoạn đặc tả và
giai đoạn xác nhận có thể so sánh được với các quá trính phần mềm khác, các
giai đoạn trung gian trong kỹ thuật hướng tái sử dụng có khác nhau. Các giai
đoạn này là:
1. Phân tìch thành phần (Component analysis): Căn cứ vào đặc tả yêu cầu,
thực hiện một tím kiếm các thành phần có thể thực hiện đặc tả đó. Thông
thường, không có đánh dấu chình xác và các thành phần có thể được sử dụng
chỉ cung cấp một số chức năng cần thiết.
2. Sửa đổi yêu cầu (Requirements modification): Trong giai đoạn này, các yêu
cầu được phân tìch bằng cách sử dụng thông tin về các thành phần đã được
phát hiện. Sau đó, chúng được sửa đổi để phù hợp với các thành phần có sẵn.
Trong trường hợp không thể thay đổi, hoạt động phân tìch thành phần có thể
được dựa vào để tím kiếm giải pháp thay thế.
3. Thiết kế hệ thống với thành phần tái sử dụng (System design with reuse):
Trong giai đoạn này, khuôn mẫu của hệ thống được thiết kế hoặc sử dụng lại
khuôn mẫu hiện tại. Các nhà thiết kế đưa vào hệ thống các thành phần được
tái sử dụng và sắp xếp các nền tảng để phục vụ cho việc này. Một số phần
mềm mới có thể được thiết kế nếu không có các thành phần tái sử dụng.
4. Phát triển và tìch hợp (Development and integration): Phần mềm phát triển
không thể đem ra bên ngoài, và các thành phần cũng như hệ thống COTS
được tìch hợp để tạo ra hệ thống mới. Tìch hợp hệ thống, trong mô hình này,
có thể là một phần trong quy trính phát triển chứ không phải là một hoạt động
riêng biệt

18