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

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ấ

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn

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ỵ

Thái Nguyên – 2012

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên http://www.lrc-tnu.edu.vn

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

Lê Thị Bắc

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

Viết tắt Tên đầy đủ

RUP Rational Unified Process

OOPSLA Ọbect-Oriented Programming, Systems, Languages,

and Applications conference 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

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

Hình 3.1 Sơ đồ tiến trình hoạt động quản lý đề tài, dự án 34 Hình 3.2 Mô hình triển khai hệ thống 40 Hình 4.1 Mô hình ca sử dụng mức tổng thể của hệ thống quản

lý đề tài dự án

44

Hình 4.2 Biểu đồ tuần tự hệ thống đăng nhập 56 Hình 4.3 Biểu đồ tuần tự hệ thống Quản trị người sử dụng 57 Hình 4.4 Biểu đồ tuần tự chức năng QL DTDA đang triển khai 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ệ 76 Hình 4.15 Bảng danh mục cán bộ tham gia đề tài 77 Hình 4.16 Chi tiết danh sách đề tài dự án đang triển khai 78

MỤC LỤC

LỜI CAM ĐOAN 1

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

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

MỤC LỤC 4

LỜI NÓI ĐẦU 6

CHƯƠNG 1: TỔNG QUAN VỀ MẪU THIẾT KẾ 8

1.1 Lịch sử phát triển mẫu thiết thiết kế 8

1.2 Khái niệm về mẫu thiết kế (Design pattern) 10

1.3 Hệ thống các mẫu thiết kế và phân loại 11

1.4 Phân loại mẫu 15

1.5 Lợi ích của việc sử dụng các mẫu trong thiết kế 17

1.6 Áp dụng mẫu thiết kế trong phát triển phần mềm 21

CHƯƠNG 2 : QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG MẪU 22 2.1 Các bước của tiến trình phân tích và thiết kế hướng mẫu 22

2.2 Phân tích và đặc tả yêu cầu hệ thống 26

2.3 Tiến trình sử dụng mẫu thiết kế 27

CHƯƠNG 3 : BÀI TOÁN NGHIỆP VỤ VÀ GIẢI PHÁP GIẢI QUYẾT VẤN ĐỀ 29

3.1 Khảo sát thu thập dữ liệu và mô tả bài toán 29

3.2 Mô tả hoạt động nghiệp vụ của hệ thống (mô hình nghiệp vụ) 29

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

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

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ế

Một cách làm triệt để hơn để sử dụng lại các mẫu cho thiết kế là phân tích thiết kế định hướng mẫu Đây là một trong ba hướng sử dụng lại của phát triển phần mềm hướng đối tượng – sử dụng lại các mẫu Với mong muốn áp

dụng các công nghệ mới cho phát triển phần mềm, tôi đã chọn đề tài “Phân

tích thiết kế hướng mẫu và ứng dụng cho 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 “ làm đề tài của luận văn

Theo phương pháp phân tích thiết kế định hướng mẫu, người ta sử dụng các mẫu thiết kế ngay sau khi đặc tả yêu cầu Như vậy, sau khi đặc tả yêu cầu của bài toán theo phương pháp hướng đối tượng, ta phải tìm kiếm các mẫu tương ứng cho mỗi đặc tả chi tiết Khó khăn lớn ở đây là có rất nhiều mẫu khác nhau, làm sao chọn được một mẫu thích hợp Hơn nữa, các đặc trưng mô

tả mẫu là tương đối trừu tượng, có sự khác biệt đáng kể với các đặc trưng đặc

tả yêu cầu Vì thế đòi hỏi người phát triển hệ thống có hiểu biết sâu xắc về mỗi mẫu, nắm chắc được yêu cầu của vấn để đặt ra, để từ đó chọn ra một mẫu giải quyết được yêu cầu của vấn đề Mặt khác, cùng một yêu cầu, có thể có nhiều mẫu có khả năng đáp ứng được yêu cầu đó Đây lại là một cách lựa

chọn đòi hỏi phải có kinh nghiệm từ thực tiễn triển khai ứng dụng Theo phương pháp này, ta đã bỏ qua được các bước đi tuần tự, từ mức cao đến mức chi tiết của giai đoạn phân tích và thiết kế, thường tốn nhiều thời gian công sức với nhiều mô hình phương pháp khác nhau Vì vậy đây là cách làm hiệu quả, vừa tiết kiệm thời gian, công sức và vẫn cho phép nhận được một thiết kế tốt Mặc dù hướng này là rất khó khăn, với mong muốn thử nghiệm công nghệ và nâng cao kỹ năng phân tích thiết kế, tôi chọn nó để giải quyết bài toán đặt ra

