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

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ăn

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

HÀ NỘI, 2014

3

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

4

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 năm 2014

Tác giả

Lưu Thành Sơn

5

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

6

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

7

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

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

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

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

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à hồ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ề tốn tử đầy nghi vấn – tố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à hồ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 tố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

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

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

+ 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

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

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]

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;

+ Đượ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à

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

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

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:

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:

Đ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:

+ 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

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

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

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

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

Hình 2.1: Kỹ thuật phần mềm theo hướng sử dụng lại

Có ba loại thành phần phần mềm có thể được sử dụng trong một quy trính tái sử dụng:

1 Các dịch vụ Web (web service) được phát triển theo tiêu chuẩn dịch vụ và được gọi từ xa

2 Tập hợp các đối tượng được phát triển như là một package được tìch hợp với một nền tảng như NET hay J2EE

3 Hệ thống phần mềm độc lập được cấu hính để sử dụng trong một môi trường cụ thể

Kỹ thuật tái sử dụng phần mềm có ưu điểm rõ ràng là giảm số lượng phần mềm cần phát triển và do đó, giảm chi phì và rủi ro Điều này thường dẫn đến việc bàn giao phần mềm nhanh hơn Tuy nhiên, vấn đề thỏa hiệp các yêu cầu là không thể tránh khỏi và điều này có thể làm cho hệ thống không đáp ứng các nhu cầu thực sự của người sử dụng Hơn nữa, một số kiểm soát phát triển hệ thống như bị mất phiên bản mới của các thành phần tái sử dụng không nằm dưới sự kiểm soát của doanh nghiệp sử dụng chúng

Đặc tả yêu

cầu

Phân tích thành phần

Thay đổi yêu cầu

Thiết kế hệ thống

có thể tái sử dụng

Phát triển và tìch hợp

Kiểm tra và đánh giá hệ thống

2.1.2 Xác định từ mô hình phát triển phần mềm

Phát triển gia tăng (hay còn gọi là mô hính tăng tiến) dựa trên ý tưởng phát triển một triển khai ban đầu đầy đủ, đưa vào sử dụng cho người dùng nhận xét và phát triển phần mềm thông qua vài phiên bản cho đến khi phát triển được một hệ thống đầy đủ (hình 2.2) Các hoạt động đặc tả, phát triển, xác nhận được thực thi xen kẽ nhau chứ không riêng biệt, với thông tin phản hồi nhanh chóng trên tất cả các hoạt động

Hình 2.2: Mô hình phát triển tăng tiến

Phát triển phần mềm gia tăng, là phần cơ bản của các phương pháp Agile, tiếp cận tốt hơn so với mô hính thác nước cho các hệ thống kinh doanh, thương mại điện tử, và hệ thống cá nhân Phát triển gia tăng phản ánh cách chúng ta giải quyết vấn đề Bằng cách phát triển phần mềm từng bước, phương páp này có chi phì thấp hơn và thay đổi phần mềm dễ dàng hơn trong quá trính phát triển nó

Phiên bản hoàn thiện

Các công việc thực hiện đồng thời

Mỗi phần gia tăng hoặc phiên bản của hệ thống kết hợp một số chức năng khách hàng cho là cần thiết Nói chung, các phần gia tăng đầu của hệ thống gồm các chức năng quan trọng nhất hoặc yêu cầu cấp bách nhất Điều này có nghĩa là khách hàng có thể đánh giá hệ thống ở giai đoạn tương đối sớm trong quá trính phát triển nếu nó cung cấp được những gí được yêu cầu Nếu không, sau đó phiên bản hiện tại được thay đổi và có thể thêm các chức năng mới vào các phiên bản sau này

So với mô hính thác nước, phát triển gia tăng có ba ưu điểm quan trọng:

1 Chi phì thực hiện đáp ứng thay đổi yêu cầu của khách hàng được giảm thiểu Yêu cầu phân tìch và viết tài liệu đã được làm lại ìt hơn rất nhiều so với yêu cầu của mô hính thác nước

2 Dễ dàng lấy được thông tin phản hồi của khách hàng về phiên bản phát triển đã được thực hiện Khách hàng có thể nhận xét về các minh họa của phần mềm và nhín thấy chúng được thực thi như thế nào Tuy nhiên, khách hàng khó có thể đánh giá sự tiến bộ từ các tài liệu thiết kế phần mềm

