ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Em xin một lần nữa được gửi lời cảm ơn chân thành nhất đến thầy!
Em cũng được xin gửi lời cảm ơn chân thành nhất đến các thầy cô trong
trường Đại học Công nghệ, đặc biệt các thầy cô trong khoa Công nghệ phần mềm.
Các thầy cô đã tận tình dạy dỗ và tạo điều kiện cho em học tập để đạt được kết quả
tốt như ngày hôm nay! Em xin chân thành cảm ơn các thầy cô!
Cuối cùng em xin cảm ơn tới Gia đình, bố mẹ, bạn bè em đã luôn cổ vũ động
viên, tạo điều kiện giúp đỡ em trong quá trình thực hiện khóa luận tốt nghiệp này!
Hà Nội, ngày 11 tháng 05 năm 2009
Sinh viên
Nguyễn Duy Hiệp
ii TÓM TẮT NỘI DUNG KHÓA LUẬN
Qua tìm hiểu thực tế cho thấy, với các tổ chức, cơ quan khác nhau có nghiệp
vụ thực hiện công tác tổ chức xử lý và giao việc không giống nhau. Tuy nhiên về cơ
bản các công ty, doanh nghiệp đều có mô hình quản lý và luồng quy trình nghiệp
Chương 4: Ứng dụng Framework trên để demo một bài toán giao việc
nhỏ.
KẾT LUẬN: Phần này nêu kết quả đạt được của khóa luận và đề xuất
phương hướng nâng cấp và mở rộng ứng dụng đề tài vào thực tiễn trong tương lai.
2.1.2.9. Token Service - 14 -
2.1.2.10. Token Provider - 15 -
2.1.2.11. Identity Attribute Service - 15 -
2.1.2.12. Context Provider - 16 -
v
2.1.3. Mô hình dữ liệu của Higgins - 16 -
2.1.3.1. Các khái niệm dữ liệu cơ bản - 16 -
2.1.3.2. Mục tiêu của mô hình - 18 -
2.2. JhotDraw - 18 -
2.2.1. Giới thiệu khung làm việc JhotDraw - 18 -
2.2.2. Kiến trúc tổng quan về thiết kế của JHotDraw - 19 -
CHƯƠNG 3: - 24 -
XÂY DỰNG FRAMEWORK GIẢI QUYẾT - 24 -
BÀI TOÁN LUỒNG CÔNG VIỆC-WORKFLOW. - 24 -
3.1. Mô tả bài toán quản lý công việc tại một công ty thiết kế đồ nội thất gia đình:- 24 -
3.1.1. Bài toán đặt ra: - 24 -
3.1.2. Sơ đồ hoạt động quản lý công việc tại công ty thiết kế đồ nội thất gia
đình: - 24 -
3.1.3. Mô hình miền lĩnh vực: - 25 -
3.2. Mô tả bài toán quản lý thanh toán tiền lương: - 26 -
3.2.1. Bài toán đặt ra: - 26 -
3.2.2. Sơ đồ tiến trình quản lý hoạt động thanh toán tiền lương: - 27 -
3.2.3. Mô hình miền lĩnh vực: - 30 -
3.3. Mô tả bài toán tổng quát: - 30 -
3.3.1. Các thông tin chung về bài toán luồng công việc: - 30 -
3.3.2. Công tác quản lý bài toán luồng công việc: - 32 -
3.3.3. Sơ đồ tiến trình quản lý hoạt động giao công việc - 32 -
3.3.4. Các yêu cầu xây dựng hệ thống quản lý hoạt động giao công việc - 34 -
3.3.9. Mô tả chi tiết các ca sử dụng - 47 -
3.3.9.1. Gói ca sử dụng Đăng nhập hệ thống - 47 -
3.3.9.2. Gói ca sử dụng Quản lý giải quyết công việc - 49 -
3.3.9.3. Gói ca sử dụng Quản trị tiện ích - 53 -
3.3.9.4. Gói ca sử dụng Báo cáo thống kê - 57 -
3.3.9.5. Gói ca sử dụng Quản trị phân quyền người dùng - 61 -
3.4. Phân tích các lớp: - 63 -
3.4.1. Các lớp giao diện hệ thống: - 63 -
3.4.2. Các lớp thao tác Cơ Sở dữ liệu: - 64 -
3.4.3. Các lớp dịch vụ(Services): - 65 -
3.4.4. Các lớp thực thể: - 66 -
3.5. Áp dụng các mẫu (patterns) trong việc thiết kế cho các ca sử dụng: - 67 -
vii
3.5.1. Gói ca sử dụng Đăng nhập hệ thống - 67 -
3.5.2. Gói ca sử dụng Quản lý giải quyết công việc - 68 -
a. Ca sử dụng Cập nhật công việc - 69 -
b. Ca sử dụng Phân công việc - 72 -
3.5.3. Gói ca sử dụng phục vụ tra cứu, báo cáo, thống kê - 74 -
3.6. Thiết kế một số lớp - 76 -
3.6.1. Lớp giao diện - 76 -
3.6.2. Lớp điều khiển - 78 -
3.6.3. Lớp thực thể - 80 -
KẾT LUẬN - 87 -
TÀI LIỆU THAM KHẢO - 89 -
Tài liệu tiếng Việt - 89 -
Tài liệu tiếng Anh - 89 -
Các trang Web - 90 -
Bộ công cụ - 90 -
Hình 3.4: Mô hình miền lĩnh vực của bài toán quản lý tính tiền lương
Hình 3.5. Mô hình phân cấp quản lý trong doanh nghiệp
Hình 3.6: Sơ đồ tiến trình quản lý hoạt động giao công việc
Hình 3.7: Mô hình khái niệm hệ thống tổ chức và quản lý giao công việc
Hình 3.8: Gói ca sử dụng Đăng nhập hệ thống
Hình 3.9: Gói ca sử dụng Quản lý giải quyết công việc
Hình 3.10: Gói ca sử dụng Quản trị tiện ích
Hình 3.11: Gói ca sử dụng Báo cáo thống kê
Hình 3.12: Gói ca sử dụng Quản trị phân quyền người dùng
Hình 3.13: Biểu đồ lớp thiết kế thực thi ca sử dụng Đăng nhập
Hình 3.14: Biểu đồ lớp thiết kế ca sử dụng Đăng nhập áp dụng mẫu Singleton
Hình 3.15: Biểu đồ lớp thiết kế thực thi ca sử dụng Tạo công việc mới
Hình 3.16. Biểu đồ lớp thiết kế thực thi ca sử dụng Tạo công việc mới áp dụng mẫu
thiết kế Observer
Hình 3.17: Biểu đồ lớp thiết kế thực thi ca sử dụng Sửa nội dung công việc
ix
Hình 3.18: Biểu đồ lớp thiết kế thực thi ca sử dụng Xoá công việc
Hình 3.19: Biểu đồ lớp thiết kế thực thi ca sử dụng Phân công việc
Hình 3.20. Biểu đồ lớp thiết kế thực thi ca sử dụng Phân công việc áp dụng mẫu
thiết kế State
Hình 3.21: Biểu đồ lớp thiết kế thực thi ca sử dụng Chỉ đạo công việc
Hình 3.22: Biểu đồ lớp thiết kế thực thi ca sử dụng Giải quyết công việc
Hình 3.23: Biểu đồ lớp thiết kế thực thi ca sử dụng Báo cáo công việc
Hình 3.24: Áp dụng mẫu thiết kế Composite vào lớp CongViec
DANH MỤC CÁC BẢNG
Bảng 2.1: Các chức năng hệ thống
Ngày nay, với sự phát triển nhanh chóng của khoa học kỹ thuật nói chung và
công nghệ thông tin nói riêng đã mang lại nhiều thành tựu to lớn. Những thành tựu
của khoa học được áp dụng trong tất cả các hoạt động của con người và đã đem lại
những thành công hết sức lớn lao. Ở Việt Nam, hiện nay, các công ty, xí nghiệp và
các doanh nghiệp vừa và nhỏ hầu hết đã trang bị cơ sở hạ tầng về máy tính và kết
nối mạng đã tạo cơ sở cho việc áp dụng những công nghệ mới của mạng máy tính
và internet vào lĩnh vực tìm kiếm, tổ chức và xử lý thông tin phục vụ công tác điều
hành và quản lý sản xuất. Với cơ sở hạ tầng công nghệ thông tin ngày càng phát
triển mở rộng, các tổ chức, doanh nghiệp ngày càng có nhu cầu tin học hoá mọi lĩnh
vực công việc, sản xuất, quản lý,… và mong muốn mọi thông tin quản lý điều hành
sản xuất đều được lưu trữ trên máy tính để có thể tra cứu tìm kiếm dễ dàng và nhanh
chóng mỗi khi có nhu cầu.
- 2 -
Những hoạt động mang tính chất luồng công việc như hoạt động giao việc và
điều hành xử lý việc thực hiện công việc là một hoạt động chủ đạo trong hầu hết các
tổ chức, doanh nghiệp. Tuy nhiên, qua khảo sát thực tế cho thấy, hiện nay việc tổ
chức và quản lý hoạt động giao công việc trong các tổ chức, xí nghiệp chủ yếu thực
hiện trực tiếp bằng miệng và quản lý dựa trên trên giấy tờ. Do đó, để tổ chức và
theo dõi điều hành một công việc thực hiện qua nhiều người, nhiều cấp, trên nhiều
giai đoạn thời gian khác nhau gặp rất nhiều khó khăn. Việc tin học hoá hoạt động
này để có thể tổ chức xử lý, theo dõi hoạt động giao công việc trên hệ thống máy
tính là nhu cầu cấp thiết.
Việc ứng dụng công nghệ thông tin vào tổ chức, quản lý hoạt động giao công
việc là một trong các biện pháp có ý nghĩa thiết thực trong việc áp dụng các thành
tựu khoa học kỹ thuật vào công tác điều hành và quản lý sản xuất trong các doanh
nghiệp.
Từ nhu cầu thực tiễn xã hội và đặc biệt là của đơn vị đang công tác, cùng với
cơ sở khoa học của việc nghiên cứu ứng dụng các mô hình sử dụng lại vào quá trình
hướng đối tượng để phân tích thiết kế bài toán.
– Từ kết quả phân tích và thiết kế tiến hành xây dựng hệ thống dựa trên các
công cụ và môi trường đã lựa chọn.
– Ứng dụng một phần mềm nhỏ sử dụng Framework đã xây dựng.
Nội dung nghiên cứu và thực hiện của luận văn
– Nghiên cứu khái niệm, đặc điểm và phân loại Framework.
– Nếu một số đặc điểm và ứng dụng của một vài Framework sẵn có.
– Tiếp cận một số bài toán cụ thể liên quan đến luồng công việc đó là bài
toán “Quản lý luồng công việc tại Công ty đồ nội thất gia đình” và bài
toán “Quản lý tính tiền lương cho giáo viên”.
– Tiến hành tổng quát hóa từ hai bài toán trên để rút ra bài toán “Luồng
công việc tổng quát”.
– Tiến hành xây dựng các biểu đồ Usecase cho bài toán “Luồng công việc”
đến mức chi tiết nhất.
– Từ các biểu đồ Usecase chi tiết hóa trên tiến hành áp dụng các
mẫu(patterns sẵn có như Singleton, Observer, State, Oposite…) để tổng
quát hóa bài toán, tổng quát hóa các biểu đồ lớp phục vụ cho việc xây dựng
Framework.
– Xây dựng chương trình và tiến hành cài đặt thử nghiệm demo một bài toán
nhỏ.
- 4 -
Chương 1
GIỚI THIỆU CHUNG VỀ FRAMEWORK
Trong một vài thập niên gần đây, việc sử dụng lại phần mềm đã và vẫn là một
vấn đề quan trọng cho các tổ chức phát triển phần mềm. Đầu tiên, phần mềm được sử
dụng lại dưới hình thức là các thư viện hàm API hay các thư viện lớp. Tiếp theo, các
nhà phát triển nhận thấy không chỉ cần sử dụng lại các đoạn mã mà còn cần phải sử
dụng lại cả các thiết kế của phần mềm. Do vậy, đã xuất hiện khái niệm về design
“Một framework là một tập các ký hiệu của các lớp cộng tác mà đạt được cả
các mẫu phạm vi nhỏ và các cơ chế chủ yếu để thực hiện các yêu cầu chung và thiết kế
trong một phạm vi ứng dụng cụ thể”
“Một tập các lớp cộng tác với nhau mà tạo ra một thiết kế có thể sử dụng lại
cho một lớp cụ thể của phần mềm. Một framework cung cấp các hướng dẫn có tính
kiến trúc bằng cách phân chia thiết kế thành các lớp trừu tượng và định nghĩa các đáp
ứng và sự cộng tác của chúng. Một nhà phát triển tùy biến framework thành một ứng
dụng cụ thể bằng cách tạo ra các lớp con và tạo ra các phiên bản của các lớp
framework”
Như vậy, một framework bao gồm một tập các lớp mà các thể hiện của chúng
cộng tác với nhau, được dự định để mở rộng, sử dụng lại cho các ứng dụng cụ thể của
một lĩnh vực. Một họ các vấn đề liên quan, cho phép tổng hợp trong một framework.
Hơn nữa, các framework được biểu diễn thành một ngôn ngữ lập trình, như vậy nó
cung cấp cho việc sử dụng lại cả mã thực hiện và thiết kế.
1.1.2. Cấu trúc của một framework
Một framework hướng đối tượng bao gồm các thành phần sau:
Các tài liệu thiết kế
Các giao diện
Các lớp trừu tượng
Các thành phần
Các lớp
Mối quan hệ giữa các thành phần khác nhau trong một framework được mô tả
như hình vẽ sau:
- 6 - Hình 1.1. Mối quan hệ giữa các thành phần khác nhau trong một framework
Các thành phần của một framework được mô tả như sau:
Các tài liệu thiết kế: thiết kế của một framework có thể bao gồm các lược đồ lớp,
ng
Các thành ph
ầ
n
Các l
ớ
p
ph
ả
n ánh
tri
ể
n khai
tri
ể
n khai
th
ừ
a k
ế
là m
ộ
t ph
trong khi đó chỉ có các ví dụ của các mẫu thiết kế mới được mã hóa. Các mẫu thiết kế
thậm chí mô tả mục đích, việc cân bằng các yếu tố khác để đạt được sự kết hợp tốt
nhất và các kết quả của một thiết kế. Điều này không là một trường hợp cho các
framework. Thứ hai, các mẫu thiết kế là những kiến trúc nhỏ hơn so với các
framework. Do vậy, một framework có thể chứa một số các mẫu thiết kế, nhưng điều
ngược lại là không thể. Do vậy, các mẫu thiết kế không có ảnh hưởng lớn tới kiến trúc
của ứng dụng. Cuối cùng, các framework được chuyên môn hóa hơn so với các mẫu
thiết kế. Các framework luôn luôn liên quan đến một miền ứng dụng cụ thể, trong khi
đó các mẫu thiết kế là chung và có thể được ứng dụng trong bất kỳ miền ứng dụng
nào.
Các ngôn ngữ mẫu khác với framework theo cách mà một ngôn ngữ mẫu
miêu tả: làm như thế nào để tạo ra một thiết kế. Trong khi đó, một framework hướng
đối tượng là một thiết kế. Các ngôn ngữ mẫu bổ sung cho một framework, do chúng có
- 8 -
thể hướng dẫn các kỹ sư phần mềm sử dụng framework như thế nào, và mô tả tại sao
nó lại được thiết kế như vậy.
Một ứng dụng hướng đối tượng khác với một framework ở chỗ, một ứng
dụng mô tả một chương trình thực hiện phức tạp mà thỏa mãn một yêu cầu cụ thể.
Framework đạt được các tính năng của một ứng dụng nhưng nó không thể thi hành bởi
vì nó không bao gồm các tương tác trong trường hợp ứng dụng cụ thể.
Các framework khác với các thư viện lớp ở chỗ: chúng nhắm tới các miền
ứng dụng cụ thể. Trong khi đó, các thư viện lớp cung cấp cho người sử dụng các sự
thực hiện trước của thuật toán. Các thư viện lớp là thụ động, người sử dụng gọi các
phương pháp trong thư viện lớp để thực hiện một số hoạt động. Trong khi đó các
framework định nghĩa khung cho một ứng dụng thực tế và điều khiển luồng điều khiển
trong ứng dụng. Các framework có thể khác so với thư viện lớp, nhưng chúng có thể
sử dụng các thư viện lớp đã có sẵn để thực hiện các thuật toán chung và các cấu trúc
dữ liệu.
Sự đổi chiều của điều khiển
Về đặc điểm thứ nhất, các framework tăng cường khả năng môđun hóa bằng cách
đóng gói các chi tiết thực hiện không chắc chắn đằng sau các giao diện chắc chắn. Khả
năng này giúp cho việc tăng cường chất lượng của phần mềm bằng cách cục bộ hóa
các tác động của những thay đổi về kiến trúc và sự thực hiện. Sự cục bộ hóa này giảm
các nỗ lực được yêu cầu để hiểu và duy trì phần mềm hiện có.
Mặt khác, các giao diện chắc chắn được cung cấp bởi các framework còn tăng
cường khả năng sử dụng lại bằng cách định nghĩa các thành phần chung mà có thể
được áp dụng để tạo ra các ứng dụng mới. Khả năng sử dụng lại của framework thúc
đẩy kiến thức của miền ứng dụng và ưu tiên nỗ lực của các nhà phát triển kinh nghiệm
để tránh việc tạo và làm hợp lệ lại các giải pháp chung cho các yêu cầu của ứng dụng
lặp lại và các thách thức trong thiết kế phần mềm. Việc sử dụng lại các thành phần
thiết kế có thể là một sự cải tiến đáng kể trong sản xuất chương trình, cũng như tốt cho
việc nâng cao chất lượng, tính hiệu quả, độ tin cậy và tính sẵn sàng của phần mềm.
Về khả năng mở rộng, một framework tăng cường khả năng mở rộng bằng cách
cung cấp các điểm nóng tường minh mà cho phép các ứng dụng mở rộng các giao diện
chắc chắn và cách ứng xử của vùng ứng dụng với các sự thay đổi được yêu cầu bởi các
trường hợp của ứng dụng trong một ngữ cảnh cụ thể. Khả năng mở rộng của
framework là cần thiết để đảm bảo các sự điều chỉnh có tính thời gian của các dịch vụ
và tính năng ứng dụng mới.
Cuối cùng, đặc điểm của kiến trúc thời gian chạy của một framework là sự đổi
chiều của điều khiển, thường được gọi là “Nguyên tắc Hollywood”- Đừng gọi cho
chúng tôi, chúng tôi sẽ gọi cho bạn. Kiến trúc này cho phép ứng dụng hợp với các quy
tắc tiêu chuẩn bằng cách điều chỉnh từng bước xử lý, bằng các đối tượng quản lý sự
kiện mà được viện dẫn thông qua cơ chế gửi kích họat lại của framework. Khi các sự
kiện xảy ra, framework gửi lại kích hoạt bằng cách viện dẫn phương pháp móc nối trên
các đối tượng quản lý sự kiện đã được đăng ký trước, cái mà thực hiện việc xử lý ứng
dụng cụ thể trên các sự kiện. Đổi chiều điều khiển cho phép framework định nghĩa
một tập các phương pháp ứng dụng cụ thể để đáp ứng với các sự kiện ở bên ngoài.
ContextProviders thường hoạt động như “cầu nối” giữa framework với hệ thống
sẵn có. “Cầu nối” này cung cấp kết nối đến kho lưu trữ như LDAP server, hệ thống
quản lý nhận dạng, diễn đàn, và các mạng xã hội. Nó cũng có thể kết nối với các mạng
giao tiếp như email, instance message,…
Kiến trúc dịch vụ của Higgins framework cho phép ứng dụng mở rộng phạm vi
truy cập đến các hệ thống ngoài mà không cần phải thay đổi bản thân ứng dụng.
2.1.2. Các thành phần của Higgins
Higgins gồm 12 thành phần: Higgins Browser Extension, RP Enablement, I-Card
Manager, RP Protocol Support, ISS Client UI, I-Card Selector Service (ISS), I-Card
Registry, I-Card Provider, Token Service, Token Provider, Identity Attribute Service
(IdAS), Context Provider được tổ chức như hình 3.2.
Hình 2.1. Higgins Trust Framework
- 12 - Chúng ta sẽ lần lượt tìm hiểu các thành phần của Higgins framework.
2.1.2.1. Browser Extension
Higgins Browser Extension là một mở rộng trình duyệt Firefox viết bằng
javascript. Khi Higgins Extension được cài đặt và trình duyệt duyệt đến một site đối
tác, Higgins Browser Extension quản lý quyền truy cập và các tương tác liên quan đến
định danh tương tác giữa site đối tác và dịch vụ Higgins.
2.1.2.2. RP Enablement
RP Enablement là tập hợp các thành phần sử dụng để tạo site đối tác. Các thành
phần con tách biệt trong mục này sẽ được tạo ra để hoạt động như các dịch vụ tin
tưởng cho lớp các giao thức khác nhau.
Hình 2.2. Kiến trúc của Higgins
Thành phần I-Card Registry quản lý tập các I-Card của người dùng. Mỗi I-Card
được tạo và quản lý bởi một I-Card Provider và thi hành giao diện I-Card Interface.
Các giao diện của I-Card Registry có hai phần:
- Một giao diện để quản lý I-Card như thêm mới, xóa bỏ và duyệt các I-Card.
- Tập các giao diện thi hành bởi I-Card Provider.
2.1.2.8. I-Card Provider
I-Card Provider chịu trách nhiệm tạo và quản lý các I-Card thi hành giao diện I-
Card Interfaces. Thành phần này cũng chịu trách nhiệm nhập I-Card từ các loại dữ liệu
card khác nhau. Lưu ý là I-Card Provider chỉ chịu trách nhiệm nhập dữ liệu, việc xuất
dữ liệu được thi hành bởi chính lớp I-Card.
Higgins framework hiện đang thi hành các I-Card Provider sau:
- CardSpace Managed I-Card Provider
- CardSpace Personal I-Card Provider
- URI Managed I-Card Provider
- URI Personal I-Card Provider
2.1.2.9. Token Service
Token Service tạo nhận dạng số dùng được cho đối tác từ dữ liệu yêu cầu. Dữ
liệu yêu cầu có thể truyền bởi I-Card Provider đến Token Service sau đso đến Token
Provider hoặc Token Issuer có thể nhận dữ liệu từ I-Card Provider.
Copyright: Tài liệu đại học ©