Phân tích thiết kế phần mềm hướng đối tượng sử dụng mẫu và áp dụng cho bài toán quản lý nước TTNS và VSMT nông thông Thái Nguyên

ĐẠI HỌC THÁI NGUYÊN
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG



Ngô Thị Thùy Vân



PHÂN TÍCH THIẾT KẾ PHẦN MỀM
HƢỚNG ĐỐI TƢỢNG SỬ DỤNG MẪU VÀ ÁP
DỤNG CHO BÀI TOÁN QUẢN LÝ NƢỚC TẠI
TTNS&VSMT NÔNG THÔN THÁI NGUYÊN



CHUYÊN NGÀNH: KHOA HỌC MÁY TÍNH
MÃ SỐ: 60. 48. 01

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




NGƢỜI HƢỚNG DẪN KHOA HỌC
PGS.TS. Nguyễn Văn Vỵ

Thái Nguyên - 2012

2


Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

2
LỜI CAM ĐOAN
Tôi xin cam đoan về toàn bộ nội dung của luận văn, những điều đƣợc
trình bày hoặc là của cá nhân hoặc là đƣợc tổng hợp từ nhiều nguồn tài liệu.
Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và đƣợc trích dẫn hợp
pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo
quy định cho lời cam đoan của mình.


Ngô Thị Thùy Vân


3


Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

3

LỜI CẢM ƠN
Trƣớc tiên, em xin đƣợc trân trọng cảm ơn và bày tỏ lòng biết ơn đối
với thầy giáo PGS.TS Nguyễn Văn Vỵ, giảng viên bộ môn Công Nghệ Phần
Mềm – Khoa Công Nghệ Thông Tin – Trƣờng Đại học Công Nghệ -
ĐHQGHN. Trong toàn bộ quá trình học tập và làm luận văn tốt nghiệp, thầy
đã rất tận tình chỉ bảo, hƣớng dẫn, định hƣớng, giảng giải cho em trong việc
nghiên cứu và thực hiện hoàn thành luận văn.
Em xin đƣợc cảm ơn các Giáo Sƣ, Tiến Sĩ, các thầy cô trong trƣờng đại
học Công Nghệ Thông tin và Truyền thông Thái Nguyên đã tận tình giảng
dạy, giúp đỡ em trong quá trình học tập, thực hành, làm bài tập, đọc và nhận
xét luận văn của em, giúp em hiểu thấu đáo hơn lĩnh vực mà em đang nghiên
cứu và những hạn chế cần khắc phục trong việc học tập, nghiên cứu và thực
hiện bản luận văn này.
Xin cảm ơn bạn bè, đồng nghiệp và nhất là các thành viên trong gia
đình đã tạo mọi điều kiện tốt nhất, động viên, cổ vũ em trong suốt quá trình
học tập và làm luận văn tốt nghiệp.
Thái Nguyên, tháng 09 năm 2012


Ngô Thị Thùy Vân









4

MỤC LỤC

LỜI CAM ĐOAN 1
LỜI CẢM ƠN 2
MỤC LỤC 3
BẢNG CÁC CHỮ VIẾT TẮT 7
DANH SÁCH CÁC BẢNG VÀ HÌNH VẼ 8
MỞ ĐẦU 10
CHƢƠNG 1: QUY TRÌNH PHÁT TRIỂN PHẦN MỀM HƢỚNG ĐỐI TƢỢNG
SỬ DỤNG MẪU THIẾT KẾ 12
1.1 Ngôn ngữ mô hình hoá thống nhất – UML 12
1.2. Quy trình tổng quát phát triển phần mềm hƣớng đối tƣợng 13
1.2.1. Ca sử dụng điều khiển toàn bộ quá trình phát triển 15
1.2.2. Quá trình phát triển lấy kiến trúc làm trung tâm 15
1.2.3. Tiến trình phát triển là quá trình lặp và tăng dần 16
1.3 Tổng quan về mẫu thiết kế 20
1.3.1. Khái niệm mẫu thiết kế (pattern) 20
1.3.2. Phân loại mẫu 21
1.3.3. Một số mẫu thiết kế thông dụng 21
1.3.3.1. Mẫu thiết kế GoF (Gang of Four) 21
a. Các mẫu tạo lập 21
b. Các mẫu cấu trúc 22
c. Các mẫu ứng xử 22
1.3.3.2. Mẫu gán trách nhiệm (GRASP) 22
a. Mẫu Expert 23
b. Mẫu Creator 23
c. Mẫu Low Coupling (ghép nối thấp) 24

d. Mẫu High Cohesion (kết dính cao) 24
e. Mẫu Cotroller (kiểm soát) 25
CHƢƠNG 2: BÀI TOÁN QUẢN LÝ NƢỚC SẠCH VÀ GIẢI PHÁP CNTT 26
2.1. Trung tâm NS&VSMT và hoạt động của nó 26
2.1.1. Sự hình thành của trung tâm NS&VSMT 26
2.1.2. Mô hình tổ chức và hoạt động nghiệp vụ 27
a. Ban lãnh đạo Trung tâm 27
b. Phòng Hành chính 28
c. Phòng Kế hoạch – Kỹ thuật 29
d. Các trạm Dịch vụ 30
2.2. Dịch vụ cung cấp nƣớc sạch và những vấn đề đặt ra 31
2.2.1. Quy trình nghiệp vụ quản lý cung cấp nƣớc sạch 31
5