3 Phân phối và triển khai các phần mềm hữu ìch cho khách hàng nhanh chóng hơn, ngay cả khi tất cả các chức năng chưa đầy đủ Khách hàng có thể

sử dụng và đạt được giá trị từ phần mềm sớm hơn so với quy trính theo mô hính thác nước

Phát triển gia tăng trong một vài hính thức hiện nay là phương pháp phổ biến nhất cho việc phát triển các hệ thống ứng dụng Cách tiếp cận này có thể là một trong hai phương pháp, phương pháp có kế hoạch hoặc phương pháp Agile, hoặc thông thường hơn, là sự kết hợp của hai phương pháp này

Vấn đề với mô hính phát triển gia tăng

Mặc dù, mô hính phát triển gia tăng có nhiều ưu điểm nhưng không phải là nó không có vấn đề Nguyên nhân chình của khó khăn hay gặp phải là trong thực

tế các công ty, tổ chức lớn có các thủ tục quy trính công việc bắt buộc phải

tuân theo và nó không phù hợp với việc lặp đi lặp lại giữa các thủ tục này với

mô hính lặp hay quy trính Agile

Từ quan điểm quản lý, phương pháp tiếp cận gia tăng có hai vấn đề:

1 Quá trình không rõ ràng Nhiều người quản lý cần xác định được tiến độ công việc Nếu hệ thống được phát triển một cách nhanh chóng, cách thức này không hiệu quả cho việc tao ra tài liệu ghi lại tất cả các phiên bản của hệ thống

2 Cấu trúc hệ thống có xu hướng suy thoái khi phần gia tăng mới được thêm vào Trừ khi nhà phát triển dành nhiều thời gian và chi phì cho việc tái cấu trúc để cải thiện phần mềm, thay đổi thường xuyên có xu hướng làm hỏng cấu trúc của nó Tiếp tục thay đổi phần mềm trở nên ngày càng gây ra khó khăn

và tốn kém

Những vấn đề của phát triển gia tăng trở nên đặc biệt nghiêm trọng cho các hệ thống lớn, phức tạp, lâu đời, nơi nhiều đội khác nhau phát triển các bộ phận khác nhau của hệ thống Các hệ thống lớn cần có một khuôn mẫu hoặc kiến trúc ổn định và trách nhiệm của các đội khác nhau làm việc với các bộ phận của hệ thống cần phải được xác định rõ ràng đối với kiến trúc đó Điều này cần phải lên kế hoạch trước chứ không phải thể được phát triển từng bước

2.1.3 Phương pháp phát triển phần mềm Agile

a Sự ra đời của các phương pháp Agile

Ở cuối thập kỉ 80 và đầu thập kỉ 90, trong kĩ nghệ phần mềm thịnh hành quan điểm, đó là cách tốt nhất để xây dựng được những phần mềm chất lượng hơn nữa là lập kế hoạch dự án một cách tỉ mỉ, chuẩn hóa các tiêu chì chất lượng và sử dụng các công cụ CASE (Computer-Aided Software Engineering – Kỹ nghệ phần mềm có sự trợ giúp của máy tình), và giám sát nghiêm ngặt quá trính phát triển phần mềm Sau đó, các quan điểm này được tổng quát hóa thành các phương pháp phát triển phần mềm có kế hoạch Tuy

nhiên, phương pháp này xem là cách thức “nặng nề” khi áp dụng cho các hệ thống doanh nghiệp nhỏ và vừa ví nó tốn một khoản chi phì không cần thiết cho việc viết tài liệu và xử lý các thay đổi bất ngờ xảy ra

Không thỏa mãn với phương pháp phát triển phần mềm theo kế hoạch, nhiều lập trính viên đã nhất trì đề xuất ra các phương pháp phát triển phần mềm Agile Các phương pháp này tập trung vào chình phần mềm chứ không tập trung vào quá trính thiết kế và viết tài liệu Các phương pháp Agile tổng quan dựa trên phương thức tiếp cận gia tăng trong quá trính xác định định đặc

