Vận dụng các mẫu thiết kế để giải quyết bài toán quản lý theo công nghệ hướng đối tượng

Nhìn chung, một mẫu là mô tả các vấn đề thường xuyên xuất hiện trong thiết kế, triển khai phần mềm và các giải pháp cho nó theo cách có thể sử dụng lại được.. Kiến trúc phần mềm hướng mẫ

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Ệ

Nguyễn Đức Toàn

VẬN DỤNG CÁC MẪU THIẾT KẾ ĐỂ GIẢI QUYẾT BÀI TOÁN QUẢN LÝ THEO CÔNG

NGHỆ HƯỚNG ĐỐI TƯỢNG

Ngành: Công nghệ thông tin

CÁC THUẬT NGỮ VIẾT TẮT

Abstract factory pattern Mẫu chế tạo trừu tượng

Smart reference proxy Kiểm soát các đối tượng bổ sung

Copy_ on_write proxy Cho phép ghi vaò đĩa mọi lúc

MỤC LỤC

CHƯƠNG I 6

MẪU THIẾT KẾ 6

1.1 Mẫu thiết kế là gì? 6

1.2 Lịch sử các mẫu 7

1.3 Các thành phần của mẫu thiết kế 8

1.3.1 Tên mẫu 8

1.3.2 Vấn đề 9

1.3.3 Giải pháp 9

1.3.4 Hệ quả 9

1.4 Mô tả mẫu thiết kế 9

1.4.1 Tên gọi và phân loại 9

1.4.2 Mục đích 10

1.4.3 Các tên gọi khác 10

1.4.4 Lý do sử dụng 10

1.4.5 Khả năng áp dụng 10

1.4.6 Cấu Trúc 10

1.4.7 Kết Quả 10

1.4.8.Triển Khai 11

1.5 Vai trò của mẫu trong phát triển phần mềm 11

1.6 Mẫu thiết kế và kỹ nghệ phần mềm 12

1.6.1 Những mẫu thiết kế trong vòng đời phát triển phần mềm 12

1.6.2 Vòng đời mẫu 13

1.7 Đặc điểm chung của mẫu 14

CHƯƠNG 2 15

CÁC LOẠI MẪU THIẾT KẾ 15

2.1 Phân loại mẫu 15

2.2 Mẫu thiết kế với từng bài toán 15

2.3 Mẫu chế tạo (Factory Pattern) 16

2.3.1 Định nghĩa 16

2.3.2 Đặc điểm 17

2.3.3 Phân loại 17

2.3.4 Một biểu đồ lớp bằng UML của mẫu chế tạo 18

2.4 Mẫu chế tạo trừu tượng (Abstract Factory Pattern) 18

2.4.1 Định nghĩa 18

2.4.2 Thiết kế động với mẫu chế tạo trừu tượng 18

2.4.3 Biểu đồ lớp bằng UML của mẫu 19

2.5 Mẫu đơn chiếc (Singleton Pattern) 19

2.5.1 Định nghĩa 20

2.5.2 Lợi ích 20

2.5.3 Trường hợp sử dụng 20

2.5.4 Cách thực hiện 21

2.5.5 Ứng dụng của mẫu đơn chiếc 21

2.5.6 Nhận xét 22

2.6 Mẫu uỷ nhiệm (Proxy Pattern) 22

2.6.1 Định nghĩa 22

2.6.2 Phân loại 22

2.6.3 Đặc điểm chung 24

2.6.4 Biểu đồ lớp bằng UML của mẫu 24

2.7 Mẫu thích nghi (Adapter Pattern) 24

2.7.1 Định nghĩa 24

2.7.2 Đặc điểm 25

2.7.3 Phạm vi ứng dụng 25

Luận văn thạc sỹ Nguyễn Đức Toàn

3

2.7.4 Biểu đồ lớp bằng UML của mẫu 25

2.8 Sơ đồ mối liên kết các mẫu thiết kế 26

CHƯƠNG 3 27

ỨNG DỤNG MẪU 27

Phân tích, thiết kế hệ thống “ Quản lý khám chữa bệnh “ 27

3.1 Mô tả bài toán 27

3.1.1 Bài toán 27

3.1.2 Các vấn đề cần giải quyết 27

3.2 Phát triển hệ thống 28

3.2.1 Các chức năng của hệ thống 28

3.2.2 Các khái niệm và mô hình lĩnh vực 29

3.3 Xác định các tác nhân, các ca sử dụng và mô tả các ca sử dụng 35

3.3.1 Xác định các tác nhân 35

3.3.2 Xác định các ca sử dụng 39

3.3.3 Mô hình ca sử dụng 44

3.3.4 Mô tả chi tiết ca sử dụng 48

3.4 Phân tích hệ thống 59

3.4.1 Ca sử dụng cập nhật thông tin phòng khám (Clinic) 59

3.4.2 Ca sử dụng cập nhật thông tin loại phòng khám (Provider Type) 61

3.4.3 Ca sử dụng cập nhật loại quyền sử dụng (BenefitScheme) 63

3.4.4 Ca sử dụng cập nhật thanh toán theo đợt tới từng công ty (Invoice) 67

3.4.5 Ca sử dụng cập nhật thông tin khám (EmpVisit) 70

3.5 Biểu đồ lớp 73

3.5.1 Áp dụng mẫu Uỷ nhiệm (Proxy) 73

3.5.2 Áp dụng mẫu tạo (Factory) 74

3.5.3 Áp dụng mẫu đơn chiếc (Singleton) 75

3.5.4 Biểu đồ lớp khi chưa áp dụng mẫu 77

3.5.5 Biểu đồ lớp sau khi áp dụng mẫu 78

3.6 Mô tả chi tiết các đối tượng 79

3.6.1 ClinicVO 79

3.6.2 ClinicRdb 79

3.6.3 ProviderTypeVO 79

3.6.4 ProviderTypeRdb 80

3.6.5 DiagnosisVO 80

3.6.6 DiagnosisRdb 80

3.6.7 DrugVO 80

3.6.8 DrugRdb 81

3.6.9 LabVO 81

3.6.10 LabRdb 81

3.6.11 XRayVO 82

3.6.12 XRayRdb 82

3.6.13 GroupVO 82

3.6.14 GroupRdb 83

3.6.15 UserVO 83

3.6.16 UserRdb 83

3.6.17 UserRoleTypeVO 84

3.6.18 UserRoleTypeRdb 84

3.6.19 UserRoleVO 84

3.6.20 UserRoleRdb 84

3.6.21 CompanyVO 85

3.6.22 CompanyRdb 85

3.6.23 BenefitSchemeVO 85

3.6.24 BenefitSchemeRdb 86

3.6.25 BSInPanelVO 86

Luận văn thạc sỹ Nguyễn Đức Toàn

5

3.6.26 BSInPanelRdb 87

3.6.27 VisitDisplayVO 87

3.6.28 VisitDisplayRdb 87

3.6.29 BatchVO 88

3.6.30 BatchRdb 88

3.6.31 InvoiceVO 88

3.6.32 InvoiceRdb 89

3.6.33 PaymentAdviceVO 89

3.6.34 PaymentAdviceRdb 89

3.6.35 EmployeeVO 89

3.6.36 EmployeeRdb 90

3.6.37 DependantVO 90

3.6.38 DependantRdb 91