2.2.2. Những vấn đề đặt ra 33
2.2.3 Yêu cầu của hệ thống mới 34
2.3 Mô tả mô hình nghiệp vụ của hệ thống 37
2.3.1. Các chức năng của hệ thống 37
2.3.2. Các tác nhân nghiệp vụ 38
2.3.3. Các đối tƣợng nghiệp vụ và các thao tác nghiệp vụ 38
a. Các đối tƣợng nghiệp vụ 38
b. Các thao tác nghiệp vụ 39
2.3.4 Mô hình miền lĩnh vực 40
2.3.5 Các tiến trình nghiệp vụ trong hệ thống cấp nƣớc 41
CHƢƠNG 3. PHÂN TÍCH THIẾT KẾ BÀI TOÁN QUẢN LÝ NGUỒN NƢỚC
SẠCH 42
3.1 Phát triển mô hình ca sử dụng 42
3.1.1 Biểu đồ ca sử dụng mức gộp 42
3.1.2 Mô tả chức năng các ca sử dụng 42

3.2. Biểu đồ ca sử dụng chi tiết 44
3.2.1. Biểu đồ ca sử dụng hệ con “Ký hợp đồng cấp nƣớc” 44
3.2.1.1. Tạo mới hợp đồng 44
3.2.1.2 Sửa hợp đồng 45
3.2.2. Theo dõi sử dụng 46
3.2.3. Lập hóa đơn 47
3.2.4. Thu tiền sử dụng nƣớc 48
3.2.5. Tra cứu 49
3.2.6. Báo cáo thống kê 51
3.3. Phân tích hệ thống 52
3.3.1. Tạo mới hợp đồng 52
3.3.2. Nhập chỉ số sử dụng 53
3.3.3. Lập hóa đơn 54
3.3.4. Tra cứu 55
3.4. Lựa chọn mẫu và thiết kế hệ thống 55
3.4.1. Tạo mới hợp đồng 55
3.4.2. Nhập chỉ số sử dụng 59
3.4.3. Tra cứu hợp đồng 61
3.4.4. Lập hóa đơn 62
3.4.5. Thanh toán 64
3.4.6. Biểu đồ lớp thiết kế của hệ thống 65
3.4.7. Thiết kế dữ liệu 67
3.4.8. Mô hình triển khai hệ thống 70
3.5. Giao diện 71
PHỤ LỤC 73
KẾT LUẬN 74
TÀI LIỆU THAM KHẢO 75

6

BẢNG CÁC CHỮ VIẾT TẮT

Viết tắt
Tên đầy đủ
UML
Unified Modeling Language
OOSE
Object-Oriented Software Engineering
OMT
Object Modeling Technique
UC
Use case
RUP
Rational Unified Process
GRASP
General Responsibility Assignment Software
NS&VSMT
Nƣớc sạch và vệ sinh môi trƣờng
NM
Nhà máy
TT
Trung tâm
UBND
Ủy ban nhân dân
CMTND
Chứng minh thƣ nhân dân
CSDL
Cơ sở dữ liệu
PC

Personal Computer
GTGT
Giá trị gia tăng

7



DANH SÁCH CÁC BẢNG VÀ HÌNH VẼ

Số
Tên bảng và hình
Trang
Hình 1.1
Tiến trình chung pháp triển phần mềm
9
Hình 1.2
Vòng đời của hệ thống
10
Hình 1.3
Các pha và bƣớc lặp
10
Hình 1.4
Sơ đồ tổng quát các bƣớc phân tích, thiết kế và sản phẩm theo RUP
16
Hình 2.1
Mô hình tổ chức hành chính của TT NS&VSMT Thái Nguyên
22
Hình 2.2
Biểu đồ miền lĩnh vực

37
Hình 2.3
Các tiến trình nghiệp vụ
38
Hình 3.1
Biểu đồ ca sử dụng mức gộp
39
Hình 3.2
Ca sử dụng Ký hợp đồng cấp nƣớc
41
Hình 3.3
Chi tiết ca sử dụng Theo dõi sử dụng
43
Hình 3.4
Chi tiết ca sử dụng Thu tiền sử dụng
45
Hình 3.5
Chi tiết ca sử dụng Tra cứu
46
Hình 3.6
Chi tiết ca sử dụng Báo cáo thống kê
48
Hình 3.7
Biểu đồ lớp phân tích thực thi ca sử dụng Tạo mới hợp đồng
49
Hình 3.8
Biểu đồ lớp phân tích thực thi ca sử dụng Nhập chỉ số sử dụng
50
Hình 3.9
Biểu đồ lớp phân tích thực thi ca sử dụng Lập hóa đơn

51
Hình 3.10
Biểu đồ lớp phân tích thực thi ca sử dụng Tra cứu hợp đồng
52
Hình 3.11
Biểu đồ lớp ca sử dụng Thêm mới hợp đồng
53
Hình 3.12
Biểu hoạt động ca sử dụng Thêm mới hợp đồng
54
Hình 3.13
Sơ đồ tuần tự ca sử dụng Thêm mới hợp đồng
55
Hình 3.14
Biểu đồ lớp thiết kế ca sử dụng Nhập chỉ số sử dụng
56
Hình 3.15
Sơ đồ hoạt động năng Nhập chỉ số sử dụng
57
Hình 3.16
Sơ đồ tuần tự chức năng Nhập chỉ số sử dụng
57
Hình 3.17
Biểu đồ lớp thiết kế ca sử dụng Tra cứu hợp đồng
58
Hình 3.18
Sơ đồ tuần tự ca sử dụng Tra cứu hợp đồng
59
Hình 3.19
Biểu đồ hành động Lập hóa đơn

59
Hình 3.20
Biểu đồ cộng tác ca sử dụng Lập hóa đơn
60
Hình 3.21
Biểu đồ cộng tác ca sử dụng Lập hóa đơn
60
Hình 3.22
Biểu đồ lớp thiết kế ca sử dụng Thanh toán
61
Hình 3.23
Biểu đồ tuần tự ca sử dụng Thanh toán
61
Hình 3.24
Biểu đồ lớp thiết kế hệ thống quản lý nƣớc
62
8


