ĐẠ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ỵ
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
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
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
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
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
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
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
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à
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.
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
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
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ó
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
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.
Copyright: Tài liệu đại học ©