3.6.39 EmpVisitVO 91

3.6.40 EmpVisitRdb 92

3.6.41 DrugVisitVO 92

3.6.42 DrugVisitRdb 92

3.6.43 LabVisitVO 93

3.6.44 LabVisitRdb 93

3.6.45 XRayVisitVO 93

3.6.46 XRayVisitRdb 93

3.7 Cấu hình phần cứng 94

3.8 Thiết kế giao diện 95

KẾT LUẬN 98

CHƯƠNG I MẪU THIẾT KẾ

1.1 Mẫu thiết kế là gì?

Nhìn chung, một mẫu là mô tả các vấn đề thường xuyên xuất hiện trong thiết kế, triển khai phần mềm và các giải pháp cho nó theo cách có thể sử dụng lại được Những mẫu thiết kế có ý nghĩa thực tế tốt, chúng là phương tiện thiết kế để làm tài liệu và để truyền đạt kiến thức, những kinh nghiệm của các chuyên gia cho những người mới học

Mẫu còn mô tả một giải pháp chung đối với một vấn đề nào đó trong thiết kế thường được “lặp lại” trong nhiều dự án Nói một cách khác, một mẫu có thể được xem như một

“khuôn dạng” có sẵn có thể áp dụng được cho nhiều tình huống khác nhau để giải quyết một vấn đề cụ thể Trong bất kỳ hệ thống phần mềm hướng đối tượng nào, chúng ta cũng

có thể bắt gặp các vấn đề lặp lại

a Các mẫu phân tích

Các mẫu phân tích (Analysis Patterns) là để hiểu các vấn đề từ các yêu cầu bên ngoài Martin Fowler đã định nghĩa các mẫu phân tích như “ Nhóm những khái niệm được đại diện cho một cấu trúc chung trong các mô hình nghiệp vụ”

b Các mẫu kiến trúc

Các mẫu kiến trúc (Structual Patterns) mô tả sơ đồ tổ chức với cấu trúc cơ bản cho hệ thống phần mềm Nó cung cấp một tập hợp các định nghĩa về các hệ thống con hoặc các thành phần Đồng thời chỉ rõ trách nhiệm của các thành phần đó cùng các qui tắc và các nguyên tắc cho việc tạo lập mối quan hệ giữa chúng Những mẫu kiến trúc là phương tiện của kiến trúc, cung cấp tài liệu cho những hệ thống hỗn tạp và phức tạp Do đó nó giúp quản lý các ứng dụng phức tạp

c Mẫu thiết kế

Mẫu thiết kế (Design pettern) cung cấp một sơ đồ để làm mịn các hệ thống con, các thành phần của một hệ thống phần mềm hoặc mối quan hệ giữa chúng Nó mô tả một cấu trúc, xác định những thành phần truyền thông nhằm giải quyết một vấn đề thiết kế chung trong một ngữ cảnh đặc biệt Mẫu chiến lược, mẫu trạng thái và mẫu uỷ nhiệm là những

ví dụ cho phạm trù này

Luận văn thạc sỹ Nguyễn Đức Toàn

7

Thành ngữ (idoms) là một loại mẫu đặc biệt mức thấp dành cho một ngôn ngữ lập trình Một thành ngữ miêu tả làm sao để thực hiện những khía cạnh đặc biệt của thành phần hoặc mối quan hệ giữa chúng khi sử dụng những đặc tính của một ngôn ngữ lập trình đã cho như: C++, Java hoặc Smalltalk

Các mẫu là các kinh nghiệm thiết kế đã được kiểm chứng Phần lớn những mẫu được tìm ra hoặc được làm tài liệu là các mẫu được xây dựng lên từ nhiều dự án đã được tiến hành trong thực tế hơn là những mẫu được sáng chế ra Các mẫu là cách mô tả ngắn gọn

và hiệu quả để truyền đạt những khái niệm và kinh nghiệm của các nhà phát triển từ các vấn đề thực tế

độ trừu tượng từ kiến trúc của một thành phố đến các thiết kế phòng Kiến trúc sư đã thành lập khung mẫu miêu tả cơ bản của một mẫu như một giải pháp của vấn đề ở mức ngữ cảnh Ông đã phát triển một nguyên mẫu từ các mẫu dùng trong công việc của ông về kiến trúc

Kent Beck và Ward Cunningham[1] đã rất say mê áp dụng ý tưởng của Alexander để phát triển các mẫu phần mềm Họ đã tập hợp các mẫu đầu tiên nói về đặc tả giao diện người dùng Kent tập trung vào các thành ngữ cho Smalltalk và Ward diễn đạt kinh nghiệm của mình bằng các hệ thống nghiệp vụ (hệ thống kế toán)

Erich Gamma đã xuất bản ấn phẩm đầu tiên về vấn đề sử dụng các mẫu trong phát triển phần mềm năm 1991 Cuốn sách được viết ở Đức, nhưng cuốn sách này không được chú ý nhiều Bruce Anderson là một trong những nhà lãnh đạo trong cộng đồng mẫu Ông thành lập một ngân hàng mẫu ở OOPSLA vào đầu những năm 1990 Jim Coplien miêu tả thành ngữ trên C++ trong quyển lập trình C++ tiên tiến Theo một cách nào đó, những thành ngữ này có liên quan tới ý tưởng của những giải pháp cung cấp tài liệu cho những vấn đề thường xuyên Một nhóm có tên là Hillside Group được hình thành nhằm khai thác sâu hơn những ý tưởng này và thúc đẩy sử dụng mẫu trong quá trình phát triển phần mềm

Họ xây dựng mẫu nhằm dẫn dắt và hỗ trợ những thành viên mới trong cộng đồng mẫu Nhóm này được hình thành đầu tiên với tên PLOP vào năm 1994

Những kiến thức cơ bản của quá trình phát triển mẫu được Gang of Four (GoF) xuất bản trong cuốn” những mẫu thiết kế” Những phần tử của phần mềm hướng đối tượng đã được giới thiệu và được miêu tả dễ hiểu với mẫu thiết kế hướng đối tượng Gamma, Helm, Johnson, and Vlissides' work là đại diện cho lĩnh vực phân loại những giải pháp thiết kế, và việc sử dụng thông dùng bên trong mẫu hướng đối tượng Họ xây dựng một tập hợp gồm 23 mẫu chia làm 3 phạm trù: theo hành vi, theo cấu trúc, và tạo sinh

Peter Coad gần đây cũng nghiên cứu về các mẫu hướng đối tượng Trong đó, ông đã

mô tả 7 loại mẫu cơ bản trong phân tích và thiết kế hướng đối tượng Ông làm việc dựa trên các mẫu, tức là nhờ vào việc phân tích một ứng dụng của miền đã được đưa ra và sử dụng công nghệ hướng đối tượng để xây dựng các ứng dụng Douglas Schmidt cũng là một người dẫn dắt những người mới tham gia vào lĩnh vực dùng mẫu Ông là tác giả của rất nhiều mẫu trong lĩnh vực các hệ thống truyền thông và các ứng dụng phân tán

Douglas Schmidt đã làm việc trên mẫu về các ứng dụng cho vấn đề phát triển khung làm việc Ông đã tạo ra các yếu tố cơ bản của cấu trúc vào trong các siêu mẫu được sử dụng để phát triển các khung làm việc và điền địa chỉ Hot - Sport và Hooks/templates tiếp cận trong việc phát triển khung làm việc