Hình 3.25
Biểu đồ quan hệ dữ liệu của hệ thống
63
Hình 3.26
Mô hình triển khai hệ thống
67
Hình 3.27
Giao diện đăng nhập
68
Hình 3.28
Thêm mới hợp đồng sử dụng nƣớc

68
Hình 3.29
Form nhập chỉ số
69
Hình 3.30
Form Tra cứu hợp đồng
69
Bảng 2.1
Các chức năng của hệ thống
34
Bảng 2.2
Các tác nhân nghiệp vụ của hệ thống
35
Bảng 3.1
Các lớp thiết kế tham gia thực thi ca sử dụng Thêm mới HĐ
53
Bảng 3.2
Các lớp thiết kế tham gia thực thi ca sử dụng Nhập chỉ số
56
Bảng 3.3
Các lớp thiết kế tham gia thực thi ca sử dụng Tra cứu HĐ
58
Bảng 3.4
Các lớp thiết kế tham gia thực thi ca sử dụng Lập hóa đơn
59
Bảng 3.5
Các lớp thiết kế tham gia thực thi ca sử dụng Thanh toán
61

9

MỞ ĐẦU

Phần mềm ngày càng lớn, việc tiếp cận và phát triển phần mềm hƣớng cấu
trúc gặp rất nhiều khó khăn khi tạo ra cấu trúc phần mềm với quá nhiều mô đun,
khó kiểm soát, đặc biệt khi bảo trì. Cách tiếp cận hƣớng đối tƣợng cho phép xây
dựng phần mềm với các đối tƣợng độc lập tƣơng đối với nhau. Việc phát triển
hệ thống lớn dẫn đến phát triển các thành phần (các lớp đối tƣợng) độc lập với
nhau để lắp ghép lại thành hệ thống lớn không bị giới hạn. Cách tiếp cận này
không chỉ có lợi khi phát triển, mà còn đặc biệt hiệu quả khi bảo trì và sử dụng
lại những thành phần độc lập này.
Khi gặp một vấn đề, ngƣời thiết kế đã lựa chọn một phƣơng pháp tối ƣu,
sao cho tốt nhất, phù hợp nhất, sử dụng dễ, giảm thiểu đƣợc độ phức tạp cũng
nhƣ tiết kiệm công sức và thời gian cho sự phát triển lần đầu cũng nhƣ những
lần sau, đặc biệt khi tái sử dụng lại chúng. Khi phát triển hệ thống hƣớng đối
tƣợng, các chuyên gia đã đúc rút đƣợc kinh nghiệm và đƣa ra nhiều khuôn dạng
chung về các mẫu thiết kế phần mềm. Việc áp dụng các mẫu này đáp ứng đƣợc
phần nào yêu cầu khắt khe của công nghệ phần mềm hiện đại và đem lại hiệu
quả lớn cả về thời gian và chi phí. Các mẫu thiết kế đƣợc các nhà thiết kế sau
này coi nhƣ những từ vựng chung để tạo ra các thiết kế tốt khi sử dụng lại
chúng.
Tại Việt nam, vấn đề phát triển hệ thống phần mềm hƣớng đối tƣợng triển
khai chƣa lâu, việc sử dụng lại mẫu thiết kế trong thiết kế còn rất hiếm. Hiểu và
áp dụng các mẫu thiết kế vào quy trình phát triển phần mềm hƣớng đối tƣợng
đòi hỏi có thời gian và cần nhiều thử nghiệm. Vì lý do đó mà đề tài “Phân tích,
thiết kế phần mềm hướng đối tượng sử dụng mẫu và áp dụng cho bài toán quản
lý nước tại trung tâm nước sạch và vệ sinh môi trường nông thôn Thái Nguyên”
đƣợc chọn làm đề tài luận văn tốt nghiệp cao học của em. Trƣớc hết, nó góp
phần giải quyết vấn đề thiết kế các hệ thống phần mềm của thực tiễn đặt ra một

cách khoa học, hiệu quả. Sau nữa, đây là một cách để nâng cao trình độ trong
10


công nghệ thiết kế và tích lũy kinh nghiệm sử dụng mẫu nhằm phát huy hiệu quả
của chúng.
Luận văn gồm 3 chƣơng:
Chƣơng 1: Quy trình phát triển phần mềm hƣớng đối tƣợng sử dụng mẫu
thiết kế
Chƣơng 2: Bài toán quản lý nƣớc sạch và giải pháp công nghệ thông tin
Chƣơng 3: Phân tích và thiết kế bài toán quản lý nguồn nƣớc sạch
Cuối cùng là kết luận và tài liệu tham khảo.
11


CHƯƠNG 1: QUY TRÌNH PHÁT TRIỂN PHẦN MỀM HƯỚNG
ĐỐI TƯỢNG SỬ DỤNG MẪU THIẾT KẾ
1.1 Ngôn ngữ mô hình hoá thống nhất – UML
Một mô hình (model) là một sự mô tả đơn giản hoá đối tượng của thế giới
thực. Có thể xem mô hình là “hình ảnh” của đối tƣợng đƣợc nhìn nhận theo
những góc nhìn nào đó. Mô hình hóa là quá trình mô tả đối tƣợng bằng những
mô hình khác nhau. Phương pháp mô hình hóa là phƣơng pháp nghiên cứu đối
tƣợng thông qua việc nghiên cứu các mô hình của chúng.
Mô hình hoá là một phần trung tâm của tất cả các hoạt động dẫn đến việc
triển khai một phần mềm tốt. Chúng ta xây dựng mô hình để truyền đạt một cấu
trúc và hành vi mong muốn của hệ thống; xây dựng mô hình để làm trực quan
hoá và kiểm soát đƣợc kiến trúc của hệ thống. Nhờ xây dựng mô hình mà ta hiểu
rõ hơn hệ thống cần phát triển, và làm lộ ra những cơ hội để đơn giản hoá và để
sử dụng lại chúng. Mặt khác, xây dựng các mô hình để chế ngự các rủi ro khi
phát triển hệ thống.