tả, xây dựng và bàn giao Chúng phù hợp nhất để xây dựng các ứng dụng có yêu cầu thường xuyên thay đổi trong quá trính phát triển Phương pháp này nhằm hướng tới bàn giao sản phẩm cho khách hàng một cách nhanh nhất, và khách hàng có thể đề xuất nhiều yêu cầu mới hoặc thay đổi chức năng của chương trính Mục tiêu của các phương pháp Agile là giảm thiểu các chi phì không cần thiết giảm bớt các tài liệu ìt được sử dụng

b Tuyên ngôn Agile

 Con người và sự tương tác hơn là quy trính và công cụ

 Phần mềm chạy tốt hơn là tài liệu đầy đủ

 Cộng tác với khách hàng hơn là đàm phán hợp đồng

 Phản hồi với các thay đổi hơn là bám sát kế hoạch

c Các nguyên tắc Agile

Trong số các phương pháp Agile thí phương pháp lập trình cực hạn XP

(Beck, 1999; Beck 2000) là một trong những phương pháp hoàn thiện nhất và nhận được nhiều sự quan tâm nghiên cứu nhất Các phương pháp phát triển phần mềm Agile khác bao gồm:

Phát triển trong hỗn độn – Scrum (Cohn, 2009; Schwaber, 2004; Schwaber and Beedle, 2001), Crystal (Cockburn, 2001; Cockburn, 2004)

Phát triển phần mềm có khả năng thìch nghi (Highsmith, 2000)

Phương pháp phát triển hệ thống động (Stapleton, 1997; Stapleton, 2003) Phát triển theo tình năng (Palmer and Felsing, 2002)

Sự thành công của các phương pháp này dẫn đến việc có thể kết hợp chúng với phương pháp phát triển truyền thống dựa trên ý tưởng mô hính hóa Agile (Ambler and Jeffries, 2002) và những thuyết minh Agile về quy trính Phát triển phần mềm thống nhất

Dưới đây là một số nguyên tắc khi sử dụng phương pháp Agile, các nguyên tắc này đều được thừa kế từ Tuyên ngôn Agile:

 Sự cộng tác với khách hàng: gắn bó khăng khìt với khách hàng trong suốt quá trính phát triển Khách hàng có vai trò cung cấp và đưa ra mức

ưu tiên cho các yêu cầu hệ thống mới và đánh giá từng chu trính lặp của hệ thống

 Bàn giao các gói phần mềm gia tăng: Phần mềm được phát triển với nhiều phiên bản, mỗi phần gia tăng có nhiều yêu cầu mới của khách hàng được thêm vào

 Con người quan trọng hơn quy trính: Công nhận và khai thác các kỹ năng của đội ngũ phát triển Các thành viên trong nhóm có thể tự phát triển theo từng hướng riêng của họ nhưng vẫn phải tuân theo nguyên tắc chung

 Đón nhận sự thay đổi: Khuyến khìch các yêu cầu thay đổi hệ thống từ phìa khách hàng để sửa đổi và từ đó thiết kế hệ thống thìch ứng với những thay đổi

 Duy trí tình đơn giản: Đơn giản hóa các vấn đề ở cả phần mềm xây dựng và cả quá trính phát triển phần mềm Tìch cực loại bỏ những gí phức tạp của hệ thống bất cứ khi nào có thể

d Áp dụng các phương pháp Agile trong kỹ nghệ phần mềm

Phương pháp Agile thành công trong việc phát triển một số hệ thống có đặc điểm như sau:

1.Sản phẩm công ty phát triển có kìch thước nhỏ hoặc trung bính

2.Tùy chỉnh loại hính phát triển phần mềm phù hợp với từng doanh nghiệp thiết lập một cam kết rõ ràng với khách hàng để họ cùng tham gia trong quá trính phát triển, cố gắng giảm thiểu các quy tắc bên ngoài

và các quy định có ảnh hưởng đến phần mềm

3.Do phương pháp Agile tập trung cho mô hính các đội dự án nhỏ, làm việc chặt chẽ với nhau nên sẽ phát sinh nhiều vấn đề khi áp dụng các phương pháp này cho các hệ thống lớn

2.2 Hoạt động trong các quá trình

Quy trính phần mềm thực sự là trính tự xen kẽ các hoạt động kỹ thuật, hoạt động hợp tác, và hoạt động quản lý với mục tiêu tổng thể của việc xác định, thiết kế, triển khai thực hiện, và kiểm tra một hệ thống phần mềm Các nhà phát triển phần mềm sử dụng một loạt công cụ phần mềm khác nhau trong công việc của họ Các công cụ đặc biệt hữu ìch để hỗ trợ chỉnh sửa các loại tài liệu khác nhau và quản lý lượng thông tin chi tiết khổng lồ phát sinh trong một dự án phần mềm lớn