Kiến trúc phần mềm hướng mẫu: Một hệ thống mẫu còn được gọi “Gang of five”, hướng vào việc sử dụng các mẫu ở mức kiến trúc trong quá trình phát triển phần mềm Nhiều tác giả phân loại các mẫu phần mềm thành mẫu kiến trúc, mẫu thiết kế và thành ngữ Hầu hết sự đóng góp của họ được hướng về khía cạnh mẫu kiến trúc Những quyển sách của họ cùng với những quyển sách của Gof đánh dấu điểm bắt đầu của những người mới trong cộng đồng mẫu

1.3 Các thành phần của mẫu thiết kế

Mỗi mẫu thiết kế (Design Pattern) trước tiên mô tả một bài toán mà ta gặp nhiều lần, rồi mô tả những yếu tố căn bản nhất để giải quyết bài toán theo cách mà ta có thể áp dụng lại nhiều lần Dựa trên mô tả như trên về các mẫu thiết kế, ta thấy chúng bao gồm những thành phần cơ bản sau:

1.3.1 Tên mẫu

Tên mẫu (Pattern Name) là tên gọi qua đó ta có thể hình dung được bài toán cần giải

quyết và giải pháp thực hiện hay kết quả Việc đặt tên mẫu thiết kế cho phép mô tả các bài toán và giải pháp một cách ngắn gọn Nó tạo thành một ngôn ngữ trong cộng đồng những người thiết kế Ví dụ, khi nói đến mẫu thiết kế "Facade " (bề mặt), ta hình dung ngay đến

Luận văn thạc sỹ Nguyễn Đức Toàn

9

mô hình thiết kế một đối tượng với vai trò “interfacce” (giao diện) của một tập các thành phần nhỏ hơn

1.3.2 Vấn đề

Vấn đề (Problem) cho phép xác định trong trường hợp nào thì áp dụng mẫu thông qua

mô tả bài toán và ngữ cảnh của bài toán đó

1.3.3 Giải pháp

Giải pháp (Solution) mô tả những thành phần tạo nên mẫu thiết kế cùng mối quan hệ, vai trò và cách thức phối hợp giữa chúng Giải pháp không đề cập đến cách thức thiết kế hay thực hiện cụ thể nào vì nó được áp dụng trong rất nhiều tình huống khác nhau Thay vào đó, giải pháp của mẫu thiết kế được mô tả với tính khái quát cao, với cách thức tổ chức chung nhất của các thành phần trong việc giải quyết bài toán

1.3.4 Hệ quả

Hệ quả (Consequences) cho thấy việc áp dụng các giải pháp để giải quyết những vấn

đề có hiệu quả hay không Nói cách khác, hệ quả đặt ra cho bạn cách lựa chọn, từ đó bạn

có thể xem xét lựa chọn nào là phù hợp nhất, tốt nhất

Ngoài ra, một số tác giả (như Craig Larma, Kent Beck và Ward Cunningham) còn bổ sung thêm một số thành phần khác nữa

1.4 Mô tả mẫu thiết kế

Cách thức mô tả góp phần quan trọng trong việc hiểu và áp dụng mẫu thiết kế Những tiêu chí cơ bản trong mô tả các mẫu thiết kế bao gồm: đơn giản, chính xác và đầy đủ Như vậy, cần có một khuôn dạng mô tả thích hợp để đáp ứng các mẫu thiết kế khác nhau Đồng thời, khuôn dạng này cũng cho phép người xây dựng và người sử dụng có chung một cách nhìn và tiếp cận đối với mẫu thiết kế

Theo GOF (Gang of Five), một mẫu thiết kế được mô tả với các nội dung sau:

1.4.1 Tên gọi và phân loại

Tên gọi cần chuyển tải những yếu tố căn bản nhất của mẫu thiết kế, thường tên gọi chỉ bao gồm một đến hai từ Hơn nữa, tên gọi của mẫu thiết kế sẽ trở thành một phần trong bộ

từ vựng để trao đổi về các mô hình thiết kế nên cần được cân nhắc và lựa chọn kỹ lưỡng Việc phân loại cho phép xác định mẫu thiết kế thuộc nhóm nào Theo GOF, các mẫu thiết

kế đựơc phân thành ba nhóm: nhóm mẫu tạo sinh (creational), nhóm cấu trúc (structural)

và nhóm hành vi (behavioral)

1.4.2 Mục đích

Mẫu thiết kế cho biết:

- Mẫu thiết kế có chức năng gì

- Lý do và mục đích của mẫu thiết kế

- Mẫu thiết kế giải quyết bài toán cụ thể nào

1.4.3 Các tên gọi khác

Một mẫu thiết kế có thể có nhiều tên gọi khác nhau tuỳ theo cách gọi tên của người thiết kế Ví dụ, với mẫu thiết kế Factory Method, người ta có thể gọi nó với tên Virtual Constructor Cả hai tên gọi trên đều đúng để chỉ mô hình thiết kế với việc tạo ra một giao diện trong việc khởi tạo các đối tượng và việc tạo đối tượng cụ thể thì do các lớp triển khai giao diện này thực hiện

Mẫu cho biết:

- Thiết kế mẫu này có tác động thế nào tới mục tiêu thiết kế

Luận văn thạc sỹ Nguyễn Đức Toàn

11

- Những yếu tố của kiến trúc hệ thống có thể thay đổi mà không ảnh hưởng đến thiết

kế mẫu

1.4.8.Triển Khai

Mẫu cho biết :

- Những khó khăn, những dấu hiệu hoặc những công nghệ cần phải lưu ý khi triển khai mô hình

- Có những yếu tố phụ thuộc vào từng ngôn ngữ cụ thể hay không

1.5 Vai trò của mẫu trong phát triển phần mềm

Khi sự phức tạp của các hệ thống phần mềm gia tăng, chúng ta tìm kiếm cách tiếp cận

để làm đơn giản hoá sự phát triển của các ứng dụng phần mềm Các mẫu thiết kế hứa hẹn sớm đem lại lợi ích của việc tái sử dụng trong vòng đời phát triển Để có được lợi ích trong quá trình triển khai những giải pháp thiết kế đã được khẳng định này, chúng ta cần phải định nghĩa các kỹ thuật cấu thành thiết kế để xây dựng ứng dụng sử dụng các mẫu Những mô hình thiết kế linh hoạt cần phải được phát triển để hỗ trợ cho kỹ thuật này Tái sử dụng phần mềm trong các ứng dụng thực tế là một nhiệm vụ khó Nó thực sự quan trọng để giảm bớt công sức phát triển và đảm bảo chất lượng phần mềm cao hơn Các mẫu thiết kế có tác dụng thúc đẩy trong việc sử dụng lại các sản phẩm trong pha thiết

kế, bởi vì chúng cung cấp một tập hợp các từ vựng thông thường cho thiết kế Chúng còn cung cấp một ngữ nghĩa giúp cho việc hiểu các thiết kế và chúng chỉ ra các khối xây dựng

từ các ứng dụng phức tạp hơn đã được xây dựng Sự tập hợp từ nhiều danh mục mẫu sẵn