UML là một ngôn ngữ mô hình hoá chuẩn để giúp tạo ra các sản phẩm đặc
tả khác nhau trong quá trình phát triển một hệ thống phần mềm hƣớng đối
tƣợng, trong đó đặc biệt là các bản thiết kế phần mềm. Nó đƣợc hợp nhất từ
nhiều thành tựu và kinh nghiệm trong việc nghiên cứu và triển khai thuộc lĩnh
vực công nghệ thông tin của các nhà khoa học, những chuyên gia nghiên cứu và
triển khai, trong đó nổi bật nhất là Grady Booch và Ivar Jacobson (với Object-
Oriented Software Engineering - OOSE), James Rumbaugh (với Object
Modeling Technique - OMT).
UML thích hợp cho việc mô hình hoá các hệ thống, từ các hệ thống thông
tin xí nghiệp đến các ứng dụng phân tán dựa trên Web và cả các hệ thống
nhúng thời gian thực. Nó là ngôn ngữ biểu diễn đặc tả đề cập đƣợc mọi khung
nhìn cần thiết cho việc phát triển và sau đó là triển khai các hệ thống nói trên.
12


UML chỉ là một ngôn ngữ và vì vậy nó cần phải là một phần của phƣơng
pháp phát triển phần mềm. UML là một ngôn ngữ độc lập với quá trình phát
triển, mặc dù vậy, tốt hơn cả là nó cần đƣợc sử dụng trong một tiến trình phát
triển.
1.2. Quy trình tổng quát phát triển phần mềm hướng đối tượng
Một quá trình phát triển phần mềm là một tập của các hoạt động cần thiết
để chuyển các yêu cầu ngƣời dùng thành một hệ thống phần mềm đáp ứng đƣợc
các yêu cầu đặt ra (hình 1.1.)



Hình 1.1: Tiến trình chung phát triển phần mềm
Vòng đời phát triển một phần mềm thƣờng gồm các giai đoạn sau: Xác
định yêu cầu hệ thống, phân tích, thiết kế, triển khai, vận hành và bảo trì hệ
thống. Tiến trình phát triển phần mềm hƣớng đối tƣợng dựa trên công nghệ đối

tƣợng, cụ thể là dựa trên các thành phần, tức là hệ thống phần mềm sẽ đƣợc xây
dựng dựa trên các thành phần phần mềm kết nối với nhau qua các giao diện đã
đƣợc xác định. Do vậy, nội dung thực hiện các giai đoạn trong tiến trình và
nội dung mỗi bƣớc có một sự khác biệt nhất định so các quá trình phát triển
hƣớng cấu trúc đã biết.
Vòng đời phát triển phần mềm đƣợc chia thành bốn pha: sơ bộ, soạn thảo,
xây dựng và chuyển đổi (hình 1.2). Trong mỗi pha lại chia thành nhiều bƣớc lặp
nhỏ.
Mỗi bƣớc lặp đều gồm một số công việc thực hiện chọn vẹn một sản phẩm
phần mềm: lập mô hình nghiệp vụ, xác định yêu cầu, phân tích, thiết kế, triển
khai và kiểm thử. Tuy nhiên, bƣớc lặp trong mỗi pha khác với bƣớc lặp ở các
Yêu cầu
ngƣời
dùng
Tiến trình phát triển
phần mềm
Hệ thống
phần
mềm
13


pha khác về nội dung cũng nhƣ khối lƣợng mỗi loại công việc thực hiện. (Hình
1.3)


Khởi thảo
Chi tiết
Xây dựng
Chuyển giao

Bƣớc 1
Bƣớc 2
=
=
=
=
=
Bƣớc n-
1
Bƣớc n




Hình 1.2: Vòng đời hệ thống

Hình 1.3: Các pha và các bƣớc lặp
Với mỗi bƣớc lặp, các hoạt động phát triển đƣợc thực hiện trên một phạm
vi chỉ liên quan đến một số thành phần nhất định của hệ thống, và kết thúc mỗi
bƣớc lặp ta nhận đƣợc một xuất phẩm mới của hệ thống mà sẵn sàng để phân
Bắt đầu
Kết thúc
Thời gian
Suất phẩm thực hiện
14


phối và thực hiện đƣợc. Nó bao gồm các mã nguồn đƣợc viết dƣới dạng các
thành phần mà có thể đƣợc biên dịch và thực thi, cùng với các hƣớng dẫn sử
dụng và nhiều phụ phẩm khác. Tuy nhiên, các xuất phẩm này còn chƣa phải là