Bốn hoạt động cơ bản trong một quy trính là đặc tả kỹ thuật, thiết kế, phát triển, xác nhận và nâng cấp được sắp xếp khác nhau trong các quy trính phát triển khác nhau Trong mô hính thác nước, trong các hoạt động này được

tổ chức theo thứ tự, còn trong quy trính phát triển gia tăng là sắp xếp chúng xen kẽ Cách thức thực hiện các hoạt động này phụ thuộc vào loại phần mềm, nguồn nhân lực và cơ cấu doanh nghiệp Vì dụ trong lập trình cực hạn, các đặc tả chi tiết được ghi vào các thẻ (cards) Kiểm tra được thực thi và phát triển trước khi lập trính Sự nâng cấp có thể liên quan đến chuyển dịch hay tái cấu trúc hệ thống

2.2.1 Đặc tả phần mềm

Đặc tả phần mềm (software specification) hay còn gọi là kỹ thuật yêu vầu (requirements engineering) là quá trính nắm rõ và xác định dịch vụ nào được yêu cầu trong hệ thống cùng với việc xác định các ràng buộc trong quá trính vận hành và phát triển hệ thống Giai đoạn kĩ thuật yêu cầu đặc biệt quan trọng trong quy trính phần mềm ví nếu xảy ra lỗi ở giai đoạn này chắc chắn dẫn đến nhiều vấn đề sau này trong việc thiết kế và thực hiện hệ thống

Mục đìch của quá trính kỹ thuật yêu cầu (hình 2.3) là đưa ra tài liệu yêu cầu thống nhất định rõ một hệ thống thỏa mãn yêu cầu của các bên liên quan Yêu cầu thường được trính bày ở hai mức chi tiết Người dùng cuối và khách hàng cần trính bày yêu cầu tổng quan, bên phát triển hệ thống cần đặc tả kỹ thuật

hệ thống chi tiết hơn

Hình 2.3: Quá trình kỹ thuật lấy yêu cầu

Có bốn hoạt động chình trong quá trính kỹ thuật yêu cầu:

1 Nghiên cứu khả thi (feasibility study): Thực hiện một dự đoán rằng việc sử dụng phần mềm hiện tại và công nghệ phần cúng có thể làm thỏa mãn nhu cầu

Nghiên cứu

tình khả thi

Thu thập và phân tích yêu cầu

Đặc tả yêu cầu

Xác nhận yêu cầu

và hệ thống

người dùng hay không? Nghiên cứu, xem xét hệ thống được đề xuất có hiệu quả chi phì từ góc nhín quan điểm kinh doanh và có thể phát triển hệ thống với ràng buộc ngân sách hiện có Nghiên cứu tình khả thi có vẻ tương đối rẻ

và nhanh chóng Kết quả của hoạt động này sẽ đưa ra quyết định có hoặc không triển khai dự án trước khi đi vào phân tìch chi tiết hơn

2 Thu nhập và phân tìch yêu cầu (requirements eliciation and analysis): Đây

là quá trính tím ra các yêu cầu hệ thống thông qua quan sát hệ thống hiện có, thảo luận với người sử dụng tiềm năng, phân tìch nhiệm vụ,… Điều này có thể liên quan đến việc phát triển dựa trên một hoặc nhiều mô hính hệ thống hoặc nguyên mẫu Những điều này giúp hiểu được hệ thống khi đã được quy định cụ thể

3 Đặc tả yêu cầu (requirements specification): Đặc tả yêu cầu là hoạt động chuyển đổi các thông tin đã được thu thập trong hoạt động phân tìch thành một tài liệu định nghĩa tất cả yêu cầu Có thể đưa hai loại yêu cầu vào trong tài liệu Yêu cầu người dùng là các mô tả trừu tượng, yêu cầu hệ thống dành cho khách hàng và người dùng cuối của hệ thống Yêu cầu hệ thống là các mô

tả chi tiết chức năng hệ thống cung cấp