có đã khuyến khích hình thành các ý tưởng xa hơn về việc làm sao để sử dụng những giải pháp có thể tin cậy được để phát triển các ứng dụng Các nhà nghiên cứu và thiết kế có kinh nghiệm đã mất nhiều công sức trong việc làm tài liệu có chất lượng cao trong thiết

kế phần mềm như những mẫu thiết kế Trong khi có rất nhiều sự chú ý được quan tâm để tìm và làm tài liệu cho các mẫu thiết kế, thì các kỹ thuật để triển khai và gắn kết các giải pháp thiết kế đã được chứng minh này vẫn còn thiếu các hệ thống hỗ trợ

Thiết kế các ứng dụng bằng cách triển khai có hệ thống các mẫu thiết kế không phải

là một quá trình bình thường Mặc dù cách tiếp cận cho thiết kế sử dụng công nghệ mẫu cấu thành đã được đề xướng, nhưng còn thiếu tiến trình hệ thống làm chúng nhanh tới đích

1.6 Mẫu thiết kế và kỹ nghệ phần mềm

1.6.1 Những mẫu thiết kế trong vòng đời phát triển phần mềm

Nhiều người thiết kế ứng dụng được khuyến khích để dùng những thành phần có thể

sử dụng lại nhằm giảm công sức và thời gian phát triển phần mềm Mức độ sử dụng lại được quyết định bởi những nhà tham gia phát triển ứng dụng Một quyết định thiết kế đơn giản như việc sử dụng lại một thư viện lớp hoặc một giao diện lập trình ứng dụng(API) là những thứ thông thường nhất và dễ sử dụng Một mức phức tạp hơn của sử dụng lại là sử dụng lại những mẫu và những khung làm việc, trong đó người thiết kế có sẵn một tập hợp rất nhiều mẫu với nội dung rộng hơn rất nhiều so với những quyết định thiết kế cần thiết Bất kỳ một vòng đời phát triển phần mềm nào cũng bao gồm một số pha phát triển:

phân tích, thiết kế, trình bày chi tiết thiết kế, triển khai và kiểm thử Các mẫu có thể đóng

một vai trò quan trọng trong một hoặc trong mọi pha của vòng đời phát triển phần mềm Tuy nhiên, các mẫu đầu tiên được giới thiệu chỉ nhằm phục vụ vấn đề sử dụng lại trong pha thiết kế Nhưng rất nhiều nhà triển khai đã tận dụng lợi ích của mẫu trong tất cả các pha của vòng đời phát triển phần mềm

Các mẫu thiết kế sẽ tồn tại rất lâu Càng nhiều nhà thiết kế và nhà phát triển dùng các mẫu thì họ càng được thuyết phục rằng, chúng phải là một quá trình bộ phận được hợp thành từ bất kỳ một tiến trình phát triển phần mềm nào Tính đa dạng của các ứng dụng với các mẫu được sử dụng và sự hữu ích của chúng là bằng chứng cụ thể về tính bền vững của những mẫu thiết kế

Phiên bản tiếp theo của các ứng dụng hướng đối tượng và các khung làm việc sẽ chứa các mẫu rõ ràng Các mẫu cũng sẽ tiếp tục được sử dụng để làm tài liệu mẫu và nội dung của các khung làm việc Những miền và những chủ đề chính khác cũng đem lại nhiều lợi ích từ quá trình tập hợp các mẫu nhỏ cụ thể như sau:

a Phân phối các đối tượng

Những ứng dụng tính toán song song và các đối tượng được nối mạng đã làm được tài liệu trong thập niên qua

b Các hệ thống thời gian thực và các hệ thống nhúng

Một số lượng lớn các hệ thống tính toán gia tăng là hệ thống nhúng Chúng bao gồm các hệ thống điều khiển tự động, các ứng dụng trong ô tô, các phần mềm điều khiển cho các thiết bị tự động hoá nhà máy và các thiết bị tính toán cầm tay Nhiều hệ thống trong

Luận văn thạc sỹ Nguyễn Đức Toàn

1.6.2 Vòng đời mẫu

Hình 1.1 Minh hoạ vòng đời của mẫu Trên đây (hình 1.1) là vòng đời để tăng tính tin cậy của các mẫu đã được chọn cho các thành phần thiết kế Công việc này cho thấy có sự lặp đi lặp lại có cải tiến được phát triển trên mẫu trước khi nó được làm tài liệu cho việc sử dụng lại

Các tác giả

Cộng đồng xây dựng mẫu

Người dùng mẫu

1.7 Đặc điểm chung của mẫu

Mẫu được hiểu theo nghĩa tái sử dụng ý tưởng hơn là mã lệnh: Mẫu cho phép các nhà

thiết kế có thể cùng ngồi lại với nhau và cùng giải quyết một vấn đề nào đó mà không phải mất nhiều thời gian bàn cãi Trong rất nhiều trường hợp, dự án phần mềm thất bại là

do các nhà phát triển không có được sự hiểu biết chung trong các vấn đề kiến trúc phần mềm Ngoài ra, mẫu cũng cung cấp những thuật ngữ và khái niệm chung trong thiết kế Nói một cách đơn giản, khi đề cập đến một mẫu nào đấy, bất kỳ ai có hiểu biết về mẫu đó đều có thể nhanh chóng hình dung ra “bức tranh “ của giải pháp Và cuối cùng, nếu áp dụng mẫu hiệu quả thì việc bảo trì phần mềm cũng được tiến hành thuận lợi hơn, nắm bắt kiến trúc hệ thống nhanh hơn

Mẫu hỗ trợ tái sử dụng kiến trúc và mô hình thiết kế phần mềm theo qui mô lớn Ở đây chúng ta cần phân biệt mẫu thiết kế với khung làm việc Khung làm việc hỗ trợ tái sử dụng mô hình thiết kế và mã nguồn ở mức chi tiết hơn Trong khi đó mẫu thiết kế được vận dụng ở mức tổng quát hơn, giúp các nhà phát triển hình dung và ghi nhận các cấu trúc tĩnh và động cũng như quan hệ tương tác giữa các giải pháp trong quá trình thiết kế ứng dụng đối với các lĩnh vực riêng biệt

Mẫu đa tương thích: Mẫu không phụ thuộc vào ngôn ngữ lập trình, công nghệ hoặc các nền tảng lớn như J2W của Sun hay Microsofft, NET framework

Tiềm năng ứng dụng của mẫu là rất lớn Các thiết kế dựa trên mẫu được sử dụng khá nhiều ở các phần mềm mã nguồn mở Trong các dạng ứng dụng này, có thể dễ dàng nhận

ra một số tên lớp chứa các tiền tố hoặc hậu tố như Factory, Proxy, Adapter

CHƯƠNG 2 CÁC LOẠI MẪU THIẾT KẾ

2.1 Phân loại mẫu

Mẫu được phân loại ra làm 3 nhóm chính sau đây:

a Các mẫu tạo sinh

Các mẫu tạo sinh (Creational Pattern) gồm: Factory, Abstract Factory, Singleton, Prototype, Builder… Liên quan đến quá trình khởi tạo đối tượng cụ thể từ một định nghĩa trừu tượng(abstract class, interface)

b Các mẫu cấu trúc

Các mẫu cấu trúc (Structural Pattern) gồm: Proxy, Adapter, Wrapper, Bridge, Facade,

