Tải bản đầy đủ (.pdf) (75 trang)

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 vsmt nông thông thái nguyên

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.42 MB, 75 trang )

..

ĐẠ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 TỐN QUẢN LÝ NƢỚC TẠI
TTNS&VSMT NƠNG THƠN THÁI NGUN

CHUN 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

LỜI CAM ĐOAN
Tơi xin cam đoan về tồ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 hồn tồ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

2

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 tồn bộ q 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 Ngun đã 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


3

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyê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 hố 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 tồn bộ q 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 số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 TỐ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
UML
OOSE
OMT

Tên đầy đủ
Unified Modeling Language
Object-Oriented Software Engineering
Object Modeling Technique

UC

Use case

RUP

Rational Unified Process

GRASP
NS&VSMT

General Responsibility Assignment Software

Nƣớc sạch và vệ sinh môi trƣờng

NM

Nhà máy

TT

Trung tâm

UBND
CMTND
CSDL
PC
GTGT

Ủy ban nhân dân
Chứng minh thƣ nhân dân
Cơ sở dữ liệu
Personal Computer
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 tốn

61


Hình 3.23 Biểu đồ tuần tự ca sử dụng Thanh tố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 số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 tố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 hố thống nhất – UML
Một mơ hình (model) là một sự mơ tả đơn giản hố đố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à q 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 hố 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 hố 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 ObjectOriented Software Engineering - OOSE), James Rumbaugh (với Object
Modeling Technique - OMT).
UML thích hợp cho việc mơ hình hố 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.)
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

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


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)
Bắt đầu

Khởi thảo
Bƣớc 1

Kết thúc

Thời gian

Bƣớc 2

Chi tiết
=

=


Xây dựng
=

=

Chuyển giao
=

Bƣớc n1

Bƣớc n

Suất phẩm thực hiệ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


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 hồ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ó.
Q 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. Q 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 tồn bộ q 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 q
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 q
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 q trình phát triển.
Chính q 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 qt 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 ln 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:
Vấn đề:
Giải pháp

Creator
Ai có trách nhiệm tạo ra một thể hiện mới của một lớ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 q 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 để 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 số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ề ngồ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 tồ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.


×