4 Xác nhận yêu cầu (requirements validation): hoạt động này kiểm tra các yêu cầu để đảm bảo tình khả dụng, tình nhất quán, sự đầy đủ của tài liệu Trong quá trính này, sai sót trong tài liệu yêu cầu cần được phát hiện Sau đó phải được sửa đổi để sửa chữa những vấn đề này

Tất nhiên, các hoạt động trong kỹ thuật yêu cầu không chỉ thực hiện một cách đơn giản theo trính tự nghiêm ngặt Việc phân tìch yêu cầu được tiếp tục trong suốt quá trính định nghĩa và đặc tả, phát hiện nhiều yêu cầu mới Ví vậy, các hoạt động trong phân tìch, định nghĩa và đặc tả kỹ thuật thực hiện xen kẽ nhau Trong các phương pháp Agile, chẳng hạn như lập trính cực hạn XP, yêu cầu được phát hiện từng bước theo các ưu tiên người dùng và

việc khám phá các yêu cầu từ phìa người dùng (coi người dùng là một phần của nhóm phát triển)

2.2.2 Thiết kế và triển khai phần mềm

Giai đoạn triển khai trong phát triển phần mềm là quá trính chuyển đổi đặc tả kỹ thuật hệ thống thành một hệ thống có thể thực thi được Giai đoạn này thường liên quan đến quá trính thiết kế và lập trính phần mềm, nhưng nếu

sử dụng phương pháp gia tăng, giai đoạn này cũng có thể liên quan đến quá trính làm mịn đặc tả phần mềm

Một thiết kế phần mềm là một mô tả cấu trúc phần mềm được thực hiện, các

mô hính và cấu trúc dữ liệu được hệ thống sử dụng, các giao diện giữa các thành phần hệ thống, và đôi khi cũng là các thuật toán được sử dụng Người thiết kế không thể hoàn thành thiết kế ngay lập túc mà phải xây dựng thiết kế lặp đi lặp lại Họ đưa thêm các quy cách và chi tiết khi phát triển và xem xét lại liên tục để sửa chữa các thiết kế trước đó

Hình 2.4 là một mô hính trừu tượng quá trính này cho thấy các yêu tố đầu vào của quá trính thiết kế, các hoạt động, và các tài liệu đươc đưa ra như kết quả đầu ra từ quá trính này

Hình 2.4: Mô hình chung của quá trình thiết kế

Sơ đồ này cho thấy rằng các giai đoạn của quá trính thiết kế được thực hiện tuần tự Trong thực tế, các hoạt động này thực hiện xen kẽ nhau Thông tin phản hồi từ một giai đoạn này đến các giai đoạn khác và hệ quả là việc thiết kế lại là không thể tránh khỏi trong tất cả các quá trính thiết kế

Thiết kế đầu vào

Nền tảng

xây dựng

Đặc tả yêu cầu

Mô hính dữ liệu

Thiết kế kiến

trúc

Thiết kế giao diện

Thiết kế thành phần

Thiết kế cơ sở dữ liệu

Đặc tả thành phần Thiết kế hệ thống

Thiết kế đầu ra

Hầu hết, các phần mềm đều tương tác với các hệ thống phần mềm khác, chúng bao gồm hệ thống vận hành, cơ sở dữ liệu, các hệ thống trung gian và các hệ thông ứng dụng khác Tất cả những thành phần này tạo nên “nền tảng phần mềm” (software platform) – môi trường phần mềm sẽ thực hiện trong

đó Thông tin về nền tảng này là một đầu vào cần thiết cho quá trính thiết kế, người thiết kế phải quyết định làm thế nào để tìch hợp phần mềm với môi trường một cách tốt nhất Các đặc tả yêu cầu là một mô tả chức năng phần mềm phải được cung cấp cùng với yêu cầu về hiệu suất và độ tin cậy của nó Nếu hệ thống phải xử lý dữ liệu hiện có, sau đó mô tả dữ liệu được đưa vào đặc tả nền tảng; nếu không, các mô tả dữ liệu phải là đầu vào của quá trính thiết kế để xác định cơ cấu của hệ thống dữ liệu

Các hoạt động trong quá trính thiết kế rất đa dạng, tùy thuộc vào loại của hệ thống được phát triển Vì dụ, các hệ thống thời gian thực đòi hỏi thiết