Flyweight, visitor… Liên quan đến vấn đề làm thế nào để các lớp và đối tượng kết hợp với nhau tạo thành các cấu trúc lớn hơn

c Các mẫu hành vi

Các mẫu hành vi (Behavioral pattern) observer, state, command, Interator…Mô tả cách thức để các lớp hoặc các đối tượng có thể giao tiếp với nhau

2.2 Mẫu thiết kế với từng bài toán

Trong quá trình thiết kế, chúng ta luôn gặp những sự kiện đó là sự phụ thuộc lẫn nhau giữa các đối tượng trong hệ thống Sự phụ thuộc này đôi khi cho phép ta giải quyết các vấn đề trước mắt thật nhanh chóng Nhưng phần mềm được tạo ra thường không chỉ

để giải quyết các vấn đề trước mắt, nó luôn thay đổi vì các yêu cầu thay đổi chức năng không chỉ là cập nhật chức năng đã có mà còn thêm mới các chức năng mới

Mỗi khi phần mềm cần thêm một yêu cầu mới, chúng ta thường phải thiết kế lại, thậm chí cài đặt lại và kiểm thử lại xem các chức năng mới thêm vào có tương thích với các chức năng cũ hay không, và các chức năng cũ có cần thay đổi để phù hợp với các chức năng mới hay không những điều đó làm chúng ta mất nhiều thời gian và tiền bạc Vì thế, mục tiêu của bất kì nhà thiết kế nào là có thể dự đoán được các thay đổi trong tương lai của phần mềm Trên cơ sở đó, thiết kế một hệ thống sao cho bất kỳ sự thay đổi nào trong tương lai cũng không làm ảnh hưởng đến những phần còn lại của hệ thống

Một phần mềm không kiên định, phức tạp hoá và có quá nhiều các thành phần lệ thuộc vào nhau, cần phải thiết kế lại đều do xuất phát từ những nguyên nhân sau:

- Các đối tượng đều được tạo ra từ các lớp cụ thể thay vì sử dụng các lớp ảo (interface) làm cho việc thay đổi và cập nhật trong tương lai sẽ trở lên phức tạp Vì vậy, sử dụng các mẫu: Abstract Factory, Factory Method, Prototype

- Phần mềm phụ thuộc vào phần cứng hệ điều hành Một chương trình được thiết kế trên Windows sẽ chạy không hiệu qủa trên Linux vì các hàm APIs và platform hoàn toàn khác biệt nhau Do đó, cần phải thiết kế chương trình có thể linh hoạt chuyển đổi không phụ thuộc vào bất kỳ hệ điều hành, phần cứng nào Vì vậy, sử dụng các mẫu: Abstrac Factory, Bridge

- Phần mềm phụ thuộc vào chi tiết của đối tượng như cách thức hoạt động như thế nào, được lưu trữ tại stack nào, thực thi ra sao, có ràng buộc quan hệ nào không Nếu Client biết quá nhiều về đối tượng mà nó gọi tới thường luôn có xu hướng thay đổi nếu đối tượng thay đổi Chính vì thế, chúng ta cần giấu đi những thông tin không cần thiết của đối tượng với client Vì vậy, sử dụng Abstract Factory, Bridge, Memento, proxy

- Cách giải quyết một bài toán nào đó tại thời điểm này có thể chưa tốt và nó phải cần được mở rộng thay thế hoặc tối ưu hoá Việc phụ thuộc vào một vấn đề cụ thể thường làm thay đổi các đối tượng liên quan, thậm chí gây ra sự thay đổi dây chuyền Do đó, các thuật toán càng độc lập bao nhiêu thì càng hạn chế được sự ràng buộc bấy nhiêu

Vì vậy sử dụng các mẫu: Builder Iterator, Strategy, Template, Method, Visitor

- Phần mềm phụ thuộc chặt chẽ giữa các đối tượng Do lớp đối tượng A và đối tượng

B liên kết phụ thuộc với nhau quá chặt nên rất khó có thể thay đổi lớp A nếu không

hiểu rõ về lớp B Vì vậy sử dụng Abstract Factory, Bridge, Command, Observer

Thiết kế mẫu đưa ra ý tưởng để khắc phục các vấn đề trên, cho phép ta xây dựng các kiến trúc độc lập nhau, sao cho bất cứ sự thay đổi của phần nào trong hệ thống cũng không làm ảnh hưởng hoặc ảnh hưởng rất ít đến các phần còn lại của hệ thống, từ đó làm cho phần mềm trở nên kiên định và linh động hơn

2.3 Mẫu chế tạo (Factory Pattern)

2.3.1 Định nghĩa

Mẫu chế tạo (Factory Pattern) định nghĩa một lớp (interface, abstract, class) đóng vai

trò như một “ nhà xưởng” có nhiệm vụ trừu tượng hoá quá trình khởi tạo đối tượng “ cụ

Luận văn thạc sỹ Nguyễn Đức Toàn

17

Các mẫu này giúp hệ thống không phải phụ thuộc vào cách một đối tượng được tạo ra, xây dựng và thể hiện

2.3.2 Đặc điểm

Mẫu chế tạo kiểm soát được các hoạt động trong suốt chu kỳ sống của đối tượng, như

khởi tạo đối tượng, huỷ đối tượng…Đảm bảo cho các đối tượng được thực thi an toàn Nắm được thông tin về những đối tượng nào được tạo ra và được khởi tạo ra sao Nói cách khác, các đối tượng được quản lý tốt và an toàn hơn Factory Đối tượng của Factory thường được đặt tên theo những chuẩn khác nhau nhưng vẫn có thể dễ dàng nhận ra thiết

kế Factory chứa trong đó Ví dụ: BankFactory…

Tính chất đóng gói thể hiện rõ trong mẫu Factory, các thông tin liên quan đến truy cập đối tượng được che giấu trong Factory Thiết kế Factory luôn có một thủ tục khởi tạo đối tượng, ví dụ creatObject()

Mẫu Factory luôn tuân thủ nguyên tắc thiết kế (Dependency inversion Principle - DIP) không nên phụ thuộc vào những thứ quá cụ thể

2.3.3 Phân loại

Mẫu Factory được thiết kế theo một trong hai cách sau đây:

a Lớp cơ sở (Base- class) : mẫu này sử dụng tính chất thừa kế để phân loại các đối

tượng được tạo ra

b Đối tượng cơ sở(Base – object): Sử dụng mối quan hệ kết hợp để tham chiếu tới

một đối tượng sẽ được tạo ra Đối tượng được tạo ra sẽ trở thành một phần hay thuộc tính của lớp Factory Chúng ta thường hay gặp loại này trong mẫu chế tạo trừu tượng(Abstrac Factory Pattern)

2.3.4 Một biểu đồ lớp bằng UML của mẫu chế tạo

Hình 2.1 Biểu đồ lớp của lớp chế tạo

2.4 Mẫu chế tạo trừu tƣợng (Abstract Factory Pattern)

2.4.1 Định nghĩa

Mẫu Abstract Factory cung cấp một giao diện lớp có chức năng tạo ra một tập hợp các đối tượng liên quan hoặc phụ thuộc lẫn nhau mà không chỉ ra đó là những lớp cụ thể nào tại thời điểm thiết kế