sản phẩm cuối cùng; vì sản phẩm cuối cùng phải là sản phẩm hoàn thiện thỏa
mãn đƣợc yêu cầu của tất cả mọi ngƣời sẽ làm việc với nó.
Quá trình phát triển phần mềm hƣớng đối tƣợng có thể sử dụng các công
cụ khác nhau. Quá trình này có ba đặc trƣng sau :
– Ca sử dụng điều khiển quá trình phát triển
– Lấy kiến trúc làm trung tâm
– Tiến trình phát triển là quá trình lặp và tăng dần
1.2.1. Ca sử dụng điều khiển toàn bộ quá trình phát triển
Một hệ thống phần mềm đƣợc tạo ra là để phục vụ ngƣời dùng. Thuật ngữ
ngƣời dùng ở đây bao gồm cả ngƣời dùng hệ thống hay các hệ thống ngoài khác
tƣơng tác với hệ thống mà chúng ta xây dựng.
Một ca sử dụng (use case) là một phần chức năng của hệ thống cung cấp
cho ngƣời dùng để đem lại một kết quả nào đó khi sử dụng nó. Các ca sử dụng
dùng để nắm bắt các yêu cầu chức năng. Tập hợp tất cả các ca sử dụng lập thành
mô hình ca sử dụng mô tả chức năng đầy đủ của hệ thống. Mô hình này sẽ thay
thế cho đặc tả chức năng hệ thống bằng phƣơng pháp truyền thống. Một đặc tả
chức năng thƣờng trả lời câu hỏi: hệ thống đƣợc dự kiến sẽ làm gì? Nhƣng đối
với ca sử dụng thì câu hỏi lại là: hệ thống dự kiến sẽ làm đƣợc gì cho mỗi ngƣời
sử dụng nó? Vì vậy, tất cả các bƣớc của quá trình phát triển đều lấy các ca sử
dụng làm cái định hƣớng, chỉ dẫn và kiểm tra.
1.2.2. Quá trình phát triển lấy kiến trúc làm trung tâm
Vai trò của kiến trúc hệ thống phần mềm giống một khung nền dựa trên đó
phần mềm đƣợc xây dựng và phát triển đến hoàn thiện. Khái niệm kiến trúc
phần mềm chứa đựng những khía cạnh tĩnh và động, có ý nghĩa quyết định đối
15


với chất lƣợng một hệ thống. Nó đƣợc phát triển dựa theo yêu cầu của tổ chức,
theo cảm nhận của ngƣời dùng và các tổ chức có liên quan khác. Mặt khác, nó
cũng chịu ảnh hƣởng của rất nhiều nhân tố khác, chẳng hạn nhƣ phần nền của hệ

thống, các khối xây dựng dùng lại đƣợc có sẵn, các cân nhắc về điều kiện triển
khai, các hệ thống có sẵn trong môi trƣờng tƣơng tác với nó, và cả các yêu cầu
phi chức năng (ví dụ nhƣ tính thể hiện, độ tin cậy). Kiến trúc là một cái nhìn
tổng thể về những đặc điểm quan trọng nhất của hệ thống phần mềm khi tạm bỏ
qua các chi tiết.
Mọi sản phẩm phần mềm đều bao gồm chức năng và hình thức thể hiện.
Hai yếu tố này phải cân bằng với nhau để đem lại kết quả tốt nhất. Chức năng
tƣơng ứng với các ca sử dụng và hình thức thể hiện tƣơng ứng với kiến trúc
của nó. Do đó việc lựa chọn các ca sử dụng để phát triển đƣợc định hƣớng theo
kiến trúc và phải phù hợp với kiến trúc. Nói cách khác, kiến trúc phải cung cấp
chỗ dựa và cũng là các ràng buộc chung cho việc thực hiện các ca sử dụng ngay
từ khi bắt đầu tiến trình phát triển hệ thống và cho đến cả trong tƣơng lai. Để có
đƣợc một mẫu cho kiến trúc, nhà kiến trúc phải có hiểu biết chung về các chức
năng chính, đó là các ca sử dụng chính yếu. Thƣờng thì các ca sử dụng này chỉ
chiếm từ 5-10% tổng số các ca sử dụng. Chúng là các ca sử dụng mang ý nghĩa
nhất, tạo nên các chức năng cốt yếu của hệ thống và thƣờng ít thay đổi trong quá
trình phát triển.
1.2.3. Tiến trình phát triển là quá trình lặp và tăng dần
Việc phát triển một phần mềm nói chung đòi hỏi một số lớn công việc và
có thể diễn ra trong một khoảng thời gian.Việc chia nhỏ toàn bộ công việc thành
các phần nhỏ hoặc các dự án con là yêu cầu thiết thực. Mỗi dự án con là một
bƣớc lặp và tạo nên một sự tăng trƣởng. Điều này dễ dàng thực hiện đƣợc khi
phát triển phần mềm hƣớng đối tƣợng vì nó đƣợc cấu thành từ các thành phần
độc lập ghép nối lại với nhau. Để đạt hiệu quả nhất, các bƣớc lặp phải đƣợc điều
16


khiển, tức là chúng phải đƣợc lựa chọn và tiến hành theo một cách có kế hoạch
từ trƣớc.
Lựa chọn cái gì cần triển khai trong một bƣớc lặp dựa trên hai yếu tố sau.

Thứ nhất, bƣớc lặp phải liên quan tới một nhóm các ca sử dụng cho phép mở
rộng tính khả dụng của hệ thống trong khi phát triển. Thứ hai, bƣớc lặp phải giải
quyết những rủi ro quan trọng nhất, tức là hạn chế rủi ro đến mức tối đa có thể.
Mỗi bƣớc lặp tiếp đƣợc xây dựng trên cơ sở các xuất phẩm (sản phẩm thiết
kế) từ trạng thái mà nó vừa kết thúc ở bƣớc lặp trƣớc. Bởi vì là một dự án con,
nên từ các ca sử dụng đã dùng, nó tiếp tục mở rộng việc thực hiện các công việc
phân tích, thiết kế, cài đặt, và kiểm thử đối với các chức năng còn lại đƣợc nắm
bắt trong các ca sử dụng tiếp theo để đƣa chúng về dạng các mã nguồn thực thi
đƣợc.
Tuy nhiên, trong một vài bƣớc ban đầu, ngƣời phát triển có thể chỉ thay thế
một thiết kế còn sơ bộ bằng một thiết kế khác chi tiết hơn, phức tạp hơn, vì vậy
có thể chƣa tạo ra sự tăng trƣởng của xuất phẩm. Nhƣng ở các bƣớc sau, một sự
tăng trƣởng của xuất phẩm nói chung là tất nhiên và cần thiết.
Trong mỗi bƣớc lặp, ngƣời thiết kế xác định các ca sử dụng liên quan, tạo
lập một thiết kế dựa trên kiến trúc đã chọn, triển khai thiết kế dƣới dạng các
thành phần, và kiểm tra mức độ tƣơng ứng giữa các thành phần và các ca sử
dụng. Nếu một bƣớc lặp thỏa mãn đƣợc các mục đích của nó thì có thể chuyển
sang bƣớc lặp tiếp theo. Nếu không, ngƣời thiết kế sẽ phải xem lại và thử một
cách tiếp cận mới.
Một dự án gọi là thành công nếu đƣợc tiến hành mà không trệch hƣớng
nhiều so với kế hoạch đã đƣợc định ra. Tối thiểu hóa đƣợc các vấn đề còn chƣa
đƣợc nhận thức chính là một trong các mục tiêu của việc giảm rủi ro. Một quá
trình lặp có điều khiển sẽ mang lại rất nhiều lợi ích, đặc biệt giải quyết đƣợc
những vấn đề liên quan đến các rủi ro.
17