CHƯƠNG 1: TỔNG QUAN VỀ MẪU THIẾT KẾ 1.1 Lịch sử phát triển mẫu thiết 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

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

đồng Pattern Nhóm này đã thành lập nên Ngôn ngữ mẫu cho chương trình

(Pattern Languages of Programs- PloP) lần đầu tiên vào năm 1994 tại một hội nghị Tri thức chung về mẫu đã được thể hiện tốt trong một cuốn sách gồm 4

người cùng tham gia viết, Design Patterns: Elements of Object-Oriented

Software [3], họ đã phân loại và mô tả rất rõ 23 mẫu thiết kế được dùng rất phổ biến trong lập trình hướng đối tượng

Peter Coad đã làm việc với các Mẫu hướng đối tượng từ rất sớm [6] Ông đã

mô tả 7 mẫu đơn giản trong phân tích và thiết kế Ông đã làm việc trên các Mẫu hỗ trợ phân tích miền ứng dụng và dùng công nghệ hướng đối tượng để xây dựng các ứng dụng [7] Douglas Schmidt cũng là một trong những người đầu tiên nghiên cứu về mẫu; ông là tác giả của nhiều Mẫu trong các hệ thống giao tiếp và các ứng dụng phân tán [8] Wolfgang Pree đã làm việc trên các mẫu dành cho việc phát triển khung làm việc (framework) [9] Ông đã phân nhóm các nguyên lý mang tính cấu trúc thành các Siêu Mẫu (MetaPattern)

được dùng để phát triển các khung làm việc Pattern-Oriented Software: A

Pattern System, cũng được coi là cuốn sách “Tốp 5” [5], chú trọng vào việc

dùng các Mẫu ở mức kiến trúc của phát triển phần mềm Các tác giả đã phân loại các Mẫu phần mềm như là các Mẫu kiến trúc, các mẫu thiết kế và các Thành ngữ Phần lớn sự đóng góp của họ đều được hướng tới các Mẫu kiến

trúc Cuốn sách của họ cùng với cuốn sách của bốn tác giả Erich Gamma,

Richard Helm, Ralph Johnson, John Vlissides là những tài liệu rất tốt cho

những người mới bắt đầu nghiên cứu mẫu Quyển 2 của tập sách

Pattern-Oriented Software Architecture - POSA [10] mô tả các mẫu cho các đối

tượng đồng thời (concurrent) và đối tượng mạng, giải thích các Mẫu và thể

hiện kĩ thuật xây dựng các ứng dụng phân tán Cuốn sách bao gồm các mẫu truy cập dịch vụ, các Mẫu Cấu hình, các mẫu điều khiển sự kiện, các mẫu đồng bộ hoá và các mẫu Đồng thời Một ngôn ngữ mẫu dành cho MiddleWare

và các ứng dụng cũng được mô tả

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

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ệ

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

1.3 Hệ thống các mẫu thiết kế và phân loại

Hệ thống các mẫu thiết kế hiện có 23 mẫu được định nghĩa trong cuốn

“Design patterns Elements of Reusable Object Oriented Software” Hệ thống các mẫu này có thể nói là đủ và tối ưu cho việc giải quyết hết các vấn đề của bài toán phân tích thiết kế và xây dựng phần mềm trong thời điểm hiện tại

TT Tên mẫu Vai trò của mẫu

1 Abstract Factory Cung cấp giao diện để tạo họ các đối tƣợng độc lập

hoặc liên quan nhau mà không cần đặc tả các lớp cụ thể của chúng

2 Adapter 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

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

8 Decorator Gắn các trách nhiệm bổ sung cho một đối tƣợng

theo cách động, hỗ trợ cho việc bổ sung chức năng

9 Facade Cung cấp một giao diện thống nhất cho một tập các

giao diện trong một hệ thống con Façade định nghĩa một giao diện mức cao mà làm cho các hệ

thống con dễ sử dụng

10 Factory Method Định nghĩa một giao diện để tạo một đối tượng

nhưng cho phép các lớp con quyết định lớp nào để làm thể hiện

11 Flyweight Sử dụng chia sẻ để hỗ trợ số lượng lớn các đối

tượng được làm mịn một cách hiệu quả

12 Interpreter Đưa ra một ngôn ngữ, định nghĩa một thể hiện cùng

với một đối tượng biểu thị mà dùng thể hiện này để biểu thị các câu trong ngôn ngữ

13 Iterator Cung cấp một cách để truy cập các yếu tố của một

đối tượng tập hợp một cách tuần tự mà không làm

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

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 Singleton Đảm bảo một lớp chỉ có một thể hiện và cung cấp

điểm truy nhập toàn cục cho nó

20 State Cho phép một đối tượng thay đổi hành vi của nó

khi trạng thái bên trong nó thay đổi

21 Strategy Định nghĩa họ các thuật toán, đóng gói nó, làm cho