kế phải có sự tình toán thời gian nhưng có thể không cần một cơ sở dữ liệu có bất thiết kế dữ liệu liên quan nào Hính 2.4 biểu diễn bốn hoạt động có thể là một phần trong thiết kế hệ thống thông tin:

1 Thiết kế kiến trúc (Architectural design): Xác định cấu trúc tổng thể của hệ

thống, thành phần chủ yếu (đôi khi được gọi là các tiểu hệ thống hoặc các mô đun), mối quan hệ giữa chúng, và chúng được phân tán như thế nào

2 Thiết kế giao diện (interface design): Xác định giao diện giữa các thành

phần hệ thống Đặc tả giao diện này phải rõ ràng Với một giao diện chình xác, có thể sử dụng một thành phần mà không cần quan tâm đến các thành phần khác được thực hiện như thế nào Một khi các đặc tả giao diện đã chấp thuận, có thể thiết kế và phát triển đồng thời các thành phần

3 Thiết kế thành phần (Component design): Xác định các thành phần hệ

thống và thiết kế cho chúng hoạt động với nhau Đây có thể là một mô tả đơn giản của các chức năng dự kiến được triển khai tực hiện, với thiết kế đặc tả cụ thể cho người lập trính Ngoài ra, nó có thể là một danh sách các thay đổi

được thực hiện cho một thành phần tái sử dụng hoặc một mô hính thiết kế chi tiết Mô hính thiết kế có thể được sử dụng để tự động tạo ra một thực thi

4 Thiết kế cơ sở dữ liệu (database design): thiết kế cấu trúc dữ liệu hệ thống

và biểu diễn chúng như trong cơ sở dữ liệu Một lần nữa, công việc ở đây phụ thuộc vào việc tái sử dụng cơ sở dữ liệu hiện tại hoặc tạo ra cơ sở dữ liệu mới

Những hoạt động này dẫn đến một tập hợp các kết quả đầu ra trong thiết kế, cũng được hiển thị trong hính 2.4 Các chi tiết và biểu diễn của chúng thay đổi đáng kể Đối với hệ thống quan trọng, tài liệu thiết kế chi tiết mô tả chình xác và hoàn chỉnh hệ thống được phát triển Nếu sử dụng phương pháp hướng mô hình (model-driven approach), những đầu ra này chủ yếu là sơ đồ Trong trường hợp sử dụng các phương pháp Agile, đầu ra này chủ yếu là sơ

đồ Trong trường hợp sử dụng các phương pháp Agile, đầu ra của quá trính thiết kế có thể không phải là các tài liệu đặc tả riêng biệt mà có thể là mã thực thi của chương trính

Phương pháp có cấu trúc là một cách thức tiếp cận trong việc thiết kế với một mô hính đồ họa giúp cho việc phát triển hệ thống trong suốt quá trính thiết kế Phương pháp này ngoài ra cũng có một quy trính cho việc phát triển các mô hính và các quy tắc áp dụng cho từng loại mô hính Phương pháp có cấu trúc sẽ giúp ta tạo ra các tài liệu chuẩn cho một hệ thống và hữu ìch trong việc cung cấp một nền tảng phát triển cho các lập trính viên ìt kinh nghiệm và không có sự hỗ trợ nhiều từ các chuyên gia trong lĩnh vực hệ thống đang xây dựng

Các phương pháp có cấu trúc (structured methods) trong thiết kế được phát triển trong những năm 70 và 80, với tiền thân là UML và thiết kế hướng đối tượng (Budgen, 2003) Các phương pháp này dựa vào mô hính đồ họa của

hệ thống, và trong nhiều trường hợp, tự động sinh code từ các mô hính này Phát triển hướng mô hính (MDD – Model driven development) hoặc kỹ thuật hướng mô hính (model – driven engineering) (Schmidt, 2006) là tạo ra các

mô hính phần mềm từ các mức độ trừu tượng khác nhau, là một sự nâng cấp của các phương pháp có cấu trúc Trong mô hính MDD, nhấn mạnh nhiều hơn vào các mô hính kiến trúc với sự tách biệt giữa các mô hính trừu tượng độc lập và các mô hính triển khai cụ thể Các mô hính được phát triển đầy đủ chi tiết để có thể tạo ra một hệ thống thực thi từ chúng