Những khái niệm – ca sử dụng điều khiển tiến trình, tập trung vào kiến
trúc, lặp và tăng dần - có mức độ quan trọng nhƣ nhau. Kiến trúc cung cấp cấu
trúc mà theo đó chỉ dẫn công việc trong các bƣớc lặp. Trong khi đó ca sử dụng

xác định mục tiêu và định hƣớng công việc cho mỗi vòng lặp. Thiếu một trong
ba khái niệm này sẽ làm giảm nghiêm trọng giá trị của quá trình phát triển.
Chính quá trình lặp làm dễ dàng cho hoạt động quản lý và giảm sự phức tạp của
quá trình phát triển, nhờ vậy mà giảm bớt những rủi ro.
18



Hình 1.4: Sơ đồ tổng quát các bƣớc phân tích, thiết kế và sản phẩm theo RUP
19


1.3 Tổng quan về mẫu thiết kế
1.3.1. Khái niệm mẫu thiết kế (pattern)
Theo định nghĩa của Christopher Alexander: “Một mẫu mô tả một vấn đề
xảy ra lặp đi lặp lại và mô tả phần cốt lõi của giải pháp cho vấn đề đó, chúng ta
có thể sử dụng lại giải pháp đã có hàng triệu lần”.
Nói chung, một mẫu mô tả một vấn đề thƣờng xảy ra trong phát triển phần
mềm và mô tả giải pháp cho vấn đề đó theo cách có thể dùng lại đƣợc. Các mẫu
là phƣơng tiện truyền bá tri thức và kinh nghiệm, truyền từ những ngƣời giàu
kinh nghiệm đến những ngƣời thiếu kinh nghiệm.
Hầu hết các mẫu đƣợc xây dựng để hỗ trợ chỉ cho tiếp cận hƣớng đối tƣợng
Thông thƣờng một mẫu đƣợc thể hiện với 4 yếu tố chính:
− Tên mẫu: cụm từ ngắn, cho phép tham chiếu đến mẫu
− Vấn đề: mô tả khi nào áp dụng mẫu, giải thích vấn đề và khung cảnh.
− Giải pháp cho vấn đề: mô tả các yếu tố tạo nên thiết kế, các mối quan hệ
giữa chúng, các trách nhiệm và sự cộng tác giữa chúng. Giải pháp không
mô tả thiết kế hoặc triển khai cụ thể, vì một mẫu có thể đƣợc áp dụng trong
nhiều tình huống khác nhau. Mẫu chỉ cung cấp bản mô tả trừu tƣợng về
một vấn đề thiết kế và việc sắp xếp các yếu tố ở mức chung nhất để giải

quyết nó.
− Kết quả: là các kết quả của việc áp dụng mẫu. Vì chúng ta luôn phải trả giá
cho việc áp dụng mẫu nên trƣớc đó chúng ta cần xác định chi phí bỏ ra
cũng nhƣ kết quả thu về để có thể quyết định lựa chọn mẫu phù hợp và áp
dụng nó.
Ví dụ:
Tên mẫu:
Creator
Vấn đề:
Ai có trách nhiệm tạo ra một thể hiện mới của một lớp?
Giải pháp
Lớp B có trách nhiệm tạo ra một thể hiện mới của lớp A nếu một
trong các điều kiện dƣới đây thỏa mãn:
B là một tập hợp các đối tƣợng A (B và A có mối quan hệ
20


aggregate)
B chứa các đối tƣợng A (B và A có mối quan hệ contain)
B lƣu lại các thể hiện của các đối tƣợng A
B sử dụng các đối tƣợng A
B có dữ liệu khởi tạo mà đƣợc truyền tới A khi nó đƣợc tạo.
Bảng 1.1: Ví dụ về mẫu thiết kế
1.3.2. Phân loại mẫu
Các mẫu đƣợc phân loại theo nhiều cách khác nhau, một trong số đó là
cách phân loại theo các giai đoạn phát triển phần mềm:
 Mẫu phân tích
 Mẫu thiết kế
 Mẫu triển khai
Trong nghiên cứu này chỉ tập trung vào các mẫu thiết kế.