chúng có thể hoán đổi cho nhau và không phụ thuộc vào đối tượng dùng nó

22 Template Method Định nghĩa khung thuật toán cho một tác vụ

23 Visitor Thể hiện một tác vụ được thực hiện trên các yếu tố

của một cấu trúc đối tượng Mẫu cho phép định nghĩa một tác vụ mới mà không thay đổi lớp các yếu tố mà nó thao tác trên đó

Có nhiều mẫu thiết kế dành riêng cho từng lĩnh vực cụ thể:

 Mẫu thiết kế cho hệ thống điều khiển phương tiện tự động

 Mẫu thiết kế cho hệ thống âm nhạc có tương tác

 Mẫu thiết kế cho các dịch vụ mạng với cấu hình linh hoạt trong các hệ thống phân tán

 45 mẫu thiết kế cho các hệ thống thời gian thực và hệ thống phân tán

 Các mẫu thiết kế theo công nghệ J2EE

 Các mẫu Expert, Creator, LowCoupling, High Cohension và Controller

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:

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

Interpreter Template Method Chain of Responsibility Command

Interator Mediator Memento Observer State Strategy Visitor

Theo phạm vi/đối tượng áp dụng

Class Factory Method

Adapter Interpreter Template Method

Object Abstract

Factory Builder Prototype Singleton

Adapter 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

Các mẫu hành vi áp dụng trên đối tượng mô tả cách thức mà một nhóm đối tượng cộng tác với nhau để thực hiện một nhiệm vụ mà không có một đối tượng riêng lẻ nào có thể thực hiện độc lập

Ngoài ra, chúng ta có thể phân loại mẫu theo ngôn ngữ triển khai mẫu:

Ngôn ngữ Java: interfaces, responsibility, construction, operations, and extensions

1.5 Lợi ích của việc sử dụng các mẫu trong thiết kế

Mẫu thiết kế giải quyết nhiều vấn đề mà các nhà thiết kế hướng đối tượng phải đối mặt và bằng nhiều cách khác nhau Dưới đây là một số vấn đề mà mẫu có thể giải quyết và cách thức mẫu giải quyết các vấn đề đó

- Tìm các đối tượng (object) phù hợp

Trong thiết kế hướng đối tượng, chúng ta cần phân chia một hệ thống thành các đối tượng Việc này là không dễ dàng vì thiết kế của chúng ta phải đảm bảo các tiêu chí như bao gói, mịn, độc lập, mềm dẻo, hiệu năng, tái sử dụng,… Các tiêu chí này thường mâu thuẫn nhau

Đã có nhiều cách tiếp cận khác nhau để thực hiện công việc này, hoặc là viết

ra một câu mô tả ngắn về vấn đề với các danh từ và các động từ, chúng ta tạo

ra các lớp (class) và phương thức (method) của các lớp tương ứng với các

danh từ và các động từ tìm được trong câu mô tả, hoặc là chúng ta mô hình hóa các đối tượng của thế giới thực và chuyển các đối tượng được tìm thấy trong giai đoạn phân tích sang giai đoạn thiết kế

Các mẫu thiết kế giúp chúng ta xác định các đối tượng phù hợp Ví dụ, các đối tượng thể hiện các vi xử lý hay các thuật toán mà không xuất hiện trong thế giới thực nhưng chúng lại là phần cốt lõi của các thiết kế mềm dẻo Mẫu Strategy mô tả cách triển khai họ các thuật toán Mẫu State thể hiện mỗi trạng thái của một thực thể như là một đối tượng Các đối tượng này ít khi được tìm

thấy trong giai đoạn phân tích hoặc giai đoạn đầu của thiết kế, chúng chỉ được 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

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 đối tượng đựợc biết chỉ qua giao diện của chúng Không có cách nào để biết bất cứ điều gì về một đối tượng mà không thông qua giao diện của nó

Hai đối tượng có triển khai khác nhau hoàn toàn có thể có giao diện giống nhau Khi một yêu cầu được gửi đến một đối tượng, tác vụ nào được thực hiện là phụ thuộc vào cả đối tượng gửi và đối tượng nhận yêu cầu

Các đối tượng khác nhau hỗ trợ các yêu cầu giống nhau có thể có các triển khai khác nhau của tác vụ mà đáp ứng các yêu cầu đó Liên kết của một yêu cầu tới một đối tượng và một trong các tác vụ của nó tại thời gian chạy được

gọi là liên kết động (dynamic binding)

Liên kết động có nghĩa là một yêu cầu không được hồi đáp cho tới thời gian chạy Kết quả là chúng ta có thể viết ra các chương trình mà mong đợi một đối tượng với một giao diện cụ thể Biết rằng bất kỳ đối tượng nào có giao diện đúng sẽ chấp nhận yêu cầu Tuy nhiên liên kết động cho phép chúng ta nhận ra các đối tượng mà có các giao diện giống nhau ở mỗi thời gian chạy