Về bản chất, mẫu Abstract Factory chỉ khác mẫu Factory ở chỗ bản thân đối tượng factory không được chỉ ra cụ thể tại thời điểm thiết kế Nó là một giao diện hoặc lớp trừu tượng (interface, absstract) Nếu như mẫu Factory phân loại đối tượng dựa trên tham số đầu vào, thì đối với mẫu Abstract Factory Pattern, thủ tục createObject() còn phụ thuộc vào các yếu tố phụ khác như môi trường hệ điều hành Ứng với mỗi yếu tố phụ thứ hai ta

có một lớp Factory cụ thể

2.4.2 Thiết kế động với mẫu chế tạo trừu tƣợng

Một trong những vấn đề gặp phải là khung giao diện Abstract Factory thường hay bị sửa đổi, thí dụ như bổ sung thủ tục chẳng hạn, khi đó các lớp cụ thể thực thi giao diện này

sẽ phải được dịch và triển khai lại Để giảm nhẹ vấn đề này người ta thường thiết kế giao diện Abstract Factory một cách linh hoạt

Luận văn thạc sỹ Nguyễn Đức Toàn

19

2.4.3 Biểu đồ lớp bằng UML của mẫu

Hình 2.2 Biểu đồ lớp của mẫu chế tạo trừu tượng

2.5 Mẫu đơn chiếc (Singleton Pattern)

Mẫu đơn chiếc (Singleton Pattern) đảm bảo một lớp chỉ có một thể hiện duy nhất được tạo ra và đồng thời cung cấp một truy cập toàn cục đến đối tượng được tạo ra

Hình 2.3 Minh hoạ biểu đồ lớp của mẫu đơn chiếc

Hình 2.4 Ví dụ mẫu đơn chiếc

Một số ví dụ về mẫu Singleton: file system, file manager, window manager

2.5.2 Lợi ích

Việc sử dụng mẫu Singleton đem lại các lợi ích sau:

- Quản lý việc truy cập tốt hơn vì chỉ có một thể hiện đơn nhất

- Cho phép cải tiến các tác vụ (operations) và các thể hiện (representation) do mẫu có thể được kế thừa và tuỳ biến lại thông qua một thể hiện của lớp con

- Quản lý số lượng thể hiện của một lớp, không nhất thiết chỉ có một thể hiện mà có số thể hiện xác định

- Khả chuyển hơn so với việc dùng một lớp có thuộc tính là tĩnh, vì việc dùng lớp tĩnh chỉ có thể sử dụng một thể hiện duy nhất, còn mẫu đơn chiếc cho phép quản lý các thể hiện tốt hơn và tuỳ biến theo điều kiện cụ thể

2.5.3 Trường hợp sử dụng

Ta có thể sử dụng mẫu đơn chiếc trong những trường hợp sau:

- Chỉ cần một thể hiện duy nhất của một lớp

- Khi thể hiện duy nhất có thể thay đổi thông qua việc thừa kế, người dùng có thể sử dụng thể hiện thừa kế đó mà không cần thay đổi các đoạn mã của chương trình

Luận văn thạc sỹ Nguyễn Đức Toàn

21

2.5.4 Cách thực hiện

Thực hiện mẫu đơn chiếc theo các bước sau:

- Định nghĩa một thuộc tính riêng (Private) và tĩnh (static) trong các lớp Singleton: instance

- Định nghĩa tất cả các constructor thành các protected hoặc các private để người dùng không thể tạo thực thể trực tiếp từ lớp

- Định nghĩa một accessor Public và static trong lớp: getInstance()

- Thực hiện "Lazzy initialization"- khởi động chậm, khởi tạo khi yêu cầu trong getInstance(): trả về một thể hiện mới hay một giá trị rỗng (null) tuỳ thuộc vào một biến boolean, biến này như một cờ hiệu dùng báo xem lớp đó đã có thể hiện hay chưa

- Client chỉ dùng getInstance() để tạo đối tượng của lớp Singleton

Thừa kế cũng được hỗ trợ, nhưng không nạp chồng (overridden) các phương thức Static: lớp cơ sở phải được khai báo là friend với lớp dẫn xuất (để truy xuất đến prrotected constructor)

Hình 2.5 Biểu đồ lớp trong mẫu đơn chiếc Trong chế độ đa luồng, mẫu Singleton có thể làm việc không tốt: hai thread có thể gọi phương thức sinh đối tượng cùng thời điểm và hai thể hiện sẽ được tạo ra

2.5.5 Ứng dụng của mẫu đơn chiếc

Ứng dụng rõ rệt nhất của mẫu đơn chiếc có thể thấy trong dịch vụ web khi triệu gọi các đối tượng từ xa Ở đó đối tượng nằm trên server hoặc sẽ phục vụ chung cho tất cả các

ứng dụng khách (singleton) hoặc sẽ chỉ đáp ứng một ứng dụng khách riêng lẻ nào đó rồi

tự bị phá huỷ sau đó(single call)

2.6 Mẫu uỷ nhiệm (Proxy Pattern)

2.6.1 Định nghĩa

Mẫu uỷ nhiệm (Proxy pattern): là mẫu thiết kế mà ở đó tất cả các truy cập trực tiếp

một đối tượng nào đó sẽ được chuyển hướng vào một đối tượng trung gian của lớp uỷ nhiệm (Proxy class)

Mẫu uỷ nhiệm không những giúp quản lý đối tượng tốt hơn mà còn có nhiệm vụ bảo

vệ việc truy cập một đối tượng bằng cách thông qua proxy, hay còn gọi là truy cập gián tiếp Mẫu Proxy được uỷ quyền về phía ứng dụng khách cho phép tương tác với đối tượng đích theo những cách khác nhau, như gửi yêu cầu một dịch vụ nào đó, theo dõi trạng thái

và vòng đời đối tượng, xây dựng lớp vỏ bảo vệ đối tượng…Thí dụ, chúng ta phát hiện ra một đối tượng như một thư viện DLL có thể bị khai thác truy cập vào trong một số trường quan trọng, khi đó chúng ta không thể mở mã nguồn thư viện đã được dịch để vá lỗ hổng Giải pháp lúc này là xây dựng một proxy ngăn chặn truy cập các trường đó và cuối cùng biên dịch lại thành một DLL mới

2.6.2 Phân loại

Độ phức tạp của giải pháp sử dụng mẫu uỷ nhiệm phụ thuộc vào tình huống bài toán đưa ra

- Ủy nhiệm từ xa (Remote Proxy): Máy khách truy cập qua remote proxy để tham

chiếu tới một đối tượng được bảo vệ nằm bên ngoài ứng dụng như dịch vụ Windows, dịch vụ web, ứng dụng từ xa Mô hình này “ che giấu” đối tượng được triệu gọi đang nằm ở rất xa đâu đó và client có vẻ như truy cập vào đối tượng nằm trên cùng một miền làm việc

Luận văn thạc sỹ Nguyễn Đức Toàn

23

- Uỷ nhiệm ảo (Virtual Proxy): tạo ra một đối tượng trung gian mỗi khi có yêu cầu tại

thời điểm thực thi ứng dụng, nhờ đó làm tăng hiệu suất của ứng dụng

- Uỷ nhiệm giám sát (Monitor Proxy): sẽ thiết lập các ràng buộc bảo mật trên đối