Sự phát triển một chương trính để triển khai hệ thống theo cách tự nhiên là bắt đầu của quá trính thiết kế hệ thống Mặc dù, một số lớp (classes) của chương trính, vì dụ trong hệ thống an toàn quan trọng, thường được thiết

kế chi tiết trước khi bắt đầu thực hiện, được sử dụng phổ biến hơn so với việc thực hiện xen kẽ các giai đoạn sau của thiết kế và phát triển chương trính Công cụ phát triển phần mềm có thể được sử dụng để tạo ra một bộ khung cho chườn trính từ một thiết kế Việc này bao gồm mã để xác định và thực thi các giao diện và trong nhiều trường hợp, lập trính viên cần chỉ thêm chi tiết các hoạt động của mỗi thành phần trong chương trính

Lập trính là hoạt động cá nhân và không có một quá trính chung để tuân theo Một số lập trính viên bắt đầu với các thành phần mà họ đã nắm rõ, phát triển chúng và sau đó chuyển sang các thành phần họ nắm bắt được ìt hơn Những người khác lại đi ngược lại phương pháp này, để lại các thành phần quen thuộc đến cuối cùng ví họ đã biết cách phát triển chúng như thế nào Một số lập trính viên thìch xác định dữ liệu trước hết sau đó sử dụng chúng để định hướng cho phát triển chương trính, những người khác lại để lại

dữ liệu không xác định càng lâu càng tốt

Thông thường, các lập trính viên thực hiện một số kiểm tra với code mà

họ đã phát triển Điều này thường tím ra các khiếm khuyết chương trính phải được loại bỏ Việc này được gọi là gỡ lỗi Kiểm tra code và gỡ lỗi là hai quá trính khác nhau Kiểm tra xác nhận sự tồn tại các khuyết điểm Gỡ lỗi liên quan tới xác định vị trí và sửa chữa các khuyết điểm này

Khi gỡ lỗi, bạn phải tạo ra giả thuyết về các hành vi có thể quan sát được của chương trính sau đó kiểm tra những giả thuyết này với hy vọng tím được các lỗi gây ra đầu ra bất thường Kiểm tra giả thuyết này liên quan đến việc lần vết code chương trính bằng cách thủ công Việc này có thể đòi hỏi các trường hợp thử nghiệm mới để xác định vấn đề Công cụ gỡ lỗi tương tác

có khả năng hiển thị các giá trị trung gian của các biến chương trính và lần vết các câu lệnh được thực hiện, có thể được sử dụng để hỗ trợ quá trính gỡ lỗi

2.2.3 Xác nhận phần mềm

Xác nhận phần mềm nói chung là xác minh và xác nhận (V & V – Verification and Validation) nhằm mục đìch chỉ ra rằng hệ thống đã phù hợp với đặc tả yêu cầu cũng như nó đã đáp ứng được mong đợi của khách hàng hề thống Kiểm thử chương trính, cho hệ thống chạy bằng cách sử dụng dữ liệu thử nghiệm mô phỏng, chủ yếu là kỹ thuật xác nhận Xác nhận cũng liên quan đến quá trính kiểm tra, như thanh tra và đánh giá, tại mỗi giai đoạn của quy trính phần mềm, từ định nghĩa yêu cầu người dùng đến phát triển chương trính Do ưu thế của việc kiểm thử, phần lớn chi phì xác nhận phát sinh trong

và sau khi thực hiện

Ngoại trừ, các chương trính nhỏ, không nên kiểm tra hệ thống như một khối đơn vị riêng lẻ, duy nhất Hính 2.5 cho thấy một quá trính kiểm thử ba giai đoạn, trong đó kiểm thử các thành phần hệ thống, sau đó kiểm tra kết hợp

và cuối cùng là kiểm tra hệ thống với dữ liệu của khách hàng Lý tưởng nhất, các sai sót trong thành phần hệ thống được phát triển sớm, và các vấn đề liên quan đến giao diện được tím thấy khi tìch hợp hệ thống Tuy nhiên, khi phát hiện ra các thiếu sót, chương trính phải được gỡ lỗi và điều này có thể yêu cầu các giai đoạn khác trong quá trính thử nghiệm được lặp đi lặp lại Lỗi trong các thành phần chương trính có thể được phát hiện trong thử nghiệm hệ thống Do đó, quá trính này lặp đi lặp lại với các thông tin có được từ giai đoạn sau được đưa trở lại các giai đoạn trước