khác nhau Tính chất này được gọi là đa hình (polymorphism), nó là khái

niệm chính trong hệ thống hướng đối tượng Đa hình tách biệt các đối tượng

và giúp chúng có những mối quan hệ khác nhau ở mỗi thời gian chạy

Các mẫu thiết kế giúp định nghĩa các giao diện bằng cách nhận ra các yếu tố chính và các loại dữ liệu chính mà có thể gửi và nhận qua giao diện Mẫu thiết

kế cũng có thể cho ta biết những gì không nên đặt ở trên giao diện, chẳng hạn mẫu Memento Mẫu này mô tả cách bao gói và lưu trữ trạng thái bên trong của đối tượng để đối tượng có thể quay về trạng thái đó trong tương lai

Các mẫu thiết kế cũng đặc tả mối quan hệ giữa các giao diện Cụ thể, chúng thường yêu cầu một vài lớp có các giao diện tương tự nhau hoặc chúng đặt

các ràng buộc trên giao diện của một vài lớp, ví dụ mẫu Decorator và mẫu Proxy

- Đặc tả việc triển khai đối tượng

Lớp khác với kiểu: lớp định nghĩa việc triển khai đối tượng, kiểu chỉ tham 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,

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

 Khi nào không dùng mẫu?

Áp dụng mẫu cho các thiết kế mềm dẻo, chất lượng nhưng đòi hỏi chi phí cho việc tìm kiếm, hiểu và sử dụng mẫu Vì vậy, mẫu chỉ nên được áp dụng khi kết quả mà nó mang lại tương xứng với chi phí bỏ ra cho việc áp dụng nó Phần kết quả mang lại của mẫu sẽ hữu ích cho việc đánh giá độ tương xứng này

CHƯƠNG 2 : QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ

HƯỚNG MẪU 2.1 Các bước của tiến trình phân tích và thiết kế hướng mẫu

Các khía cạnh của tiến trình phân tích và thiết kế hướng mẫu (Pattern Oriented Analysis and Design – POAD) giải thích các pha và các bước để phát triển một thiết kế ứng dụng có sử dụng các mẫu Đầu ra của tiến trình điều khiển là một thiết kế mẫu hướng đối tượng hoặc là một khung làm việc hướng mẫu Yêu cầu chính của đầu vào tiến trình là thư viện các mẫu thiết kế cấu trúc được xây dựng Chúng ta sử dụng thuật ngữ pha để ám chỉ các giai

đoạn đã được biết trong phát triển phần mềm: phân tích, thiết kế, thiết kế chi

tiết, triển khai, kiểm thử… Chúng ta sử dụng thuật ngữ bước để chỉ các hoạt

độ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

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 gói khái niệm hay là các thành phần mà họ lấy làm đại diện cho các thuộc tính chức năng của hệ thống Các trách nhiệm chức năng này xác định vai trò toàn diện của thành phần khái niệm và được sử dụng để hướng dẫn tiến trịnh lựa chọn mẫu bằng cách định danh các trách nhiệm cần thiết được yêu cầu từ một mẫu cụ thể để triển khai thành phần khái niệm này

Là một phần của pha phân tích, các nhà phân tích tìm kiếm mẫu phân tích từ danh sách các mẫu ứng viên Để tìm kiếm một cách có hiệu quả, thư

viện miền cụ thể của các mẫu sẽ tốt hơn là thư viện cho mục đích chung Tương tự việc quản lý thư viện các thành phần phần mềm trước đây, tiến trình này bao gồm việc làm quen bước đầu và trích rút thông tin

Sự định nghĩa không rõ ràng các thành phần khái niệm sẽ làm cho việc làm quen bước đầu không có hiệu quả Nó sẽ gây ra sự khó khăn khi xây dựng mẫu thiết kế để thực thi chức năng đã được xác định trong thành phần khái niệm Do đó, bước này thường dựa vào những tìm hiểu các thư viện mẫu

có sẵn được lựa chọn Trên thực tế, một vài mẫu trong thư viện có thể thúc đẩy nhà phân tích xác định các thành phần khái niệm được thiết kế một cách

dễ dàng và được thực thi bằng cách sử dụng các mẫu đó Ví dụ, một ngôn ngữ mẫu của các máy trạng thái và biểu đồ trạng thái đã thúc đẩy nhà phân tích phát triển mô hình (hay kiến trúc) dựa trên các thành phần cộng tác có hành

vi được mô hình hóa thích hợp trong dạng đặc tả trạng thái Mô hình hóa hướng đối tượng thời gian thực của Selic, Gullekson và Ward[1994] có các