1.3.3. Một số mẫu thiết kế thông dụng
1.3.3.1. Mẫu thiết kế GoF (Gang of Four)
Các mẫu GoF đƣợc xem là các mẫu nền tảng cho các nhà khoa học làm cơ
sở để đề xuất ra những mẫu thiết kế hữu ích cho ngành công nghiệp phát triển
phần mềm gồm 3 nhóm: Các mẫu tạo lập (Creational patterns), các mẫu cấu
trúc (Structural patterns) và các mẫu ứng xử (Behavioural patterns).
a. Các mẫu tạo lập
Các mẫu thiết kế thuộc nhóm này nhằm tổng quát hóa quá trình thực thi
của một tiến trình công việc nào đó. Chúng giúp một hệ thống độc lập với việc
tạo, thực hiện và biểu diễn các đối tƣợng của nó. Các mẫu tạo lập dạng lớp
(class creational patterns) sử dụng tính kế thừa để yêu cầu lớp khác thực hiện
công việc theo từng tiêu chuNn hay tình huống cụ thể. Trong khi các mẫu tạo
lập dạng đối tƣợng (object creational patterns) sẽ ủy nhiệm công việc đến các
đối tƣợng khác. Nhóm này bao gồm các mẫu: Factory Method, Abstract Factory,
Builder, Prototype, Singleton.
21


b. Các mẫu cấu trúc
Các mẫu thiết kế thuộc nhóm này quan tâm đến việc các lớp và đối
tƣợng đƣợc tổ chức nhƣ thế nào trong một cấu trúc lớn bao gồm nhiều lớp đối
tƣợng. Các mẫu cấu trúc dạng lớp (class structural patterns) sử dụng tính kế thừa
để kết hợp các giao tiếp (interfaces) hoặc các lớp hiện thực (implementations).
Trong khi các mẫu cấu trúc dạng đối tƣợng mô tả cách thức để kết hợp các đối
tƣợng để hiện thực những chức năng mới. N hóm này bao gồm các mẫu:
Adapter, Bridge, Composite, Decorator, Facade và Proxy.
c. Các mẫu ứng xử
Các mẫu thiết kế thuộc nhóm này quan tâm đến các giải thuật và những
yêu cầu trách nhiệm giữa các đối tƣợng với nhau. Chúng thể hiện sự giao tiếp
giữa các đối tƣợng trong hệ thống và quá trình này đƣợc điều khiển nhƣ thế nào

trong một chƣơng trình phức tạp. Các mẫu ứng xử dạng lớp sử dụng tính kế thừa
để lựa chọn và xử lý các cách ứng xử giữa các lớp. Trong khi các mẫu ứng xử
dạng đối tƣợng sử dụng cách kết hợp các đối tƣợng để xử lý. Nhóm này bao
gồm các mẫu: Interpreter, Template Method, Chain of Responsibility,
Command, Iteratror, Mediator, Memento, Flyweight, Observer, State, Strategy,
Visitor.
1.3.3.2. Mẫu gán trách nhiệm (GRASP)
Trong số các mẫu, mẫu phần mềm gán trách nhiệm chung GRASP có năm
mẫu thƣờng đƣợc sử dụng nhiều nhất đó là:
– Expert (chuyên gia)
– Creator (bộ tạo lập)
– Low Coupling (ghép nối thấp)
– High Cohension (kết dính cao)
– Controller (bộ điều khiển).
22


a. Mẫu Expert

Tên mẫu:
Expert
Vấn đề:
Nguyên tắc cơ bản nhất để gán các trách nhiệm cho các đối
tƣợng trong thiết kế hƣớng đối tƣợng là gì?
Giải pháp:
Hãy gán trách nhiệm cho một lớp có đủ thông tin cần thiết để
thực hiện trách nhiệm đó.

Mẫu Expert đƣợc sử dụng nhiều hơn bất cứ mẫu nào khác trong việc gán
trách nhiệm; nó là một nguyên tắc thƣờng dùng trong thiết kế hƣớng đối tƣợng.

Mẫu Expert dẫn dắt các thiết kế, ở đó một đối tƣợng phần mềm thực hiện các
thao tác mà nó thƣờng làm trong thực tế. Mẫu này thể hiện đƣợc những cảm giác
trực quan chung về các đối tƣợng, chúng phải thực hiện những gì để có đƣợc
những thông tin cần có. Sử dụng loại mẫu này cũng đảm bảo duy trì đƣợc tính
chất bao gói, che giấu thông tin vì các đối tƣợng chỉ sử dụng những thông tin
riêng mà chúng có để thực hiện những nhiệm vụ đƣợc giao.

b. Mẫu Creator
Tạo lập các đối tƣợng khi cần thiết là một trong những hoạt động quan
trọng của hệ thống hƣớng đối tƣợng. Do đó cần phải có nguyên lý chung để gán
trách nhiệm tạo lập đối tƣợng trong hệ thống.

Tên mẫu:
Creator
Vấn đề:
Đối tƣợng nào có trách nhiệm tạo ra một thể hiện của một lớp đã
cho
Giải
pháp:
Gán cho lớp B trách nhiệm tạo một thể hiện của lớp A (B là một
bộ tạo các đối tƣợng của A) nếu một trong những điều kiện sau
đây thoả mãn:
– B kết hợp lại (aggregate) các đối tƣợng của A
– B chứa (contain) các đối tƣợng của A
– B ghi lại (record) các thể hiện của các đối tƣợng của A
23


– B sử dụng chặt chẽ (closely use) các đối tƣợng của A
– B có dữ liệu khởi tạo mà nó sẽ đƣợc chuyển tới A khi nó

đƣợc tạo ra.
Do đó B là một Expert đối với việc khởi tạo A.

c. Mẫu Low Coupling (ghép nối thấp)

Tên mẫu:
Low Coupling
Vấn đề:
Làm thế nào để giảm sự phụ thuộc và tăng khả năng tái sử dụng ?
Giải pháp:
Gán trách niệm sao cho độ ghép nối giữ ở mức thấp.

