Số hóa bởi Trung tâm Học liệu – Đại học 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
Lê Thị Bắc
PHÂN TÍCH THIẾT KẾ HƯỚNG MẪU
VÀ ỨNG DỤNG VÀO BÀI TOÁN QUẢN LÝ
ĐỀ TÀI, DỰ ÁN CỦA SỞ KHOA HỌC VÀ
CÔNG NGHỆ 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ỵ
PloP
Pattern Languages of Programs
POSA
Pattern-Oriented Software Architecture
POAD
Pattern Oriented Analysis and Design
UML
Unified Modeling Language
GoF
Gang og Four
ĐTDA
Đề tài dự án
KHCN
Khoa học Công nghệ
CNTT
Công nghệ thong tin
UBND
Ủy ban Nhân dân
CSDL
Cơ sở dữ liệu
QLKH
Quản lý khoa học
NCKH
Nghiên cứu khoa học
DM
Danh mục
NSD
Ngƣời sử dụng
DL
Dữ liệu
59
Hình 4.5
Biểu đồ trình tự thống kê, báo cáo
61
Hình 4.6
Mô hình khái niệm phân tích lĩnh vực
63
Hình 4.7
Biểu đồ cộng tác quản trị ngƣời sử dụng
64
Hình 4.8
Biểu đồ cộng tác quản trị danh mục
65
Hình 4.9
Biểu đồ cộng tác quản lý đề tài, dự án đang triển khai
66
Hình 4.10
Biểu đồ cộng tác thống kê báo cáo.
67
Hình 4.11
Các lớp thiết kế cơ bản của hệ thống
69
Hình 4.12
Giao diện chƣơng trình quản lý đề tài dự án
75
Hình 4.13
Danh sách đề tài, dự án
76
Hình 4.14
Danh mục lĩnh vực công nghệ
3.3 Những vấn đề và tồn tại trong hệ thống quản lý đề tài NCKH 38
3.4 Giải pháp tổng thể công nghệ thông tin cho bài toán đặt ra. 38
3.5 Mô hình triển khai 40
CHƢƠNG 4. PHÂN TÍCH VÀ THIẾT KẾ BÀI TOÁN ĐỊNH HƢỚNG
MẪU 42
4.1 Phát triển mô hình nghiệp vụ 42
5
4.2 Mô hình ca sử dụng: 44
4.3 Phân tích hệ thống 56
4.4 Mô hình khái niệm phân tích lĩnh vực: 63
4.5 Thiết kế hệ thống : 64
4.6 Bảng dữ liệu: 70
4.7 Cài đặt và thử nghiệm một số modul 75
6
LỜI NÓI ĐẦU
Phát triển phần mềm theo định hƣớng đối tƣợng ngày càng phát triển
mạnh mẽ và đang chiếm ƣu thế do những đặc trƣng vƣợt trội của nó. Trong
toàn bộ tiến trình phát triển phần mềm, phân tích thiết kế vẫn là một khâu khó
khăn, phức tạp nhất và đòi hỏi ngƣời thực hiện có trình độ cao, có nhiều kinh
nghiệm. Chất lƣợng của phần mềm đạt đƣợc phụ thuộc chủ yếu ở khâu này,
tức là phụ thuộc vào chất lƣợng thiết kế. Tuân thủ theo quy trình RUP, sau
một quá trình phát triển sẽ ta nhận đƣợc một thiết kế hƣớng đối tƣợng của hệ
thống. Có một số tiêu chí về thiết kế tốt cho phép ngƣời ta xem xét nó và hoàn
thiện. Nhƣng một cách khác để hoàn thiện thiết kế thƣờng đƣợc áp dụng, đó
là xem xét thiết kế để cải tiến nó trên cơ sở các kiến thức về các mẫu thiết kế
(design patterns). Các mẫu thiết kế là các giải pháp đã đƣợc các nhà thiết kế
có kinh nghiệm nghiên cứu và hoàn thiện cho những vấn đề thƣờng gặp trong
thiết kế.
Sự xuất hiện của mẫu xuất phát từ rất nhiều sáng kiến khác nhau. Kiến
trúc sƣ Christopher Alexander, giáo sƣ kiến trúc tại trƣờng đại học California
ở Berkeley, đã phát triển nền tảng cho các Mẫu. Từ «Mẫu» (Pattern) có liên
quan hầu hết tới toàn bộ công việc của ông. Ông và nhóm nghiên cứu của
mình đã sử dụng trên 20 năm cho việc phát triển một cách tiếp cận đến kiến
trúc lớn bằng cách dùng các Mẫu. Alexander đã mô tả trên 250 mẫu qua một
hệ quan điểm trừu tƣợng rất rộng, từ các kiến trúc của thị trấn đến các thiết kế
phòng. Ông đã tìm ra một khuôn mẫu mô tả các yếu tố cơ bản của Pattern, đó
là Giải pháp-Vấn đề-Ngữ cảnh. Ông đã viết một cuốn sách về các Mẫu kiến
trúc [4].
Kent Beck and Ward Cunningham đã rất nhiệt tình trong việc áp dụng
các ý tƣởng của Alexander vào việc phát triển phần mềm. Họ đã viết bộ
Pattern đầu tiên về giao diện ngƣời dùng.
Ấn phẩm đầu tiên trình bày về việc dùng các Pattern trong phát triển
phần mềm là luận án tiến sĩ năm 1991 của Erich Gamma, đƣợc viết ở Đức,
lúc đó tác phẩm này chƣa phổ biến. “Gần một nửa các Mẫu Pattern được mô
tả sau này [3] được chứng minh là trước đó có trong luận văn tiến sĩ của
ông” [5].
Bruce Anderson là một trong những ngƣời đi đầu trong nghiên cứu về
Pattern. Ông có một cuộc hội thảo về chủ đề Pattern ở OOPSLA (Ọbect-
Oriented Programming, Systems, Languages, and Applications conference)
vào khoảng những năm 1990; Jim ? đã mô tả các thành ngữ bằng ngôn ngữ
C++ trong cuốn sách của ông có tựa đề là “Advanced C++ Programming
9
Styles and Idioms”. Các thành ngữ đó dù cách này hay cách khác đều liên
quan đến các ý tƣởng của các giải pháp cho các vấn đề thƣờng xuyên xảy ra.
Một nhóm đƣợc gọi là Hillside Group đƣợc thành lập để khám phá thêm về
các ý tƣởng này và đẩy mạnh việc dùng các Mẫu trong việc phát triển phần
mềm. Họ đã làm việc để chỉ đạo và hỗ trợ cho các thành viên mới trong cộng
Một vài cuộc hội thảo đã diễn ra để đánh giá và làm tài liệu các Mẫu mới. Các
cuộc hội thảo hàng năm về ngôn ngữ Pattern là các nguồn chính cho việc
đánh giá và lập danh mục mẫu. Các Mẫu hoàn thiện đã đƣợc làm tài liệu trong
tập các quyển sách về ngôn ngữ mẫu cho thiết kế chƣơng trình [11].
1.2 Khái niệm về mẫu thiết kế (Design 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”[3].
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
11
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ụ:
Chuyển đổi giao diện của một lớp thành giao diện
khác mà clients mong đợi
3.
Bridge
Tách riêng một sự trừu tƣợng với triển khai nó để
hai việc độc lập với nhau
4.
Builder
Phân tách việc xây dựng một đối tƣợng phức tạp
với thể hiện của nó để cùng một tiến trình xây dựng
có th tạo ra nhiều thể hiện khác nhau.
5.
Chain of
Responsibility
Tránh ghép nối đối tƣợng gửi yêu cầu với đối tƣợng
nhận nó bằng cách cho phép nhiều đối tƣợng có cơ
hội nhận yêu cầu đó. Tạo thành dãy các đối tƣợng
nhận và truyền yêu cầu qua dãy này cho tới khi một
đối tƣợng nhận xử lý đƣợc yêu cầu.
6.
Command
Đóng gói một yêu cầu thành một đối tƣợng, nhờ đó
ta có thể tham số hóa các clients với các yêu cầu
khác nhau, các hàng đợi và hỗ trợ các tác vụ không
cho phép hủy.
7.
Composite
Ghép các đối tƣợng tạo thành cấu trúc cây để tạo
thành phân cấp toàn thể - bộ phận treat
lộ thể hiện cơ sở của nó.
14.
Mediator
Định nghĩa một đối tƣợng mà che giấu thông tin về
một tập các đối tƣợng tƣơng tác với nhau nhƣ thế
nào. Mediator đảm bảo kết nối lỏng lẻo bằng cách
giữ các đối tƣợng khỏi sự tham chiếu từ các đối
tƣợng khác.
15.
Memento
Không xâm phạm vào tính bao gói và che giấu
thông tin, nó nắm bắt trạng thái bên trong của đối
tƣợng để sau đó đối tƣợng có thể quay trở về trạng
thái này.
16.
Observer
Định nghĩa một hoặc nhiều sự phụ thuộc giữa các
đối tƣợng
17.
Prototype
Đặc tả các loại đối tƣợng để tạo, sử dụng thể hiện
khuôn mẫu và tạo đối tƣợng mới bằng cách sao
chép khuôn mẫu này
14
18.
Proxy
Cung cấp một đại diện cho một đối tƣợng để điều
khiển truy nhập đến nó.
19.
15
1.4 Phân loại mẫu
Có nhiều cách phân loại khác nhau. Ngoài cách phân loại theo từng lĩnh vực
áp dụng hay từng loại hệ thống cụ thể nhƣ đƣợc trình bày ở mục 4 thì tất cả
các mẫu mà có thể áp dụng đƣợc cho nhiều lĩnh vực khác nhau có thể đƣợc
phân loại theo 2 tiêu chí dƣới đây:
Theo mục đích sử dụng
Creational
Giải quyết các việc tạo
các lớp và các đối
tượng
Structural
Giải quyết mối quan hệ
cấu trúc giữa các lớp và
các đối tượng
Behavioral
Mô tả các cách thức mà
các lớp và các đối
tượng tương tác với
nhau và sự phân bổ
trách nhiệm giữa chúng
Factory Method
Abstract Factory
Builder
Prototype
Singleton
Adapter
Adapter
Bridge
Composite
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of Responsibility
Command
Interator
Mediator
Memento
Observer
State
Strategy
Visitor
Class:
- Các mẫu áp dụng chủ yếu lên các lớp
- Giải quyết mối quan hệ giữa các lớp và các lớp con. Các mối quan hệ này
đƣợc thiết lập qua thừa kế, là mối quan hệ tĩnh, tại thời gian biên dịch.
Object:
- Các mẫu áp dụng chủ yếu lên các đối tƣợng.
- Giải quyết mối quan hệ giữa các đối tƣợng, là mối quan hệ động và thay đổi
tại thời gian chạy.
Các mẫu cấu trúc áp dụng trên lớp dùng thừa kế để cấu thành lớp.
Các mẫu cấu trúc áp dụng trên đối tƣợng mô tả các cách để kết hợp các đối
tƣợng.
Các mẫu hành vi áp dụng trên lớp dùng thừa kế để mô tả các thuật toán và các
luồng điều khiển
nhận ra khi hoàn thiện thiết kế để tăng tính mềm dẻo và tăng khả năng tái sử
dụng của thiết kế.
- Quyết định kĩch cỡ của các đối tượng
Các mẫu hỗ trợ việc xác định đối tƣợng, phân chia đối tƣợng để thu đƣợc các
đối tƣợng với kích thƣớc nhỏ hơn. Ví dụ, Mẫu Abstract Factory và mẫu
Builder sinh ra các đối tƣợng mà trách nhiệm duy nhất của chúng là tạo ra các
đối tƣợng khác, mẫu Visitor và mẫu Command sinh ra các đối tƣợng mà trách
nhiệm duy nhất của chúng là triển khai một yêu cầu trên một đối tƣợng khác
hoặc trên một nhóm đối tƣợng khác.
- Đặc tả các giao diện đối tượng (object interface)
Các tác vụ (operator) của đối tƣợng đƣợc mô tả bằng tên tác vụ, tham số, giá
trị trả về. Mô tả tác vụ còn đƣợc gọi là khai báo tác vụ. Tập hợp tất cả các
khai báo tác vụ của một đối tƣợng tạo thành giao diện của đối tƣợng đó. Giao
diện của một đối tƣợng thể hiện các yêu cầu có thể đƣợc gửi đến đối tƣợng
đó, bất kỳ yêu cầu nào mà khớp với một khai báo trong giao diện đều có thể
đƣợc gửi tới đối tƣợng.
Một kiểu (type) là một tên gọi đƣợc sử dụng để nói đến một giao diện cụ thể.
Chúng ta nói rằng, một đối tƣợng có kiểu Window nếu nó chấp nhận tất cả
các yêu cầu cho các tác vụ đƣợc định nghĩa trong giao diện có tên là Window.
Một đối tƣợng có nhiều kiểu và các đối tƣợng khác nhau có thể chia xẻ cùng
một kiểu. Một phần của giao diện đối tƣợng có thể đặc trƣng bởi một kiểu và
các phần khác thì bởi các kiểu khác. Hai đối tƣợng của cùng một kiểu chỉ cần
chia xẻ các phần giao diện của chúng. Các giao diện có thể chứa các giao diện
khác nhƣ là các tập con của chúng. Chúng ta nói rằng một kiểu là kiểu con
của kiểu khác nếu giao diện của nó chứa giao diện của siêu kiểu của nó (kiểu
19
cha của nó). Thông thƣờng chúng ta nói, một kiểu con thừa kế giao diện của
kiểu cha của nó.
Các giao diện là các đối tƣợng cơ bản của các hệ thống hƣớng đối tƣợng. Các
chiếu tới giao diện của đối tƣợng, nó thể hiện một tập yêu cầu có thể gửi đến
đối tƣợng.
Nhiều mẫu thiết kế chú trọng đến sự phân biệt giữa lớp và kiểu. Ví dụ, các đối
tƣợng trong mẫu Chain of Responsibility phải có cùng kiểu nhƣng thƣờng có
các sự cài đặt khác nhau.
- Tăng hiệu quả tái sử dụng
Trong phát triển hƣớng đối tƣợng, có hai cách để tái sử dụng là sử dụng thừa
kế và kết hợp các đối tƣợng. Mỗi cách này có những thuận lợi và rào cản
riêng. Sử dụng thành phần đại diện (delegation) là một cách để kết hợp những
thuận lợi của hai cách trên. Nhiều mẫu hỗ trợ sử dụng khái niệm này trong
thiết kế, nhƣ State, Strategy, Visitor, Mediator, Chain of Responsibility và
Bridge.
- Liên hệ các cấu trúc thời gian chạy và các cấu trúc thời gian biên dịch
Các cấu trúc ở thời gian biên dịch gồm các lớp và mối quan hệ cố định giữa
các lớp, còn các cấu trúc ở thời gian chạy gồm các đối tƣợng và sự giao tiếp
giữa các đối tƣợng. Có nhiều mẫu hỗ trợ hiểu và xây dựng các cấu trúc thời
gian chạy phức tạp, chẳng hạn Compostise, Decorator, Observer, Chain of
Responsibility.
- Thiết kế cho sự thay đổi
Tính chất của thiết kế mà đảm bảo khả năng tái sử dụng là cho phép bổ sung
yêu cầu mới và thay đổi yêu cầu hiện tại. Mẫu giúp cho hệ thống có thể thay
đổi bằng cách để cho một số phần của hệ thống độc lập với những phần khác,
21
chẳng hạn, các mẫu Bridge, Chain of Responsibility, Composite, Decorator,
Observer và Strategy hỗ trợ mở rộng các chức năng của hệ thống bằng cách
tạo các lớp con.
1.6 Áp dụng mẫu thiết kế trong phát triển phần mềm
Lợi ích thu được
- Tăng cƣờng tái sử dụng
động hay bƣớc tiến trình mà ngƣời phân tích hay thiết kế tiến hành bên trong
các pha cụ thể. Chúng ta sẽ giải thích mỗi bƣớc của pha phát triển qua mục
đích, tiến trình và sản phẩm; Phần mục đích giải thích vì sao nhà thiết kế tiến
hành bƣớc đó, phần tiến trình mô tả sự hoạt động mà ngƣời thiết kế thực hiện
trong bƣớc đó, phần sản phẩm mô tả đầu ra mong muốn của bƣớc đó.
Thông thƣờng tiến trình POAD gồm có 3 pha: Trong Pha phần tích một
tập các mẫu đƣợc chọn từ một thƣ viện miền cụ thể. Ở pha thiết kế ở mức cao,
các mẫu đƣợc gắn lại với nhau bằng cách sử dụng các mô hình cấu thành mẫu
để tạo ra biểu đồ lớp ban đầu, và ở pha làm mịn thiết kế, biểu đồ lớp ban đầu
đƣợc xử lý để tạo ra biểu đồ lớp đậm đặc hơn và sâu sắc hơn cho ứng dụng .
23
2.1.1 Pha phân tích
a. Mục đích
Mục đích của pha này là để phân tích các yêu cầu của ứng dụng và quyết
định các mẫu thiết kế thích hợp nào sẽ đƣợc sử dụng trong việc thiết kế hệ
thống.
b. Tiến trình
Sử dụng các yêu cầu ứng dụng là đầu vào, ở các bƣớc khác nhau nhà
phân tích theo thứ tự sẽ quyết định tập hợp các mẫu thiết kế lấy từ thƣ viện
của các mẫu ứng dụng cụ thể. Trong bƣớc này, biểu đồ ca sử dụng của UML
và biểu đồ tuần tự có thể đƣợc sử dụng để xác định các mẫu cầu thiết hỗ trợ
các tƣơng tác này. Các mẫu này sẽ đƣợc sử dụng trong việc xây dựng thiết kế
hệ thống.
Ở mức này, nhà phân tích không quan tâm tới các chi tiết bên trong của
các mẫu. Ví dụ, nó không cần biết đƣợc mẫu này giải quyết các vấn đề đƣợc
đƣa ra trong các yêu cầu của ứng dụng nhƣ thế nào. Thay vào đó, nhà phân
tích có liên quan tới sự xác định xem một mẫu có thể đƣợc sử dụng hay không
và tại sao nếu nó đƣợc sử dụng thì sẽ tốt hơn là sử dụng các mẫu khác trong
thƣ viện hay là các giải pháp riêng. Nhà phân tích đầu tiên phải xác định các
xác hoặc xấp xỉ và các tiêu chuẩn đánh giá là đúng đắn, gọn lại, tỉ lệ đƣợc đƣa
ra, độ phức tạp, và sự tự động hóa [Mili et al, 1998]. Các mẫu thiết kế cũng
không phải là ngoại lệ. Tuy nhiên, trích rút các mẫu từ cơ sở dữ liệu có thể sẽ
dễ dàng hơn bởi vì cộng đồng mẫu đã thực hiện công việc một cách hoàn hảo
gắn với định nghĩa của các mẫu khi sử dụng một hoặc một số tiêu bản, làm
Copyright: Tài liệu đại học ©