mô hình kiến trúc dựa trên những kĩ thuật như vậy Sự làm quen với nội dung của thư viện là một hoạt động mà nhà phân tích sẽ cân nhắc đến trong pha phân tích

Tiến trình trích chọn xác định việc lựa chọn mẫu như thế nào từ tập danh mục Sự trích rút các tài sản phần mềm từ thư viện là một chủ đề nghiên cứu lớn hàng chục năm nay Nhiều kĩ thuật đã được đưa ra, và nhiều vấn đề khác nhau đã được xác định bao gồm các tiêu chuẩn phù hợp, việc trích rút chính 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

cho việc trích rút tự động mẫu một cách dễ dàng hơn nhờ cách tiếp cận vấn đề hay nội dung mẫu đối với vấn đề đã được giải quyết

c Sản phẩm

Sản phẩm của pha này là một tập các mẫu thiết kế đã các nhà phân tích ứng dụng chọn Cần chú ý là, ở pha này không có bất cứ chi tiết cụ thể nào về mẫu được đưa ra, có nghĩa là hoặc không có một mô hình lớp hoặc mô hình hành vi nào được đưa ra trong bước phân tích

b Tiến trình

Đầu tiên, người thiết kế tạo ra các thể hiện của các mẫu đã được chọn trong pha phân tích và xác định quan hệ giữa các thể hiện này Đây là ứng dụng trực tiếp của cách tiếp cận ghép mẫu mà kết quả nằm trong khung nhìn lôgic mẫu mức cao

Sự hoạt động này bao gồm một vài các hoạt động con khác nhau như là tạo các mẫu bằng cách đưa mẫu thiết kế vào trong các chế tác thiết kế hữu hình, xác định các mối quan hệ giữa các mẫu, và cấu trúc các biểu đồ mức mẫu cho toàn bộ hệ thống và cho từng hệ thống con riêng rẽ Chia nhỏ hệ thống thành các hệ con sẽ thúc đẩy hoạt động cho các hệ lớn phức tạp

Từ biểu đồ mức mẫu đã tạo ra, người thiết kế xử lý để nhận được biểu

đồ mức mẫu cùng với các giao diện Người thiết kế sẽ phân tích các quan hệ giữa các thể hiện mẫu và sau đó là lần vết các quan hệ này đến mối quan hệ thiết kế ở mức thấp hơn giữa các giao diện mẫu Sau đó sẽ xác định các giao diện mẫu và phân rã các quan hệ phụ thuộc của mẫu thành các mối quan hệ mức thấp hơn giữa các giao diện mẫu Kết quả là các biểu đồ mức mẫu với các giao diện và các biểu đồ mức mẫu được làm mịn

Bắt đầu từ biểu đồ mức mẫu với các giao diện, người thiết kế xác định các chi tiết mẫu theo thuật ngữ của biểu đồ lớp, nhằm tạo ra một biểu đồ lớp ban đầu cho hệ thống, kết quả là một biểu đồ mức mẫu đã chi tiết được tạo ra

c Sản phẩm

Sản phẩm của pha này là các biểu đồ mức mẫu được chi tiết, đó là mô hình thiết kế của ứng dụng, là một tập các mẫu được thể hiện

2.2 Phân tích và đặc tả yêu cầu hệ thống

Lựa chọn các mẫu cho các yêu cầu

Mục đích

- Mục đích của hoạt động lựa chọn mẫu là lựa chọn các mẫu đáp ứng đầy

đủ các trách nhiệm của mỗi thành phần khái niệm mà được xác định từ việc xác định yêu cầu của ứng dụng Các mẫu này sẽ được sử dụng trong giai đoạn thiết kế của phương pháp phân tích thiết kế hướng mẫu để xây dựng các khung nhìn mức mẫu

− Lựa chọn mẫu là công việc khó khăn và quyết định hiệu quả của sử dụng mẫu Để lựa chọn mẫu phù hợp, chúng ta cần xem xét một số vấn

đề sau:

− Kiểm tra xem mẫu giải quyết vấn nào bằng cách duyêt qua phần giải pháp và đánh giá xem giải pháp mà mẫu cung cấp có thể sử dụng để giải quyết vấn đề đang có không

− Duyệt phần nội dung, mà trong đó mô tả vấn đề là cái gì và có tương tự vấn đề đang có hay không

− Nghiên cúa xem các mẫu có liên quan với nhau như thế nào Tìm kiếm các mẫu tương tự hoặc các mẫu thường được sử dụng theo cặp, theo nhóm

− Xem mục đích và vai trò của các mẫu

− Xem xét các yếu tố có thể thay đổi được trong thiết kế mà không cần phải thiết kế lại hoàn toàn: mỗi mẫu hỗ trợ chúng ta thực hiện một sự thay đổi mà không yêu cầu phải thiết kế lại hoàn toàn