tượng cần bảo vệ, ngăn không cho client truy cập một số trường quan trọng của đối tượng

- Uỷ nhiệm bảo vệ (Protection proxy): Đối với proxy này thì phạm vi truy cập của các

client khác nhau sẽ khác nhau Protection Proxy sẽ kiểm tra các quyền truy cập của client khi có dịch vụ được yêu cầu

- Uỷ nhiệm bộ đệm (Cache proxy): Cung cấp không gian lưu trữ tạm thời cho các kết

quả trả về đối tượng nào đó Kết quả này sẽ được tái sử dụng cho các client chia sẻ chung một yêu cầu gửi đến và do đó làm tăng đáng kể hiệu suất chương trình

- Uỷ nhiệm tường lửa (Firewall proxy): Bảo vệ đối tượng từ chối các yêu cầu xuất xứ

từ các client không tín nhiệm

- Uỷ nhiệm tham chiếu thông minh (Smart reference proxy): Là nơi kiểm soát các hoạt

động bổ sung mỗi khi đối tượng được tham chiếu, ví dụ như kiểm soát vòng đời của đối tượng, lưu lại số lần tham chiếu vào đối tượng…

- Uỷ nhiệm đồng bộ (Synchoronization Proxy): Đảm bảo nhiều client có thể truy cập

vào cùng một đối tượng mà không gây xung đột Thực tế có rất nhiều tình huống khiến chúng ta phải nghĩ đến thiết kế này Một Synchronization proxy được thiết lập

có thể kiểm soát được nhiều yêu cầu cập nhật dữ liệu một cách đồng thời, tại thời điểm bắt đầu cập nhật chỉ có một client với mức ưu tiên cao nhất giành được khoá để đánh dấu rằng các client khác cần phải chờ đến lượt Synchronization proxy hoạt động rất hiệu quả và phổ biến trong thiết kế các bài toán đa tuyến Một hiện tượng hay xảy ra với thiết kế này là khi một client nào đó chiếm dụng khoá khá lâu khiến cho số lượng các client trong danh sách hàng đợi cứ tăng lên, và do đó hoạt động của

hệ thống bị ngưng trệ, có thể dẫn đến hiện tượng “tắc nghẽn” là hiện tượng khoá được giữ vô thời hạn bởi một đối tượng nào đó Trong trường hợp này người ta cải tiến thành mẫu thiết kế phức tạp hơn đó là Copy_ on_write proxy

- Uỷ nhiệm sao chép ghi ra (Copy - on – write proxy): Đảm bảo rằng, sẽ không có

client nào phải chờ vô thời hạn Thiết kế này rất phức tạp do đó chỉ nên ứng dụng nó thay thế cho synchronization proxy khi hệ thống được dự đoán sẽ thường xuyên bị ngưng trệ hoặc các hiện tượng tắc nghẽn xảy ra

2.6.3 Đặc điểm chung

Mẫu Proxy có những đặc điểm chung sau đây:

- Cung cấp mức truy cập gián tiếp vào một đối tượng

- Tham chiếu vào đối tượng đích và chuyển tiếp các yêu cầu đến đối tượng đó

- Cả Proxy và đối tượng đích đều thừa kế hoặc thực thi chung một lớp giao diện Mã máy dịch cho lớp giao diện thường “nhẹ” hơn các lớp cụ thể và do đó có thể giảm được thời gian tải dữ liệu giữa server và client

2.6.4 Biểu đồ lớp bằng UML của mẫu

Hình 2.6 Biểu đồ lớp mẫu uỷ nhiệm

2.7 Mẫu thích nghi (Adapter Pattern)

2.7.1 Định nghĩa

Mẫu thích nghi (adapter pattern) biến đổi giao diện của một lớp thành một giao diện khác mà các đối tượng client có thể hiểu được Lớp với giao diện được tạo ra gọi là Adapter Nguyên tắc cơ bản của mẫu thích nghi nằm ở chỗ, làm thế nào để các lớp với các giao diện không tương thích có thể làm việc được với nhau

Nguyên lý xây dựng mẫu thích nghi khá đơn giản: chúng ta xây dựng một lớp với một giao diện mong muốn sao cho lớp đó giao tiếp được với một lớp cho trước ứng với một giao diện khác

Luận văn thạc sỹ Nguyễn Đức Toàn

25

Mẫu thích nghi không quản lý tập trung các đối tượng gần giống như mẫu chế tạo, mà kết nối với nhiều lớp không có liên quan gì với nhau Ví dụ, lớp A sau khi thực thi giao diện của nó và vẫn muốn bổ sung các phương thức từ một lớp B nào đó, chúng ta có thể kết nối A với B thông qua hình thức kế thừa hoặc liên kết đối tượng như một thành phần Mẫu Adapter có một chút giống mẫu proxy ở chỗ đã tận dụng tối đa tính chất “uỷ quyền”

Mẫu Adapter được ứng dụng trong các trường hợp sau :

- Cần tích hợp một vài module vào chương trình

- Không thể sát nhập trực tiếp module vào chương trình

- Module đang tồn tại không có giao diện như mong muốn

- Cần nhiều hơn các phương thức cho module đó

- Một số phương thức có thể được nạp chồng

2.7.4 Biểu đồ lớp bằng UML của mẫu

Hình 2.7 Biểu đồ lớp thích nghi

2.8 Sơ đồ mối liên kết các mẫu thiết kế

Hình dưới đây cho ta các mẫu thiết kế khác nhau và mối quan hệ liên kết giữa chúng

Hình 2.8 Sơ đồ mối liên kết các mẫu thiết kế

CHƯƠNG 3 ỨNG DỤNG MẪU Phân tích, thiết kế hệ thống

“ Quản lý khám chữa bệnh “

3.1 Mô tả bài toán

3.1.1 Bài toán

Hệ thống “Quản lý khám chữa bệnh” là một hệ thống rất quan trọng của các công ty

Hệ thống hỗ trợ các công ty trong việc quản lý khám chữa bệnh của nhân viên Mỗi tổng công ty (Group) sẽ có các công ty con (Company) Các công ty sẽ có nhân viên (Emplooye) và người nhà (Dependant)

Mỗi nhân viên và người nhà sẽ có những chế độ được hưởng khi đi khám chữa bệnh khác nhau Khi đi khám hệ thống sẽ dựa vào chế độ được hưởng của nhân viên và người nhà để đưa ra phí khám chữa bệnh mà người đó phải trả cũng như những chi phí mà người đó được hưởng

3.1.2 Các vấn đề cần giải quyết

Xây dựng hệ thống với đầy đủ chức năng quản lý việc hỗ trợ khám chữa bệnh trong công ty

Hỗ trợ các dịch vụ trực tuyến và môi trường giao tiếp tiện ích bao gồm :

- Dịch vụ tra cứu trực tuyến: Cung cấp thông tin của nhân viên cũng như các thông tin

khám chữa bệnh

- Cung cấp môi trường giao tiếp giữa lãnh đạo công ty, lãnh đạo phòng khám cũng

như nhân viên trong công ty Cho phép cập nhật thông tin trực tuyến

- Giao tiếp trên cơ sở những công nghệ mới ví dụ qua các thẻ từ, qua các thiết bị di

động để việc xử lý đặc biệt là các thủ tục hành chính được dễ dàng và tiết kiệm thời gian