Khái niệm kết nối đã đề cập trong giáo trình về kỹ nghệ phần mềm
[Vy&08], nó đánh giá mức độ phụ thuộc của một lớp này vào một lớp khác.
Tiêu chí một thiết kế tốt đòi hỏi phải có độ ghép nối thấp đối với các lớp khác,
tức là ít phụ thuộc vào các lớp khác (ít mối liên kết phụ thuộc, liên kết yếu). Khi
gán một trách nhiệm cho một lớp cũng vậy, cần gán sao cho độ ghép nối giữa
các lớp giữ ở mức độ thấp.
Vấn đề ghép nối có thể là không quan trọng nếu việc sử dụng lại không
phải là mục đích của hệ thống. Và không có một độ đo tuyệt đối để biết khi nào
mức độ ghép nối là quá cao. Thêm vào đó, rất hiếm có một hệ thống mà trong
đó có rất ít hay không có liên kết giữa các lớp.
d. Mẫu High Cohesion (kết dính cao)

Tên mẫu:
High Cohesion
Vấn đề:
Làm thế nào để giữ cho sự phức tạp ở mức có thể quản lý đƣợc?
Giải pháp:
Gán một trách nhiệm sao cho duy trì độ kết dính cao.

Kết dính là một độ đo mức độ liên quan mạnh hay yếu của một lớp với các
lớp khác và nó làm nổi bật trách nhiệm của lớp. Một lớp có kết dính cao thƣờng
liên quan chặt chẽ với các trách nhiệm về mặt chức năng. Các lớp nhƣ vậy
thƣờng có một số ít các phƣơng thức đơn giản.
24


Một tính chất quan trọng của một thiết kế hƣớng đối tƣợng là gán trách
nhiệm cho các lớp liên quan chặt chẽ với các công việc, và các lớp này đôi khi
không phải làm gì nhiều. Chúng có trách nhiệm là giao các phần thực thi công
việc cho các lớp khác. Đặc tính này đƣợc lƣu giữ bởi mẫu kết dính cao.
e. Mẫu Cotroller (kiểm soát)

Tên mẫu:
Controller
Vấn đề:
Đối tƣợng nào nên nhận trách nhiệm điều khiển một sự kiện vào
hệ thống?
Giải pháp:
Gán trách nhiệm điều khiển một sự kiện vào hệ thống cho một lớp
có một trong các lựa chọn sau:
– Biểu diễn hệ thống nói chung (bộ điều khiển bề ngoài)
– Biểu diễn giao dịch chung hoặc tổ chức chung (bộ điều khiển
bề ngoài)
– Biểu diễn cái gì đó hoạt động trong thế giới thực (ví dụ, vai trò
của một ngƣời) có thể có liên quan trong công việc (bộ điều
khiển vai trò)
– Biểu diễn một bộ điều khiển nhân tạo tất cả các sự kiện đầu
vào hệ thống của một ca sử dụng, thƣờng đƣợc đặt tên

"<UseCaseName>Handler" (bộ điều khiển use-case)

Mẫu Controller cho phép xác định các thao tác của hệ thống. Mẫu này sử
dụng cùng một lớp điều khiển cho tất cả các sự kiện vào hệ thống trong cùng ca
sử dụng. Điều này cũng có nghĩa là, một Controller là một đối tƣợng giao diện
không có ngƣời dùng, nó có trách nhiệm điều khiển sự kiện vào hệ thống, và
định nghĩa phƣơng thức cho thao tác tƣơng ứng của hệ thống. Một đối tƣợng
giao diện có thể chấp nhận một sự kiện vào hệ thống, nhƣng nó không thực hiện
bất cứ một trách nhiệm (hay bất cứ phần công việc) nào của thao tác hệ thống
mà chỉ đơn giản là chuyển nó tới bộ điều khiển (controller).
25


CHƯƠNG 2: BÀI TOÁN QUẢN LÝ NƯỚC SẠCH VÀ GIẢI
PHÁP CÔNG NGHỆ THÔNG TIN
2.1. Trung tâm NS&VSMT và hoạt động của nó
2.1.1. Sự hình thành của trung tâm NS&VSMT
Trung tâm Nƣớc sạch và Vệ sinh môi trƣờng (TTNS&VSMT) nông
thôn Thái Nguyên đƣợc thành lập theo Quyết định số 343/QĐ-UB ngày
10/9/1991 của UBND tỉnh Bắc Thái nay là tỉnh Thái Nguyên.
Trung tâm là đơn vị sự nghiệp trực thuộc Sở Nông nghiệp và Phát
triển nông thôn, có tƣ cách pháp nhân, có con dấu và tài khoản riêng, hoạt
động theo phƣơng thức tự trang trải một phần chi phí hoạt động;
Trung tâm có nhiệm vụ:
− Quản lý, vận hành các công trình cấp nƣớc tập trung ở nông thôn đƣợc
cấp có thẩm quyền giao và tổ chức việc cung cấp nƣớc sạch theo giá
bán đƣợc Ủy ban nhân dân tỉnh phê duyệt.
− Tổ chức triển khai thực hiện Chƣơng trình Mục tiêu Quốc gia
NS&VSMT Nông thông trên địa bàn Tỉnh.
− Là Văn phòng thƣờng trực Ban chỉ đạo Chƣơng trình Mục tiêu Quốc

gia NS&VSMT nông thôn tỉnh Thái Nguyên.
− Thƣờng trực Hội NS&MT tỉnh Thái Nguyên.
− Chủ trì phối hợp giữa ba ngành (Nông nghiệp và Phát triển nông thôn
- Y tế - Giáo dục và Đào tạo) để triển khai thực hiện Chƣơng trình
Mục tiêu Quốc gia NS&VSMT nông thôn của tỉnh.
− Duy trì thực hiện theo dõi - đánh giá NS&VSMT nông thôn, kiểm tra
giám sát chất lƣợng nƣớc sinh hoạt nông thôn trên phạm vi toàn tỉnh.
− Xây dựng công trình cấp nƣớc sinh hoạt nông thôn theo kế hoạch.