Trong những năm gần đây, việc lựa chọn mẫu được hướng đến khả năng

tự động hóa Một số nhóm nghiên cứu đã đề xuất các phương pháp tăng cường khả năng tự động hóa trong công đoạn này nhưng còn nhiều hạn chế

2.3 Tiến trình sử dụng mẫu thiết kế

Khi đã lựa chọn được mẫu phù hợp, ta cần áp dụng nó trong thiết kế một cách hiệu quả Dưới đây là một số hướng dẫn cho quá trình áp dụng mẫu:

- Đọc mẫu một lần ở mức khái quát, chủ yếu là phần mục đích và kết quả của mẫu để chắc chắn là chúng ta đã lựa chọn mẫu phù hợp

- Nghiên cứu phần cấu trúc, các thành viên tham gia và các cộng tác trong mẫu để đảm bảo hiểu các lớp, các đối tượng trong mẫu và mối quan hệ giữa chúng

- Xem xét phần mã minh họa để biết cách triển khai mẫu

- Chọn các tên gọi tương ứng với các thành viên tham gia trong mẫu mà có ý nghĩa trong khung cảnh ứng dụng hiện tại Các tên gọi của các thành viên trong mẫu thường quá trừu tượng đối với một ứng dụng cụ thể Tuy nhiên, ta nên kết hợp các tên gọi trong mẫu với các tên gọi của ứng dụng để các mẫu được thể hiện rõ ràng hơn trong triển khai Ví dụ, SimpleLayoutStrategy là tên gọi của một đối tượng trong ứng dụng mà áp dụng mẫu Strategy

- Định nghĩa các lớp: mô tả các giao diện của chúng, thiết lập các mối quan hệ thừa kế, các thể hiện của lớp,…

- Định nghĩa các tên gọi cụ thể cho các tác vụ trong mẫu của ứng dụng

- Cài đặt các tác vụ để thực hiện các trách nhiệm và các cộng tác

CHƯƠNG 3 : BÀI TOÁN NGHIỆP VỤ VÀ GIẢI PHÁP GIẢI QUYẾT

VẤN ĐỀ

3.1 Khảo sát thu thập dữ liệu và mô tả bài toán

Hoạt động nghiên cứu và ứng dụng thành tựu khoa học và công nghệ vào sản xuất và đời sống ngày càng phát triển Tại tỉnh Thái Nguyên, trung bình hàng năm có hàng chục đề tài, dự án được phê duyệt và có hàng chục đề tài,

dự án chuyển tiếp từ năm trước Trong thời gian qua, công tác quản lý KHCN nói chung và quản lý các đề tài, dự án KHCN nói riêng tại Sở Khoa học và Công nghệ tỉnh Thái nguyên không ngừng được tăng cường và đổi mới Tuy nhiên, việc quản lý, theo dõi các đề tài, dự án tại Sở Khoa học và Công nghệ thời gian qua vẫn theo lối truyền thống nên việc tìm kiếm, tra cứu thông tin, báo cáo thống kê, tổng hợp dữ liệu ĐTDA phục vụ cho công tác quản lý gặp nhiều khó khăn Xuất phát từ yêu cầu thực tiễn đó, việc ứng dụng tin học hóa trong công tác quản lý các đề tài, dự án KHCN là một nhiệm vụ cấp thiết, giúp cho các đối tượng khác nhau có thể cập nhật, tra cứu, quản lý một cách nhanh chóng và chính xác Tăng cường công tác quản lý các đề tài, dự án KHCN cấp Tỉnh một cách có khoa học, đảm bảo tính chính xác và tính kịp thời; Ứng dụng CNTT phục vụ quản lý Nhà nước, góp phần thực hiện tốt công tác cải cách hành chính, nâng cao hiệu quả công tác; Nâng cao năng lực chuyên môn, năng lực quản lý cho cán bộ làm công tác quản lý khoa học tại

Sở khoa học và công nghệ tỉnh Thái Nguyên

3.2 Mô tả hoạt động nghiệp vụ của hệ thống (mô hình nghiệp vụ)

3.2.1 Mô tả quy trình thực hiện các đề tài/ dự án khoa học và công nghệ Xây dựng và đăng ký thực hiện nhiệm vụ KHCN:

Đơn vị đăng ký nhiệm vụ KHCN căn cứ Chiến lược, đề án phát triển

KHCN của tỉnh; nhu cầu nghiên cứu, ứng dụng KHCN của đơn vị xây dựng

và đăng ký thực hiện nhiệm vụ KHCN (đề tài, dự án, dự án KHCN doanh nghiệp) theo thông báo hàng năm của Sở KH&CN