- Hỗ trợ các chuẩn: với một lượng dữ liệu lớn cho cả một bài toán tổng thể Việc truy

xuất dữ liệu là rất nhiều và phức tạp Cải thiện tốc độ cũng như bổ sung các thuật toán giúp cho nâng cao tốc độ hiển thị và thao tác là cần thiết

- Bảo mật và an toàn dữ liệu: vấn đề đặt ra là phải sử dụng một công nghệ lưu trữ dữ

liệu phù hợp để đảm bảo tốc độ xử lý và an toàn dữ liệu Đảm bảo tính an toàn dữ liệu trong hệ thống nhằm tránh sai sót cho người quản trị dữ liệu trong lưu trữ và xử lý, ngăn chặn những hành vi gian lận từ bên ngoài

3.2 Phát triển hệ thống

3.2.1 Các chức năng của hệ thống

R1 Quản trị hệ thống (Admin)

R 1.1 Cập nhật thông tin phòng khám (Clinic)

R 1.2 Cập nhật người sử dụng thệ thống mức phòng khám (Clinic User)

R 1.3 Cập nhật thông tin loại phòng khám (ProviderType)

R 1.4 Cập nhật thông tin các chẩn đoán (Diagnosis)

R 1.5 Cập nhật thông tin các loại thuốc (Drug)

R 1.6 Cập nhật thông tin các xét nghiệm (Lab)

R 1.7 Cập nhật thông tin các loại chiếu chụp (Xray)

R 1.8 Cập nhật thông tin tổng công ty (Group)

R 1.9 Cập nhật người sử dụng mức Group (Group User)

R 1.10 Cập nhật người sử dụng mức Admin (Admin User)

R 1.11 Cập nhật loại quyền sử dụng hệ thống (User Role Type)

R 1.12 Cập nhật quyền sử dụng hệ thống (UserRole)

R 1.13 Đổi mật khẩu (Password)

R2 Quản trị mức tổng công ty (Group)

R 2.1 Cập nhật thông tin công ty (Company)

R 2.2 Cập nhật người sử dụng mức công ty (Company User)

R 2.3 Cập nhật loại quyền lợi (Benefit Scheme)

R 2.4 Cập nhật loại hình khám (Visit Display)

Luận văn thạc sỹ Nguyễn Đức Toàn

29

R 2.5 Cập nhật đợt thanh toán (Batch)

R 2.6 Cập nhật thanh toán theo đợt tới từng công ty (Invoice)

R 2.7 Cập nhật thanh toán theo đợt tới từng phòng khám (Payment Advice)

R 2.8 Đổi mật khẩu (Password)

R3 Quản trị mức công ty (Company)

R 3.1 Cập nhật thông tin nhân viên (Employee)

R 3.2 Cập nhật thông tin người nhà nhân viên (Dependant)

R 3.3 Đổi mật khẩu (Password)

R 4 Quản trị mức phòng khám (Clinic)

R 4.1 Cập nhật thông tin khám (EmpVisit)

R 4.3 Đổi mật khẩu (Password)

3.2.2 Các khái niệm và mô hình lĩnh vực

ProviderType

Payment Advice Thanh thoán theo đợt tới Clinic

Luận văn thạc sỹ Nguyễn Đức Toàn

31

3.2.2.2 Mô hình khái niệm mức nghiệp vụ

Hình 3.1 Mô hình khái niệm mức nghiệp vụ (hình 1) Hình 3.1 mô tả mối quan hệ giữa tổng công ty, công ty, nhân viên, người nhà nhân viên và mức ưu đãi được hưởng

Hình 3.2 Mô hình khái niệm mức nghiệp vụ (hình 2) Hình 3.2 mô tả mối quan hệ giữa BenefitScheme, BSInPanel, VisitDisplay, ProviderType

Luận văn thạc sỹ Nguyễn Đức Toàn

33

Hình 3.3 Mô hình khái niệm mức nghiệp vụ (hình 3) Hình 3.3 mô tả mối quan hệ giữa EmpVisit, Employee, Dependant, Clinic, ProviderType, DrugVisit, LabVisit, XrayVisit, Drug, Lab, Xray, Diagnosis

Hình 3.4 Mô hình khái niệm mức nghiệp vụ (hình 4) Hình 3.4 mô tả mối quan hệ giữa EmpVisit, Batch, Invoice, PaymentAdvice, Company, Clinic

Luận văn thạc sỹ Nguyễn Đức Toàn

35

3.3 Xác định các tác nhân, các ca sử dụng và mô tả các ca sử dụng

Hệ thống được chia ra làm 5 nhóm tác nhân với các chức năng chính như sau:

- Admin User : Có quyền điều khiển toàn bộ hệ thống: thêm, sửa, xoá các chức năng

truy cập của các nhóm tác nhân khác Ngoài ra còn có chức năng tạo ra các tổng công

ty (Group), người dùng mức tổng công ty (GroupUser), các phòng khám (Clinic), …

- Group User : Có quyền kiểm soát hệ thống ở mức tổng công ty: quản lý các công ty,

tạo ra các quyền lợi (benefitScheme), tạo thanh toán (Invoice, PaymentAdvice)…

- Company User : Có quyền kiểm soát hệ thống ở mức công ty : Quản lý thông tin của

nhân viên và người nhà nhân viên

- Clinic User : Có quyền kiểm soát hệ thống ở mức phòng khám : Quản lý khám chữa

bệnh của bệnh nhân (bao gồm nhân viên và người nhà nhân viên)

- Employee User : Có quyền xem thông tin nhân viên : Có quyền xem thông tin nhân

viên cũng như thông tin khám chữa bệnh của nhân viên

3.3.1 Xác định các tác nhân

a, Nhân viên hệ thống mức Admin (Admin user)

thoả mãn điều kiện tìm kiếm

Thêm người sử dụng mức Clinic Thêm mới Clinic User

User thoả mãn điều kiện tìm kiếm

(ProviderType)

Thêm mới ProviderType

Provider Type thoả mãn điều kiện tìm

kiếm

Diagnosis thoả mãn điều kiện tìm kiếm

thoả mãn điều kiện tìm kiếm

thoả mãn điều kiện tìm kiếm

thoả mãn điều kiện tìm kiếm

thoả mãn điều kiện tìm kiếm

Thêm người sử dụng mức Group

(Group User)

Thêm mới một Group User

User thoả mãn điều kiện tìm kiếm

Thêm người sử dụng mức Admin Thêm mới một Admin User

Luận văn thạc sỹ Nguyễn Đức Toàn

37

(Admin User)

User thoả mãn điều kiện tìm kiếm

Thêm loại quyền sử dụng hệ thống

(UserRoleType)

Thêm mới một UserRoleType

Tìm kiếm UserRoleType Đưa ra màn hình danh sách các User

Role Type thoả mãn điều kiện tìm kiếm

Thêm quyền sử dụng hệ thống

(UserRole)

Thêm mới một UserRole

Role thoả mãn điều kiện tìm kiếm

b Người sử dụng mức Group

Company thoả mãn điều kiện tìm kiếm

Thêm người sử dụng mức công ty

(Company User)

Thêm mới một Company User

Company User thoả mãn điều kiện tìm kiếm

Thêm loại quyền lợi (Benefit Scheme) Thêm mới một Benefit Scheme