Quyết định Danh mục nhiệm vụ KHCN:

Sở KH&CN căn cứ kết quả họp Hội đồng chính sách KHCN tỉnh (có biên bản cuộc họp) trình UBND tỉnh phê duyệt Danh mục nhiệm vụ KHCN

Xây dựng hồ sơ:

Theo mục tiêu, nội dung chính và dự kiến kinh phí được phê duyệt tại Danh mục thực hiện nhiệm vụ KHCN, Chủ nhiệm đề tài, dự án và Cơ quan chủ trì chịu trách nhiệm hoàn thiện hồ sơ (15 bộ) theo hướng dẫn và mẫu thống nhất trong Tài liệu Hướng dẫn thực hiện nhiệm vụ KHCN cấp tỉnh

Kiểm tra:

Phòng Quản lý Khoa học căn cứ hồ sơ thuyết minh đề tài dự án được xây dựng, kiểm tra đủ điều kiện theo quy định trước khi trình Hội đồng KHCN chuyên ngành của tỉnh xét duyệt

Xét duyệt:

Hội đồng KHCN chuyên ngành của tỉnh thành lập theo Quyết định của Giám đốc Sở KH&CN tổ chức họp đánh giá hồ sơ đề tài dự án Hội đồng bỏ phiếu chấm điểm và kết quả họp Hội đồng đƣợc ghi trong biên bản Nếu hồ

sơ không đạt yêu cầu, Sở KH&CN ra thông báo dừng triển khai cho Cơ quan chủ trì thực hiện đề tài dự án biết

Hoàn chỉnh hồ sơ:

Sau khi có ý kiến của Hội đồng KHCN tỉnh họp xét duyệt thuyết minh,

Cơ quan chủ trì thực hiện hoàn chỉnh lại thuyết minh đề tài dự án theo biên bản góp ý của Hội đồng

Thẩm định dự toán:

Giám đốc Sở KH&CN ra quyết định thành lập tổ thẩm định tài chính đề tài dự án trên cơ sở thuyết minh đã đƣợc chỉnh sửa theo các góp ý của Hội đồng KHCN tỉnh

Sở KH&CN tiến hành kiểm tra tiến độ thực hiện các nội dung đề tài dự án; phối hợp với Sở Tài chính kiểm tra tình hình sử dụng kinh phí Có biên bản của đoàn kiểm tra, Chủ nhiệm đề tài dự án có trách nhiệm tiếp thu các ý kiến kết luận của đoàn kiểm tra trong quá trình thực hiện

Xây dựng Hồ sơ báo cáo kết quả nghiệm thu cơ sở:

Khi kết thúc nhiệm vụ KHCN, chủ nhiệm đề tài dự án có trách nhiệm hoàn chỉnh hồ sơ kết quả thực hiện theo các nội dung đã đƣợc phê duyệt và hợp đồng đã ký kết trình Hội đồng KHCN cấp cơ sở nghiệm thu

Nghiệm thu cấp cơ sở:

Nghiệm thu cấp cơ sở là việc đánh giá kết quả thực hiện đề tài dự án tại

cơ sở, Cơ quan chủ trì thực hiện chịu trách nhiệm đánh giá nghiệm thu theo 2 mức: Đạt và không Đạt và ghi kết quả trong biên bản của Hội đồng nghiệm thu Nếu kết quả là không Đạt, căn cứ biên bản họp Hội đồng nghiệm thu cấp

cơ sở, Cơ quan chủ trì thực hiện làm văn bản báo cáo Sở KH&CN để xử lý

Hoàn chỉnh Hồ sơ báo cáo kết quả nghiệm thu chính thức:

Chủ nhiệm đề tài dự án hoàn chỉnh hồ sở theo góp ý của Hội đồng nghiệm thu cấp cơ sở, trong đó có quyết định và biên bản họp Hội đồng nghiệm thu cấp cơ sở để trình Hội đồng KHCN cấp tỉnh thực hiện nghiệm thu chính thức

Nếu kết quả đánh giá là không Đạt, Sở KH&CN ra thông báo cho Cơ quan chủ trì và Chủ nhiệm đề tài dự án biết và phối hợp với các đơn vị liên quan xử lý theo các quy định hiện hành

Quyết toán tài chính:

Phòng Kế hoạch – Tài chính chủ trì, phối hợp với Phòng Quản lý Khoa học và các đơn vị liên quan tiến hành tổ chức quyết toán kinh phí đề tài dự án

Thanh lý Hợp đồng:

Sau khi giao nộp đầy đủ sản phẩm, quyết toán kinh phí, Sở KH&CN tiến hành thanh lý Hợp đồng nghiên cứu khoa học và phát triển công nghệ hoặc Hợp đồng thực hiện nhiệm vụ KHCN với Cơ quan chủ trì thực hiện

Kiểm tra định kỳ

Nghiệm thu

Quyết toán

Kết thúc, sao lưu

Chức năng rõ: Là chức năng mà người sử dụng có thể nhìn thấy trên giao diện của hệ thống và có thể thực hiện

Chức năng ẩn: Thường là chức năng kỹ thuật, người sử dụng ít nhìn thấy và không được thể hiện trên giao diện của hệ thống

Hiện

R1.3 Backup CSDL Định kỳ sao lưu các dữ liệu để đảm bảo

an toàn cho hệ thống, đây là chức năng

Hiện

R2.2 Cập nhật danh mục Cho phép nhập thông tin về lĩnh vực Hiện

Cho phép cập nhật thông tin về để tài dự

án đang triển khai Hiện

R3.2 Cập nhật thông tin

đề tài dự án đã

nghiệm thu

Cho phép cập nhật thông tin về để tài dự

án đã triển khai Hiện

R4 Báo cáo, thống kê Cho phép người sử dụng lựa chọn tiêu

chí muốn xem, hệ thống sẽ hiển thị báo cáo, thống kê theo từng tiêu chí, thống

kê danh sách đề tài, dự án, báo cáo kiểm tra đề tài, dự án, báo cáo xét duyệt đề tài,

dự án, báo cáo nghiệm thu đề tài, dự án

Hiện

3.2.3 Xác định các tác nhân nghiệp vụ:

Trong hệ thống này chỉ có ba tác nhân nghiệp vụ, đó là người quản trị hệ thống (administrator) và những người dùng hệ thống nghiệp vụ (users) và hệ thống nghiệp vụ mà người dùng muốn dùng

Tác nhân Vai trò/chức năng Kết quả đem lại

1 Người quản trị - Thiết lập các đặc trưng

hệ thống

- Cấp, thu hồi quyền sử dụng hệ thống của người đăng ký

- Tạo trợ giúp để truy nhập có kết quả

- Hệ thống kiểm soát truy cập được thiết lập

- Người dùng có thể truy nhập vào hệ thống

2 Người dùng - Truy nhập hệ thống

- Sử dụng các chức năng của hệ thống

- Tiếp cận được hệ thống nghiệp vụ để sử dụng, sửa đổi, thêm mới thông tin

HT nghiệp vụ - Cung cấp các dữ liệu

cho người quản trị và dịch vụ cho người dùng

- Thống kê, báo cáo: Tạo lập thống kê báo cáo về danh sách đề tài, dự

án, báo cáo xét duyệt, nghiệm thu đề tài dự án

3.3 Những vấn đề và tồn tại trong hệ thống quản lý đề tài NCKH

− Một số chức năng xử lý thông tin chưa chính xác, có thể nhầm lẫn trong quá trình đưa ra số liệu báo cáo thống kê

− Tính bảo mật kém

− Việc sửa đổi thông tin khó khăn, lưu trữ thông tin chậm

3.4 Giải pháp tổng thể công nghệ thông tin cho bài toán đặt ra

3.4.1 Các giải pháp về CSDL

Cơ sở dữ liệu được chọn phải đủ mạnh để quản lý được khối lượng dữ liệu lớn với tần suất truy cập dữ liệu cao, đáp ứng các dịch vụ trực tuyến và đảm bảo các yêu cầu về an toàn dữ liệu Các cơ sở dữ liệu mà có thể đáp ứng các yêu cầu đó là MySQL, SQL server, oracle

3.4.2 Những vấn đề và giải pháp:

Vấn đề Giải pháp

1 Tốc độ xử lý thông tin chậm Lựa chọn cơ sở dữ liệu đủ mạnh để

quản lý được khối lượng dữ liệu lớn với tần suất truy cập dữ liệu cao như SQL

2 Mất thời gian nhiều trong việc tìm

kiếm thông tin

Số hóa thông tin để tăng tốc độ tìm kiếm

3 Cơ sở dữ liệu sơ sài Thiết kế lại CSDL để đáp ứng các

chức năng mới và nâng cao hiệu quả vận hành Sử dụng các cơ sở dữ liệu

có thể đáp ứng các yêu cầu như là MySQL, SQL server, oracle

4 Chưa quan tâm đến bảo mật Tận dụng tối đa các tính năng bảo mật

của các ứng dụng hệ thống như: bảo mật của hệ điều hành

Giải pháp tổng thể để giải quyết bài toán đặt ra là thiết kế lại toàn bộ hệ thống theo hướng đối tượng với các yêu cầu đặt ra

3.4.3 Lựa chọn công cụ nâng cấp

− Ngôn ngữ lập trình: C#, java và javascript

− Cơ sở dữ liệu: MySQL

− Hệ điều hành: WINDOWS