Ứng dụng XML xây dựng framework dựa web giải quyết bài toán quản lý

Khái niệm về mẫu 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.. nghi nhận

ỨNG DỤNG XML XÂY DỰNG FRAMEWORK DỰA WEB

GI ẢI QUYẾT LỚP BÀI TOÁN QUẢN LÝ

LÊ HUY TUỆ

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

LUẬN VĂN THẠC SỸ KHOA HỌC

ỨNG DỤNG XML XÂY DỰNG FRAMEWORK DỰA WEB

GIẢI QUYẾT LỚP BÀI TOÁN QUẢN LÝ

NGÀNH : CÔNG NGHỆ THÔNG TIN

MÃ SỐ : ………

LÊ HUY TUỆ

Người hướng dẫn khoa học : PGS,TS HUỲNH QUYẾT THẮNG

Hà Nội 2009

LỜI CAM ĐOAN 1

LỜI NÓI ĐẦU 2

MỘT SỐ THUẬT NGỮ VIẾT TẮT 4

DANH MỤC HÌNH VẼ 5

DANH MỤC BẢNG BIỂU 6

I CHƯƠNG 1 – CƠ SỞ LÝ THUYẾT VỀ MẪU, FRAMEWORK VÀ UML TRONG PHÁT TRIỂN PHẦN MỀM 7

I.1 Mẫu 7

I.1.1 Khái niệm về mẫu 7

I.1.2 Mẫu kiến trúc 8

I.1.3 Mẫu thiết kế 17

I.1.4 Idioms 20

I.2 Framework 20

I.2.1 Khái niệm về Framework 20

I.2.2 Phân loại framework 22

I.2.3 Mẫu và kiến trúc phần mềm 23

I.3 UML 25

I.3.1 Các góc nhìn của UML 26

I.3.2 Các biểu đồ của UML 27

I.4 Kết chương 32

II CH ƯƠNG 2 – XML VÀ KHẢ NĂNG ỨNG DỤNG XÂY DỰNG FRAMEWORK DỰA WEB 33

II.1 Kỹ thuật XML 33

II.1.1 Khái niệm chung về XML 33

II.1.2 XML Schema 35

II.1.6 Biểu diễn dựa trên XML 50

II.2 Phát triển phần mềm 52

II.2.1 Quy trình phát triển phần mềm nói chung 52

II.2.2 Một số vấn đề trong phát triển phần mềm 57

II.3 Khả năng sử dụng XML phát triển Framework ứng dụng trong phát triển phần mềm 59

II.4 Kết chương 60

III CHƯƠNG 3 – GIẢI PHÁP THIẾT KẾ 61

III.1 Lựa chọn mô hình phát triển phần mềm 61

III.1.1 Fusebox 61

III.1.2 PHP 63

III.2 Xây dựng Framework 67

III.2.1 Tầng biểu diễn và tầng logic 68

III.2.2 Tầng tích hợp dữ liệu 78

III.3 Bài toán ứng dụng 79

III.3.1 Phân tích và thiết kế bài toán 82

III.3.2 Cài đặt 91

III.4 Kết chương 98

KẾT LUẬN 99

TÀI LIỆU THAM KHẢO 102

LỜI CAM ĐOAN

Tôi – Lê Huy Tuệ, học viên lớp Cao học CNTT 2007-2009 Trường Đại học Bách Khoa Hà Nội – cam kết luận văn tốt nghiệp này là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của PGS,TS Huỳnh Quyết Thắng - Viện Công nghệ Thông tin và Truyền thông - Trường Đại học Bách Khoa Hà Nội

Các kết quả nêu trong luận văn tốt nghiệp là trung thực, không sao chép toàn văn của bất kỳ công trình nào khác

Hà Nội, tháng 11 năm 2009

Học viên

Lê Huy Tuệ

LỜI NÓI ĐẦU

Web bắt nguồn là một dự án ở CERN (Viện nghiên cứu vật lý hạt nhân Châu Âu) với mục tiêu ban đầu là lưu trữ siêu văn bản trên máy tính để dễ dàng tìm kiếm, tra cứu Nhưng nó nhanh chóng trở nên phổ biến và là một phần không thể thiếu được trong thời đại công nghệ thông tin ngày nay Ban đầu sử dụng là những trang web riêng lẻ Sau đó là tập hợp các trang web có quan hệ về nội dung và được liên kết với nhau bằng các siêu liên kết mà ngày nay ta gọi chúng là website Không chỉ dừng lại ở việc chia sẻ các thông tin tĩnh dưới dạng các trang web người sử dụng trên internet còn muốn tìm kiếm, cập nhật, sửa đổi thông tin Các khái niệm về ứng dụng web cũng phát triển từ đó Ứng dụng web là một ứng dụng client-server trong

đó thường thì Browser đóng vai trò là client Cũng kể từ đó rất nhiều framework để phát triển ứng dụng web ra đời cùng với nhiều ngôn ngữ web phong phú trong đó phải kể đến như viết bằng ngôn ngữ Java có framework như Spring, Struts; viết bằng ngôn ngữ NET (C# hay VB.net, …) có một số mô hình như mô hình 3 lớp ASP.NET, mô hình ASP.NET AJAX (ASP.NET tích hợp AJAX) và gần đây nhất là ASP.NET MVC; viết bằng PHP có Symfony, CakePHP, Drupal,… ; viết bằng Ruby có Ruby on Rails; và rất nhiều ngôn ngữ khác nữa

Nội dung cơ bản của luận văn đề cập đến việc áp dụng các kỹ thuật XML trong việc xây dựng framework ứng dụng dựa trên web Mục tiêu của luận văn là đưa ra một framework ứng dụng dựa trên web hỗ trợ mạnh cho người phát triển trong quá trình xây dựng ứng dụng cũng như quá trình bảo trì, nâng cấp ứng dụng cho khách hàng Ở đó đặc điểm nổi bật của framework thể hiện trên hai khía cạnh là

tự động tạo form nhập liệu, biểu diễn dữ liệu và lưu trữ dữ liệu động Trong đó tự động tạo form nhập liệu hay biểu diễn dữ liệu có nghĩa là người phát triển chỉ cần khai báo các form cũng như màn hình hiển thị chương trình sẽ tự động tạo form khi chạy Còn lưu trữ dữ liệu động có nghĩa là một số dữ liệu được nhóm gộp lại một cách tự động khi chương trình chạy thành dạng dữ liệu XML và lưu trữ vào CSDL theo ý đồ thiết kế của người thiết kế Ta có thể hình dung các tính năng này qua ví

dụ đơn giản như sau : Giả sử một ứng dụng nào đó đã hoàn thành và đem triển khai cho khách hàng, tại một form nhập liệu người sử dụng muốn bổ sung thêm thông tin cần nhập liệu Như vậy công việc của người phát triển lúc này chỉ là bổ sung thêm khai báo đối tượng nhập liệu trên form Chương trình sẽ tự động tạo ra form thỏa mãn người dùng khi chạy Dữ liệu nhập vào cũng sẽ tự động lưu trữ vào CSDL dưới dạng dữ liệu XML mà không cần phải có bất kỳ bổ sung thêm nào về code cũng như hiệu chỉnh CSDL

Luận văn được trình bày gồm ba chương chính Chương 1 - Cơ sở lý thuyết

về Mẫu, Framework và UML trong phát triển phần mềm đề cập đến các vấn đề

về cơ sở lý thuyết bao gồm lý thuyết về Mẫu, Framework và UML Chương 2 –

XML và khả năng ứng dụng xây dựng Framework dựa Web chương này tập trung

vào trình bày các vấn đề cơ bản của XML, các vấn đề trong phát triển phần mềm nói chung từ đó rút ra việc khai thác sử dụng XML trong xây dựng một Framework

phát triển ứng dụng như thế nào Chương 3 - Giải pháp thiết kế trình bày giải pháp

xây dựng framework ứng dụng dựa trên web cụ thể đồng thời mô tả một bài toán thực tế điển hình áp dụng framework đã xây dựng đó để cài đặt

Tôi xin chân thành cảm ơn thầy giáo PGS,TS Huỳnh Quyết Thắng đã tận tình hướng dẫn và giúp đỡ tôi về mặt kiến thức cũng như tài liệu để tôi có thể hoàn thành tốt luận văn này Tôi cũng xin cảm ơn các thầy giáo, cô giáo Khoa Công nghệ thông tin - Trường Đại học Bách Khoa Hà Nội và các thầy, cô giáo đã tham gia giảng dạy, chỉ bảo, giúp đỡ học viên chúng tôi trong suốt khóa học Xin cảm ơn Ban lãnh đạo Công ty Cổ phần Công nghệ Tin học ESS đã tạo điều kiện để tôi hoàn thành tốt khoá học này.Cuối cùng tôi xin được cảm ơn tất cả mọi người trong gia đình và bạn bè thân thiết - những người luôn tin tưởng, giúp đỡ tôi trong quá trình học tập và công tác

Hà Nội, tháng 11 năm 2009

Học viên

Lê Huy Tuệ

MỘT SỐ THUẬT NGỮ VIẾT TẮT

STT Tên thuật

ngữ

Ý nghĩa

1 CGI Common Gateway Interface (Hệ giao tiếp cổng vào chung)

2 CNTT Công nghệ thông tin

3 CSDL Cơ sở dữ liệu

4 HĐND Hội đồng nhân dân

5 HTML Hypertext Markup Language (Ngôn ngữ đánh dấu siêu văn)

14 TTTHDL Trung tâm tích hợp dữ liệu tỉnh

15 UBND Uỷ ban nhân dân

DANH MỤC HÌNH VẼ

1 Hình 1.1 Mô hình OSI 7 tầng 9

2 Hình 1.2 Mô hình compiler của ngôn ngữ Mocha 11

3 Hình 1.3 Mô hình nhận dạng tiếng nói 11

4 Hình 1.4 Mô hình hệ thống thông tin thành phố chạy trên mạng

5 Hình 1.5 Số liệu bầu cử biểu diễn theo các cách khác nhau 13

6 Hình 1.6 Tương tác Người – Máy trong việc nhập và xem dữ

7 Hình 1.7 Kiến trúc hình cây của agent PAC 16

8 Hình 1.8 Framework ứng dụng với các hot spot 21

9 Hình 1.9 Mô hình lớp B với 3 phương thức M1(), M2() và M3() 21

10 Hình 1.10 Mô hình lớp con B1 kế thừa lớp B và viết lại phương

11 Hình 1.11 Các góc nhìn của UML 26

12 Hình 1.12 Một số nút trong các biểu đồ 28

13 Hình 1.13 Một số đường trong các biểu đồ 28

14 Hình 1.14 Phân loại biều đồ trong UML 2.0 28

15 Hình 1.15 Biểu đồ Ca sử dụng 31

16 Hình 2.1 Mô hình chuyển đổi tài liệu XML thành HTML sử

17 Hình 2.2 Mô hình quan hệ hai lớp Person và Employee 51

18 Hình 3.1 Mô hình sử dụng chương trình CGI 65

19 Hình 3.2 Sự phân tầng trong mô hình ứng dụng 67

20 Hình 3.3 Kiến trúc tổng thể của framework 69

21 Hình 3.4 Cấu tạo chung của ứng dụng circuit 71

22 Hình 3.5 Ví dụ form nhập liệu thông tin cá nhân 73

23 Hình 3.6 Mô hình sử dụng XML trong tạo form tự động 74

24 Hình 3.7 Tạo chuỗi XML dữ liệu để lưu trữ 77

25 Hình 3.8 Ví dụ 2 form nhập liệu thông tin cá nhân 78

26 Hình 3.9 Quy trình nghiệp vụ xử lý hồ sơ TTHC 83

27 Hình 3.10 Mô hình chức năng tổng thể của hệ thống quản lý

28 Hình 3.11 Mô hình chức năng tiếp nhận hồ sơ và trả kết quả 86

29 Hình 3.12 Mô hình chức năng thụ lý hồ sơ 87

30 Hình 3.13 Mô hình chức năng giao tiếp với công dân 88

31 Hình 3.14 Mô hình chức năng trao đổi thông tin 88

32 Hình 3.15 Mô hình chức năng quản trị hệ thống 89

33 Hình 3.16 Cấu trúc thư mục chương trình EGATE 93

34 Hình 3.17 Quy trình hiển thị form cập nhật hồ sơ TTHC 95

35 Hình 3.18 Màn hình cập nhật TTHC Giải quyết trợ cấp cho người

DANH MỤC BẢNG BIỂU

1 Bảng 3.1 Chi tiết các tầng trong mô hình ứng dụng 67

2 Bảng 3.2 Danh sách TTHC có thể áp dụng tại UBND cấp Huyện 80

3 Bảng 3.3 Chi tiết fuseaction và các file thực thi 92

4 Bảng 3.4 Chi tiết bảng T_ONEGATE_RECORD 94

5 Bảng 3.5 Danh sách thẻ XML khai báo form tiếp nhận TTHC 95

I CHƯƠNG 1 – CƠ SỞ LÝ THUYẾT VỀ MẪU,

PHẦN MỀM

I.1.1 Khái niệm về mẫu

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 để truyền đạt kiến thức và 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ể

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à 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 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 [9]

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 framework Framework 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à

nghi 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 chuyên khu 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 Ngày nay người ta đã tổng hợp và đưa ra khá nhiều mẫu Các mẫu được chia thành ba nhóm chính như sau :

- Mẫu kiến trúc : Đưa ra được kiến trúc tổng thể của phần mềm

- Mẫu thiết kế : Đưa ra kiến trúc phần mềm các hệ con, mỗi quan hệ giữa

chúng

- Idiom : Đề cập đến việc thực thi vấn đề thiết kế cụ thể

I.1.2 Mẫu kiến trúc

Kiến trúc phần mềm khả thi được xây dựng theo một số công thức cấu trúc chung Ta mô tả công thức chung này bằng mẫu kiến trúc Mẫu kiến trúc đưa ra lược đồ tổ chức có cấu trúc nền tảng cho các hệ phần mềm Nó cung cấp tập các hệ con định nghĩa trước, định rõ trách nhiệm của chúng, và bao gồm các luật, các nguyên tắc tổ chức mối quan hệ giữa chúng Mẫu kiến trúc là các template cho một kiến trúc phần mềm cụ thể Chúng đặc tả các tính chất có cấu trúc hệ lớn của ứng dụng và tác động vào kiến trúc các hệ con của nó Mẫu kiến trúc biểu diễn mẫu mức cao nhất trong hệ thống mẫu Chúng giúp đặc tả cấu trúc nền tảng của ứng dụng Mỗi hoạt động phát triển đều bị chi phối bởi cấu trúc này, ví dụ thiết kế chi tiết hệ con, giao tiếp hoặc cộng tác giữa các phần khác nhau của hệ thống và các phần mở rộng Mẫu kiến trúc được phân thành các loại như sau : [9]

• Từ Mud tới cấu trúc (From Mud to Structure) : Mẫu này giúp tránh số

lượng lớn các thành phần và đối tượng Nói riêng chúng trợ giúp điều khiển phân rã nhiệm vụ hệ thống tổng thể thành các nhiệm vụ nhỏ hơn Phân loại này bao gồm các mẫu là Layer, Pipes và Filter, Blackboard

• Hệ phân tán : Phân loại này chỉ gồm một mẫu Môi giới và tham chiếu tới

hai mẫu trong các phân loại khác Microkernel, Pipes và Filters Mẫu môi

giới này cung cấp kiến trúc hạ tầng hoàn chỉnh cho ứng dụng phân tán Kiến trúc ban đầu được chuẩn hóa bởi Object Management Group (OMG)

• Hệ tương tác : Phân loại này bao gồm hai mẫu là Model-View-Controller và

Presentation-Abstraction-Control Cả hai mẫu này đều hỗ trợ xây dựng cấu trúc hệ phần mềm đặc tả tương tác giữa người với máy

• Hệ thích nghi : Gồm hai mẫu Reflection và Microkernel hỗ trợ mạnh các

mở rộng ứng dụng và sự thích nghi để tạo ra kỹ thuật và thay đổi yêu cầu chức năng

Sự phân loại này chưa hẳn đã triệt để nhưng phần nào phân chia được các mẫu hiện tại và có thể sử dụng để đưa thêm vào các loại mẫu mới

Mẫu kiến trúc Layer :

Mẫu này giúp xây dựng ứng dụng phân rã thành các nhóm nhiệm vụ con

Cung cấp phương tiện để người sử dụng truy nhập vào môi trường OSI Chuyển đổi cú pháp dữ liệu

Cung cấp phương tiện quản lý truyền thông giữa các ứng dụng

Truyền dữ liệu, kiểm soát lỗi, kiểm soát luồng dữ liệu

Chọn đường và chuyển tiếp thông tin

Cung cấp phương tiện truyền thông tin qua liên kết vật lý

Liên quan đến nhiệm vụ truyền dòng bit không cấu trúc qua đường truyền vật lý

Hình 1.1 – Mô hình OSI 7 tầng

Ví dụ : Theo ISO (The International Standardization Organiz) định nghĩa mô hình

kiến trúc mạng 7 lớp (Hình 1.1) Để giảm độ phức tạp của việc thiết kế và cài đặt

mạng, hầu hết các mạng máy tính hiện có đều được phân tích thiết kế theo quan

điểm phân tầng Mỗi hệ thống thành phần của mạng được xem như một cấu trúc đa

tầng, trong đó mỗi tầng được xây dựng trên tầng trước nó

Ngữ cảnh : Hệ thống lớn yêu cầu cần phân rã

Bài toán : Cần thiết kế 1 hệ thống mà ở đó có các vấn đề ở mức cao và mức thấp, hoạt động ở mức cao dựa trên mức thấp Thiết kế loại này cần cân bằng các yếu tố sau : Mã nguồn sau không được ảnh hưởng lan truyền trong toàn hệ thống, giao diện phải ổn định, thậm chí phải tuân thủ chuẩn tổng thể, các phần của hệ thống có khả năng trao đổi thông tin với nhau …vv

Giải pháp : Từ điểm nhìn ở mức cao, cấu trúc hóa hệ thống thành các tầng và đặt

chúng kề lên nhau Bắt đầu xây dựng ở mức thấp nhất rồi tiến hành xây dựng dần lên mức cuối cùng trong kiến trúc

Pipes và Filters

Mẫu kiến trúc Pipes và Filters cung cấp cấu trúc cho hệ thống xử lý luồng dữ liệu Mỗi bước xử lý đóng gói trong một component filter Dữ liệu được chuyển qua theo đường ống giữa các Filter liền kề

Ví dụ : Khi cần định nghĩa một ngôn ngữ mới có tên là Mocha (Modular Object

Computation with Hypothetical Algorithms) Nhiệm vụ là xây dựng một compiler cho ngôn ngữ này Khi đó ta có thể mô tả kiến trúc cần xây dựng như sau : Mã nguồn ASCII là đầu vào cho quá trình phân tích từ vựng của ngôn ngữ Kết quả của phân tích từ vừng là đầu vào cho quá trình phân tích cú pháp Liên tục như vậy cứ kết quả của quá trình này là đầu vào cho quá trình tiếp theo tạo thành một chuỗi liên tục các xử lý ta gọi là xử lý theo luồng dữ liệu

Ngữ cảnh : Xử lý luồng dữ liệu

Bài toán : Xây dựng hệ thống cần xử lý hoặc chuyển đổi luồng dữ liệu đầu vào

Giải pháp : Mẫu kiến trúc Pipes và Filters phân chia nhiệm vụ hệ thống thành một

số bước xử lý tuần tự Các bước này được kết nối bởi dòng dữ liệu qua hệ thống –

dữ liệu ra của bước này là dữ liệu vào của bước tiếp theo

ASCII program text

Token stream

Abstract syntax tree

Augmented abstract syntax tree

Aulalt program

Optimized Aulalt program

Hình 1.2 – Mô hình compiler của ngôn ngữ Mocha

Blackboard

Mẫu kiến trúc loại này hữu ích cho các bài toán không xác định trước được chiến lược giải pháp và thường để giải quyết các bài toán về nhận dạng giọng nói, chữ viết, hình ảnh

Ví dụ : Hệ thống nhận dạng tiếng nói Đầu vào là sóng âm, đầu ra phải là các câu

tiếng Anh Sóng âm được một thủ tục chia thành các segment theo ngữ nghĩa đầy đủ của giọng nói gọi là các phone Một thủ tục khác kiểm kiểm tra ngữ nghĩa của câu

có thể có Các thủ tục này làm việc trong các miền khác nhau

Hình 1.3 – Mô hình nhận dạng tiếng nói

Ngữ cảnh : Miền không rõ ràng mà ở đó không có phương pháp gần với giải pháp

đã biết hoặc khả thi

Bài toán : Mẫu Blackboard giải quyết bài toán không có một giải pháp xác định khả thi cho việc chuyển đổi dữ liệu thô thành cấu trúc dữ liệu mức cao như các biểu đồ, bảng hoặc câu tiếng Anh

Giải pháp : Ý tưởng đằng sau kiến trúc Blackboard là một tập chương trình độc lập

làm việc cộng tác trong cấu trúc dữ liệu phổ biến Mỗi chương trình chuyên dụng giải quyết một phần cụ thể của công việc tổng thể Tất cả các chương trình cùng làm việc với nhau trong cùng một giải pháp

I.1.2.2 Hệ phân tán

Loại này sử dụng mẫu kiến trúc Broker Mẫu này cấu trúc hóa hệ thống phần mềm phân tán với việc phân tách component tương tác triệu gọi dịch vụ từ xa [9]

Ví dụ : Thiết kế hệ thống thông tin thành phố chạy trên mạng diện rộng Một số

máy tính trong mạng cung cấp thông tin về sự kiện, nhà hàng, khách sạn, bệnh viện, trường học, …vv Tại một giao diện máy tính trong mạng cần lấy các thông tin đó

mà không cần phải lưu trữ chúng trong máy

OhWell City Tourist Information

Hotels Restaurants Public Transport Sighseeing Events City Map

Choose from menu COMPUTER – TERMINAL NowWhat Space Center

CityMap.getCompleteMap( ) Broker

11/11/2009 BMRSS International

City Map Server

getCompleteMap( ) currentPosition( ) showConnection( ) showPosition( ) locateBogHog( )

Town Hall

Hình 1.4 – Mô hình hệ thống thông tin thành phố chạy trên mạng diện rộng Ngữ cảnh : Môi trường phân tán và hệ thống có thể không đồng nhất với các thành

phần hoạt động tương hỗ độc lập

Bài toán : Xây dựng hệ phần mềm phức tạp như một tập các thành phần hoạt động tương hỗ tách rời

Giải pháp : Thành phần broker tách rời tốt hơn client và server Server tự đăng ký

với broker và tạo ra các dịch vụ cho phép client thông qua giao diện phương thức Client truy cập các chức năng của server bằng cách gửi các yêu cầu thông qua broker Nhiệm vụ của broker là xác định server thích hợp, chuyển yêu cầu tới server

và truyền kết quả cùng với ngoại lệ trở lại client

Ngày nay các hệ thống cho phép người sử dụng tương tác ở mức cao Chủ yếu phát triển nhờ vào giao diện đồ họa với người dụng Hai kiến trúc mẫu cơ bản làm nên điều này là Model-View-Controller (MVC) và Presentation-Abstraction-Control (PAC) [9]

Model-View-Controller

Mẫu kiến trúc MVC chia ứng dụng tương tác thành 3 component Model chứa các hàm cơ bản và dữ liệu View hiển thị thông tin tới người sử dụng Controller xử lý đầu vào của người sử dụng View và Controller kết hợp với nhau tạo nên giao diện người dùng [9]

43 39 6 10 2

Hình 1.5 – Số liệu bầu cử biểu diễn theo các cách khác nhau

Ví dụ : Xem hệ thống lấy và biểu diễn thông tin theo các cách khác nhau như hình

1.5 Đó là một hệ thống thông tin về bầu cử với số liệu biểu diễn theo kiểu tỷ lệ Hệ thống bao gồm một bảng tính (spreadsheet) để nhập dữ liệu đầu vào và các loại biểu diễn dữ liệu đầu ra là bảng và các biểu đồ Người sử dụng có thể giao tiếp với hệ thống thông qua giao diện đồ họa Tất cả dữ liệu hiển thị phải phản ánh dữ liệu mới nhất Có thể dễ dàng tích hợp thêm các cách biểu diễn dữ liệu mới mà không ảnh

hưởng nhiều tới hệ thống

Ngữ cảnh : Các ứng dụng tương tác với giao diện người – máy phức tạp

Bài toán : Giao diện người dùng đặc biệt thiên về các yêu cầu thay đổi Khi mở rộng chức năng của ứng dụng, phải thay đổi menu truy cập tới chức năng, khi khách hàng có các yêu cầu cụ thể về giao diện hoặc các nâng cấp phần mềm Tóm lại đảm bảo được các yêu cầu như sau :

- Cùng một thông tin có thể biểu diễn theo nhiều cách khác nhau tại các cửa sổ khác nhau

- Hiển thị và ứng xử của ứng dụng phải phản ánh các thao tác dữ liệu ngay lập tức

- Thay đổi giao diện người dùng dễ dàng và thậm chí có thể tại thời điểm chạy chương trình

- Hỗ trợ các chuẩn ‘look and feel’ hoặc các cổng giao tiếp người dùng mà không ảnh hưởng tới mã nguồn và core của hệ thống

Giải pháp : Như vậy mô hình MVC chia ứng dụng tương tác thành 3 phần : xử lý,

đầu ra, đầu vào Component Model đóng gói dữ liệu và và các chức năng, model độc lập với biểu diễn đầu ra cụ thể hoặc hành vi đầu vào Mỗi view có một component controller liên kết, controller nhận đầu vào thường là các sự kiện và chuyển thành dịch vụ yêu cầu cho model hoặc view Sự phân tách của model với view và controller cho phép một model có thể có nhiều view [9]

Presentation-Abstraction-Control

Presentation-Abstraction-Control (PAC) định nghĩa cấu trúc hệ phần mềm tương tác trong dạng thức kiến trúc cộng tác agent Mỗi agent đáp ứng trường hợp

abstraction và control Như vậy agent trong ngữ cảnh của mẫu có nghĩa là thành phần xử lý thông tin bao gồm từ việc nhận sự kiện, truyền và xử lý thông tin theo sự kiện Agent có thể nhỏ như một đối tượng nhưng cũng có thể phức tạp như một hệ phần mềm Thuật ngữ agent hay agent PAC là tương đương [9]

Ví dụ : Một hệ thống thông tin bầu cử đơn giản với số liệu biểu diễn theo kiểu tỷ lệ

43 39 6 10 2

Data entry

Hình 1.6 – Tương tác Người – Máy trong việc nhập và xem dữ liệu

Hệ thống bao gồm một bảng tính (spreadsheet) để nhập dữ liệu đầu vào và các loại biểu diễn dữ liệu đầu ra là bảng và các biểu đồ Tương tác người dùng với phần mềm thông qua giao diện đồ họa

Ngữ cảnh : Phát triển ứng dụng tương tác với sự trợ giúp của các agent

Bài toán : Các hệ tương tác có thể thường được xem như tập các agent cộng tác

Agent đặc trưng cho tương tác giữa người và máy chấp nhận dữ liệu vào của người dùng và hiển thị dữ liệu ra Một số agent thì duy trì mô hình dữ liệu của hệ thống và đưa ra chức năng điều hành dữ liệu này Một số khác thì đáp ứng việc thay đổi nhiệm vụ như xử lý lỗi, hoặc giao tiếp với các hệ phần mềm khác Tóm lại kiến trúc này phải đảm bảo :

- Các agent thường xuyên duy trì tình trạng và dữ liệu của mình Tuy nhiên chúng phải cộng tác hiệu quả với nhau để thực hiện nhiệm vụ chung của ứng dụng Đạt được điều này chúng cần cơ chế trao đổi dữ liệu, thông điệp, và sự kiện

- Agent tương tác cung cấp giao diện người dùng riêng của chúng vì giao

- Các hệ thống phát triển theo thời gian Giao diện cũng phải đáp ứng các thay đổi đó Như vậy có thể thay đổi từng agent hoặc mở rộng hệ thống với các agent mới mà không ảnh hưởng tới toàn bộ hệ thống

Evention PAC

JobIcon PAC

Notebook PAC

Netwindow PAC

Netwindow PAC

Evention PAC

có thể giao tiếp với các agent khác

Agent PAC mức đỉnh cung cấp các chức năng hạt nhân của hệ thống Hầu hết các agent PAC khác của hệ thống đều phụ thuộc agent này Hơn thế nữa agent PAC mức đỉnh bao gồm một số phần trong giao diện người dùng mà không thể gắn vào từng nhiệm vụ con riêng lẻ, như các mẹnu, thông báo, các thông tin hiển thị về ứng

dụng, …vv Agent PAC mức đáy biểu diễn các khái niệm ngữ nghĩa của chính nó

mà người dùng có thể tương tác giống như xem một danh sách, cập nhật thông tin một đối tượng, …Agent PAC mức trung gian hoặc biểu diễn liên kết hoặc biểu diễn

mối quan hệ giữa các agent PAC mức thấp hơn

I.1.3 Mẫu thiết kế

Các hệ con của kiến trúc phần mềm cũng như mối quan hệ giữa chúng thường chứa các đơn vị kiến trúc nhỏ hơn, ta mô tả chúng bằng cách sử dụng mẫu thiết kế Mẫu thiết kế cung cấp lược đồ tinh chỉnh hệ con hoặc các thành phần của

hệ phần mềm hoặc mối quan hệ giữa chúng Nó mô tả cấu trúc tuần hoàn phổ biến việc giao tiếp giữa các thành phần nhằm giải quyết bài toán thiết kế chung với ngữ nghĩa cụ thể [9]

Mẫu thiết kế là các mẫu ở cấp độ trung gian Chúng có cấp độ nhỏ hơn so với mẫu kiến trúc Nhưng chúng cũng hướng tới độc lập với mô ngôn ngữ lập trình

cụ thể hoặc mô hình lập trình Các mẫu thiết kế không được ứng dụng hiệu quả trong kiến trúc nền tảng của hệ phần mềm nhưng lại có ảnh hưởng lớn trong kiến trúc các hệ con

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

Mỗi mẫu thiết kế 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: [8]

- Tên mẫu : Tên mẫu 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 " , ta hình dung ngay đến mô hình thiết kế một đối tượng với vai trò “interfacce” của một tập các thành phần nhỏ hơn

- Vấn đề : 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 đó

- Giải pháp : Giải pháp 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

- Hệ quả : 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

I.1.3.2 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ế Mô tả mẫu bao gồm các nội dung như sau : [9]

- 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â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(creational), nhóm cấu trúc(structural) và nhóm hành vi (behavioral)

 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

- 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

- Lý do sử dụng : Mẫu chỉ ra một ngữ cảnh trong đó mô tả bài toán thiết kế

gặp phải và cách thức giải quyết vấn đề của các lớp, đối tượng được thiết kế theo mẫu

- Khả năng áp dụng : Mẫu cho biết có thể áp dụng trong trường hợp nào

Đồng thời, chỉ ra những trường hợp thiết kế chưa tốt mà mẫu có thể khắc phục được cùng với cách nhận biết những lỗi thiết kế đó

- Cấu Trúc : Cấu trúc mẫu là mô tả bằng hình ảnh của các đối tượng được sử

dụng trong thiết kế mẫu

- Các thành phần tham gia : Các lớp/ đối tượng tham gia vào mẫu và vai trò

- Mã nguồn mẫu : Mã mẫu trong một ngôn ngữ cụ thể như C++

- Các mẫu liên quan : Các mẫu liên quan gần gũi với mẫu này, đặc điểm khác

nhau giữa chúng, nên sử dụng mẫu nào ?

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

- Các mẫu tạo : Các mẫu tạo 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)

- Các mẫu cấu trúc : Các mẫu cấu trúc 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 mẫu hành vi : Gồm 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

dụ như quản lý bộ nhớ, tạo đối tượng, đặt tên phương thức, định dạng mã nguồn cho

dễ đọc và sử dụng hiệu quả các thư viện của chúng, …vv [9]

Mỗi Idiom có một tên duy nhất chúng cung cấp phương tiện giao tiếp giữa các nhà phát triển phần mềm Các kỹ sư có kinh nghiệm làm việc với nhau một thời gian có thể chia sẻ suy nghĩ của họ thông quan các idiom Tương phản với mẫu thiết

kế các idiom ít linh động hơn giữa các ngôn ngữ lập trình

I.2 Framework

I.2.1 Khái niệm về Framework

Framework là một hệ con phần mềm hoàn thiện một phần với mục đích như một trường hợp cụ thể Nó định nghĩa kiến trúc họ các hệ con và cung cấp các khối

cơ bản tạo nên chúng Nó cũng định nghĩa nơi có thể đưa vào các hàm cụ thể [18]

Tính cụ thể của framework bao hàm sự tạo thành và phân lớp các lớp đã có Framework ứng dụng trong một miền lĩnh vực cụ thể được gọi là Framework ứng dụng Framework ứng dụng bao gồm yếu tố là Frozen Spot và Hot Spot Trong đó frozen spot định nghĩa kiến trúc tổng thể của hệ phần mềm gồm các thành phần cơ bản và mối quan hệ giữa chúng Nó không bị thay đổi trong bất kỳ phiên bản ứng dụng nào trên framework Còn hot spot biểu diễn các thành phần framework ứng dụng đặc tả riêng từng hệ phần mềm Hot spot được thiết kế chung đáp ứng các yêu cầu đòi hỏi khi phát triển [21]

Hình 1.8 - Framework ứng dụng với các hot spot

Khi tạo ra hệ phần mềm cụ thể từ một framework ứng dụng các hot spot sẽ được thiết kế riêng tùy theo mục đích và yêu cầu của hệ thống Để đạt được việc đáp ứng các khả năng thay đổi đó không chỉ các kỹ thuật của hướng đối tượng như

kế thừa, đa hình mới làm được mà có thể sử dụng các mẫu

Ví dụ : Lớp B đưa ra 3 phương thức M1() M2() và M(3) Trong đó M(1)

dạng phương thức template móc nối gọi đến phương thức M2() và M3()

Phương thức M2() chỉ là phương thức giao diện (tên và truyền tham số)

Hình 1.9 – Mô hình lớp B với 3 phương thức M1(), M2() và M3()

Lớp con B1 cần điều chỉnh M1() bằng cách viết lại M2()

Hình 1.10 - Mô hình lớp con B1 kế thừa lớp B và viết lại phương thức M2()

Khi đó nói rằng hot spot M2() được lấp đầy Như vậy phương thức M1() của lớp B đáp ứng thay đổi nhưng không cần phải thay đổi mã nguồn Ở đây cũng thể

sử dụng M3() thực hiện vai trò hot spot

Như vậy đứng ở góc độ framework ứng dụng thì các mẫu đóng vai trò như các khối cấu thành lên framework, còn đứng ở góc độ mẫu thì các framework lại có vai trò như hệ phần mềm hoàn chỉnh trong một miền ứng dụng cho trước

Phần chính trong thiết kế framework là xác định các frozen spot và các hot spot Đã có một vài phương pháp trợ giúp quy trình xác định các điểm này

I.2.2 Phân loại framework

Để đánh giá về khả năng sử dụng framework người ta đưa ra hai khái niệm : framework hộp trắng và framework hộp đen

I.2.2.1 Framework hộp trắng

Framework hộp trắng bao gồm một vài lớp chưa hoàn chỉnh, đó là các lớp chứa chứa phương thức thực thi mặc định không đầy đủ Sử dụng framework loại này thường dùng các kỹ thuật như tạo ra các lớp con, kế thừa, hay qua các hàm [22] Framework loại này yêu cầu người sử dụng phải hiểu về các thành phần, cấu trúc bên trong nó để có thể sử dụng hiệu quả

Không yêu cầu người sử dụng phải có hiểu biết sâu về thi hành của framework Mở rộng bằng cách cấu thành sắp xếp các đối tượng với nhau và ủy

Một framewok có thể bao gồm cả các hộp trắng và hộp đen Framework có

xu hướng thay đổi theo thời gian Ban đầu thường bao gồm các hộp trắng Sau dần

có sự thay đổi, nó có thể được bổ sung thêm nhiều hộp đen hơn, có nhiều cấu trúc cấu thành và các đối tượng nhỏ hơn Framework tiến triển theo hướng có thể trở thành các môi trường lập trình trực quan (visual programming environments) nơi

mà chương trình có thể được tạo ra bằng cách kết nối tương tác giữa các thành phần được lựa chọn (ví dụ như visual studio của Microsoft hay JavaBeans)

Nhưng xét về mặt chi phí thì người ta vẫn thường thiết kế ra framework hộp trắng và framework hộp trắng thì sử dụng linh hoạt hơn so với framework hộp đen

I.2.3 Mẫu và kiến trúc phần mềm

I.2.3.1 Hệ mẫu

Các mẫu không tồn tại riêng lẻ mà giữa chúng có nhiều phụ thuộc tương hỗ Chúng xen lẫn với nhau gọi là hệ mẫu Một hệ mẫu có thể so sánh với một ngôn ngữ trong đó mẫu tạo ra từ vựng của ngôn ngữ, các luật thực thi và liên kết của chúng tạo ra ngữ pháp Hệ mẫu được định nghĩa như sau “Hệ mẫu của một kiến trúc phần mềm là tập hợp các mẫu cho kiến trúc phần mềm chúng kết hợp với nhau theo các nguyên tắc trong việc thi hành, liên kết và sử dụng thực tế trong phát triển phần mềm.” [9]

Mục đích chính của hệ mẫu là hỗ trợ phát triển hệ phần mềm chất lượng cao Chất lượng cao ở đây bao gồm cả chức năng và phi chức năng Để đạt được mục tiêu này hệ mẫu phải thỏa mãn các yêu cầu sau :

- Phải bao gồm cơ sở mẫu đầy đủ : Mẫu đặc tả kiến trúc hệ phần mềm, mẫu giúp tinh chỉnh kiến trúc, mẫu giúp thực thi kiến trúc trong một ngôn ngữ lập trình cụ thể

- Mô tả tất cả các mẫu một cách đồng bộ

- Mối quan hệ giữa các mẫu phải rõ ràng

- Các mẫu hợp thành được tổ chức hợp lý : Người sử dụng có thể dễ dàng tìm ra mẫu cần thiết

- Hỗ trợ xây dựng hệ phần mềm

- Hỗ trợ sự tiến hóa : Kỹ thuật phát triển, hệ mẫu phải đáp ứng được sự phát triển đó

Mục đích phân loại bài toán là cung cấp cách nhìn hướng bài toán về hệ mẫu Mỗi mẫu được sử dụng cho một bài toán cụ thể Các loại bài toán tương ứng trực tiếp với tình huống thiết kế cụ thể Ta có các loại bài toán như sau :

- Từ Mud đến Cấu trúc : Bao gồm các mẫu hỗ trợ phân rã nhiệm vụ hệ thống tổng thể thành các nhiệm vụ con cộng tác với nhau

- Hệ phân tán : Bao gồm các mẫu cung cấp cơ sở hạ tầng cho hệ thống có các thành phần xử lý đặt tại các nơi khác nhau

- Hệ tương tác : Gồm các mẫu giúp xây dựng hệ thống tương tác giữa người và máy

- Hệ có thể thích nghi : Bao gồm các mẫu cung cấp cơ sở hạ tầng cho các ứng dụng mở rộng và thích nghi khi phát triển và thay đổi yêu cầu chức năng

- Phân rã cấu trúc : Gồm các mẫu hỗ trợ phân rã thích hợp các hệ con, các thành phần phức tạp thành các phần cộng tác

- Tổ chức công việc : Gồm các mẫu định nghĩa các thành phần cộng tác với nhau như thế nào để cung cấp dịch vụ phức tạp

- Điều khiển truy cập : Gồm các mẫu cảnh vệ và điều khiển truy cập dịch vụ hoặc thành phần

- Quản lý : Gồm các mẫu xử lý tập đồng nhất các đối tượng , dịch vụ, thành phần trong một khối thống nhất của chúng

- Giao tiếp : Gồm các mẫu trợ giúp tổ chức giao tiếp giữa các thành phần với nhau

- Xử lý tài nguyên : Gồm các mẫu trợ giúp quản lý chia sẻ thành phần và đối tượng

Một số mẫu không thể gắn cho loại bài toán đơn nào đó, tuy nhiên các mẫu này lại có thể phục vụ một vài bài toán – một bài toán chính và một số bài toán thứ yếu

I.2.3.3 Lựa chọn mẫu

Để lựa chọn một mẫu áp dụng ta thực hiện qua bảy bước sau :

- Đặc tả bài toán : Để có thể tìm ra mẫu trợ giúp giải quyết vấn đề việc đầu tiên phải đặc tả được bài toán cụ thể : Vấn đề chung là gì, nó giải quyết cái gì Ví dụ bài toán cần định nghĩa cấu trúc nền tảng một công cụ soạn thảo văn bản tương tác Hệ thống phải đáp ứng các thư viện giao diện người dùng khác nhau và các kiểu người dùng khác nhau Ví dụ này sẽ xuyên suất trong các bước tiếp theo

- Lựa chọn loại mẫu tương ứng với hoạt động thiết kế thực hiện Trong ví

dụ của ta, ta cần đặc tả một kiến trúc cơ sở của bộ soạn thảo văn bản nên lựa chọn loại mẫu kiến trúc

- Lựa chọn loại bài toán tương ứng với loại chung của bài toán thiết kế Trong trường hợp bộ soạn thảo văn bản này ta lựa chọn loại bài toán của

nó là hệ tương tác có thể lựa chọn mẫu MVC hoặc PAC

- So sánh mô tả bài toán : Bài toán có thể dùng mẫu đơn có thể dùng một

số mẫu kết hợp với nhau Ta lựa chọn giải pháp nào phù hợp nhất với thiết kế bài toán

- So sánh lợi ích và các nguy cơ : Với nguyên tắc cơ bản lợi ích cao nhất

mà nguy cơ thấp nhất

- Lựa chọn biến thể thực thi tốt nhất giải pháp cho bài toán thiết kế Trừ khi

có các vấn đề chưa rõ ràng trong bước 3 và bước 4 nếu không thì tới đây

ta đã lựa chọn được mẫu

- Lựa chọn loại bài toán thay thế : Nếu không có loại bài toán thích hợp hoặc loại bài toán lựa chọn không bao gồm mẫu có thể dùng thì thử chọn loại bài toán tổng quát hóa bài toán thiết kế

I.3 UML

Sự đa dạng của phương pháp phân tích và thiết kế hướng đối tượng đã thúc đẩy phát triển ngôn ngữ mô hình hóa thống nhất(UML) như là một ngôn ngữ để chi tiết hoá, làm trực quan, có cấu trúc và cung cấp những tài liệu đặc tả của các hệ

thống phần mềm cũng như cho các mô hình nghiệp vụ và các hệ thống không phần mềm khác Trước UML, đã có vài ngôn ngữ mô hình, hầu hết chúng chia sẻ một tập hợp các khái niệm đã được công nhận và được biểu diễn khác nhau

UML không chỉ là một ngôn ngữ trực quan để miêu tả, mà nó còn có cả cú pháp và khả năng ngữ nghĩa Các ký pháp của UML đại diện cho cú pháp đồ thị để biểu thị ngữ nghĩa được miêu tả siêu mô hình UML cơ sở

I.3.1 Các góc nhìn của UML

UML cung cấp các mô hình để diễn tả hệ thống Mỗi mô hình chỉ diễn tả hệ thống theo một góc nhìn nhất định UML đưa ra 5 góc nhìn đối với hệ thống Mỗi góc nhìn thực hiện bởi một số biểu đồ : [1]

Góc nhìn thiết kế

Góc nhìn quá trình (trình tự, giao tiếp, máy trạng thái, hoạt động)

I.3.1.2 Góc nhìn thiết kế

Còn gọi là góc nhìn logic, là góc nhìn vào bên trong hệ thống, cho thấy các nhiệm vụ của hệ thống được thiết kế ra sao (thành các lớp, các giao diện, các hợp

tác) Đó là cách nhìn của những người thiết kế hệ thống Với UML, thì sắc thái tĩnh của góc nhìn này thể hiện trong các biểu đồ lớp, các biểu đồ đối tượng Còn sắc thái động của góc nhìn này thể hiện trong các biểu đồ tương tác, các biểu đồ máy trạng thái, các biểu đồ hoạt động

I.3.1.3 Góc nhìn quá trình

Còn gọi là góc nhìn song hành, góc nhìn này phản ánh các lộ trình điều khiển, các quá trình thực hiện, cho thấy sự hoạt động song hành hay đồng bộ của hệ thống Với UML thì góc nhìn này được thể hiện cùng với các biểu đồ như góc nhìn thiết kế

Còn gọi là góc nhìn thành phần, là góc nhìn đối với dạng phát hành của phần mềm (hệ thống vật lý) bao gồm các thành phần và tệp tương đối độc lập; có thể được lắp ráp theo nhiều cách để tạo ra hệ thống chạy được Với UML, sắc thái tĩnh của góc nhìn này được thể hiện bởi các biểu đồ thành phần Còn sắc thái động của góc nhìn này được thể hiện bởi các biểu đồ tương tác, các biểu đồ máy trạng thái, các biểu đồ hoạt động

I.3.1.5 Góc nhìn bố trí

Là góc nhìn topo của phần cứng mà trên đó hệ thống được thực hiện Nó chỉ

rõ sự phân bố, sự sắp đặt các phần của hệ thống vật lý trên các đơn vị phần cứng Với UML thì sắc thái tĩnh của góc nhìn này thể hiện qua các biểu đồ bố trí Còn sắc thái động của góc nhìn này thể hiện qua các biểu đồ tương tác, các biểu đồ máy trạng thái, các biểu đồ hoạt động

I.3.2 Các biểu đồ của UML

Các mô hình trong UML đều có dạng biểu đồ Biểu đồ là một đồ thị trong đó :

• Các nút : là các yếu tố của mô hình có dạng đồ họa hai chiều như là lớp, trạng thái, gói

Gói Trạng thái

Lớp

Hình 1.12 - Một số nút trong các biểu đồ

• Các đường là các yếu tố của mô hình có dạng đồ họa tuyến tính, như

là các liên kết, khái quát hóa, phụ thuộc, v.v…

Biểu đồ trình tự Biểu đồ giao tiếp Biểu đồ bao quát tương tác Biểu đồ máy thời khắc

Hình 1.14 - Phân loại biều đồ trong UML 2.0

UML 1.x có 9 loại biểu đồ UML 2.0 mở rộng thành 13 loại biểu đồ Chúng được phân thành hai nhóm : Các biểu đồ về cấu trúc và các biểu đồ về hành vi Các biểu đồ này cung cấp nhiều quan điểm về hệ thống đang phát triển Mô hình nền cơ

sở sẽ tích hợp các nghệ thuật này để hệ thống cố định có thể được phân tích và xây dựng Các mô hình có thể được dùng cho các phép phân tích và thiết kế hướng đối tượng nói chung có thể được phân loại thành mô hình tĩnh và mô hình động Các

mô hình tĩnh mô tả kiến trúc của ứng dụng, các tổ chức dữ liệu và chức năng mức cao, chẳng khác gì nội dung thông tin rộng Các View tĩnh bao gồm các biểu đồ lớp, các biểu đồ gói, các biểu đồ thành phần và các biểu đồ triển khai Các View động bao gồm các Use Case, các biểu đồ Scenario và các biểu đồ Cộng tác cùng với các

diện mạo hành vi của các đối tượng riêng lẻ dùng biểu đồ trạng thái [1]

I.3.2.1 Nhóm biểu đồ về cấu trúc

Đây là các biểu đồ phản ánh sắc thái tĩnh của hệ thống Có sáu loại biểu đồ thuộc nhóm này

Biểu đồ lớp

Biểu đồ lớp phô bày cấu trúc tĩnh của các lớp trong hệ thống Một biểu đồ lớp mô tả một kiến trúc diện mạo bên ngoài của ứng dụng Nó là sự thể hiện của các lớp có thể, và các mối quan hệ của chúng Các biểu đồ lớp chi tiết biểu hiện các chi tiết về việc thiết kế, chúng bao gồm các thuộc tính và các kiểu, các phương thức và các kí hiệu Biểu đồ lớp được xem là tĩnh vì cấu trúc mà nó mô tả luôn luôn đúng vào mọi lúc trong chu trình sống của hệ thống

Biểu đồ đối tượng

Biểu đồ đối tượng phô bày các đối tượng thay cho các lớp Có thể nói đó là “ảnh chớp” của hệ thống tại một thời điểm, cho thấy các đối tượng nào đang tồn tại và hoạt động

Biểu đồ thành phần

Một biểu đồ thành phần cho thấy những thành phần ứng dụng và cách mà chúng tương tác với nhau Nó miêu tả một khía cạnh tĩnh của hệ thống Biểu đồ các thành phần liên quan tới các biểu đồ lớp trong một thành phần liên kết tiêu biểu tới

một hoặc nhiều lớp, giao diện hoặc cộng tác Các thành phần được sử dụng để mô hình những phần có thể thực thi và các ứng dụng và mối quan hệ của chúng theo khía cạnh thời gian vận hành

Biểu đồ bố trí

Biểu đồ này cho biết kiến trúc vật lý của hệ thống trong giới hạn của các Nút

và các mối quan hệ của chúng Các biểu đồ triển khai thường liên quan đến các biểu

đồ thành phần trong đó một Nút nói chung sẽ bao quanh một hoặc một số thành phần Các điều kiện sẽ được cung cấp để nhận dạng các thành phần sẽ được thực thi trên các máy

Biểu đồ gói

Gói là một hình thức gom nhóm các phần tử, phần tử ở đây có thể là các lớp, các ca sử dụng, các thành phần v.v…

Biểu đồ cấu trúc đa hợp

Là biểu đồ diễn tả cấu trúc bên trong của một loài, như lớp, gói, giao diện, hợp tác v.v…, chỉ ra điểm tương tác của loài đó với các thành phần còn lại của hệ thống, cũng như chi ra vai trò của các bộ phận tham gia thực hiện hành vi chung của loài đó

để trình diễn các cách dùng có thể của ứng dụng Biểu đồ cũng chỉ cho thấy mối quan hệ giữa các ca sử dụng và do đó thành lập lên các mối quan hệ giữa các chức năng ứng dụng khác nhau Các biểu đồ ca sử dụng cũng minh hoạ cách thức mà các

thực thể bên ngoài môi trường tương tác với ứng dụng, các thực thể này có là các thành phần, các ứng dụng, hoặc người dùng bên ngoài khác hay không

Hình 1.15 – Biểu đồ Ca sử dụng

Biểu đồ trình tự

Biểu đồ này trình bày một số đối tượng với các thông điệp được chuyển giao giữa chúng, đặc biệt làm rõ trình tự các thông điệp chuyển giao này dọc theo trục thời gian (trục thẳng đứng) Biểu đồ trình tự dùng để diễn tả một sự hợp tác (hay tương tác) của một nhóm đối tượng

Biểu đồ giao tiếp

Biểu đồ giao tiếp cũng trình bày một sự hợp tác (tương tác) của một nhóm đối tượng như là biểu đồ trình tự song biểu đồ giao tiếp lại nhấn mạnh tới bối cảnh của sự hợp tác Nó cũng cho mọt nhóm các đối tượng cùng với các kết nối giữa chúng, như trong biểu đồ đối tượng, nhưng vẽ thêm các thông điệp dọc theo các kết nối đó Các thông điệp được đánh số để phân biệt trước sau

Biểu đồ hoạt động

Biểu đồ hoạt động trình bày luồng dịch chuyển từ hành động này sang hành

song song Thông thường thì biểu đồ hoạt động được dùng để đặc tả một thao tác của một lớp, song nó cũng có thể được dùng để mô tả các luồng hoạt động khác, như là cac sử dụng hay tương tác

Biểu đồ bao quát tương tác

Đây là một biến thể của biểu đồ hoạt động, mà trong đó các nút không những

là các hành động, mà còn có thể là các biểu đồ tương tác Nó cho ta một cái nhìn bao quát đối với một tương tác phức tạp

Framework là một khái niệm gần gũi hơn khi cần phát triển một ứng dụng cụ thể Framework có thể triển khai các ý tưởng về mẫu như đã nêu ở trên nhằm giúp xây dựng các phần mềm thuộc miền lĩnh vực nào đó Cùng với mẫu UML cung cấp

cả về mặt phương pháp, công cụ và kỹ thuật trong việc triển khai xây dựng hệ phần mềm

II CHƯƠNG 2 – XML VÀ KHẢ NĂNG ỨNG DỤNG

XÂY DỰNG FRAMEWORK DỰA WEB

II.1.1 Khái niệm chung về XML

Trước hết ta nói về SGML, SGML viết tắt của cụm từ Standard Generalized Markup Languag là một ngôn ngữ đánh dấu tiêu chuẩn mở rộng dùng để thêm đuôi vào văn bản nhằm báo hiệu rằng văn bản đã được định dạng SGML được thừa nhận là chuẩn quốc tế vào năm 1986 SGML được sử dụng để xây dựng những tài liệu như sách vở, báo cáo, hay cẩm nang tham khảo….Những tài liệu này sẽ được chuyển thành dạng thức biểu diễn được và sau đó gởi chúng ra thiết bị xuất như máy in, màn hình Vào giữa những năm 1990 từ chuẩn SGML người ta đưa ra một tập các thẻ đánh dấu sử dụng để tạo ra HTML (Hypertext Markup Language), một ngôn ngữ đánh dấu siêu văn bản sử dụng như tài liệu web cho đến nay Nhưng HTML chỉ gồm các thẻ đánh dấu tiêu đề, danh sách, các đoạn, hoặc các nội dung có định dạng đơn giản, nó không thể mô tả ngữ nghĩa của nội dung Thế nên XML đã

ra đời nhằm khắc phục các hạn chế trên

XML là một tập con của SGML (Standard Generalized Markup Language) được W3C (World Wide Web Conrotium) định nghĩa XML được thiết kế để thực hiện lưu trữ dữ liệu và phát hành trên các Web site không chỉ dễ dàng quản lý hơn,

mà còn có thể trình bày đẹp mắt hơn XML cho phép những người phát triển Web định nghĩa nội dung của các tài liệu bằng cách tạo đuôi mở rộng theo ý người sử dụng, không giống như HTML (Hypertext Markup Language), được khóa thành một tập các đuôi mở rộng theo chuẩn công nghiệp [6]

Đơn vị cơ bản của tài liệu XML là element Element chứa văn bản, đường dẫn đồ họa, dữ liệu bảng, thậm chí cả các element khác Khi tạo ra mô hình thông tin cần phải tạo ra kiến trúc thông tin Kiến trúc mô tả cách các element được sử dụng và chúng ăn khớp với nhau như thế nào [6]

- Element chính bao gồm tất cả các element khác gọi là root element

- Element chứa element khác gọi là element cha, element được chứa bên trong nó gọi là element con

- Một element có thể là cha của element này và là con của element kia

- Các element cùng một cha gọi là các element anh em

Mỗi element thường bao gồm hai thẻ (tag) một thẻ mở và một thẻ đóng Thẻ

mở bao gồm tên đặt trong một cặp ngoặc nhọn “<ten_the>” Thẻ đóng bao gồm chính tên đó đặt trong một cặp ngoặc nhọn với dấu gặch chéo đứng trước

“</ten_the>” Nội dung của element là tất cả những gì nằm giữa thẻ mở và thẻ đóng

Ví dụ : Tài liệu XML mô tả nội dung của một luận văn như sau :

<luan_van>

Các luật element :

- Mỗi thẻ mở phải có một thẻ đóng tương ứng, hoặc phải chính là thẻ đóng Các thẻ không được chồng lên nhau; các element phải lồng nhau hợp lệ

- Tài liệu XML chỉ có một root element

- Tên của element phải tuân theo quy ước đặt tên của XML

- Tính chính xác của thẻ Nghĩa là thẻ của XML có tính đến chữ hoa, chữ thường

- XML vẫn giữ khoảng trắng trong PCDATA

Kiểm tra tính hợp lệ của tài liệu XML là bước tiếp theo sau khi tài liệu XML

đã well formed Tính hợp lệ này được kiểm tra bằng DTD hoặc XML Schema Điểm khác biệt lớn nhất giữa DTD và Schema là DTD - một file văn bản mã ASCII với cú pháp đơn giản trong khi Schema lại là một file văn bản mã ASCII sử dụng cú pháp XML Do đó Schema tận dụng được các ưu điểm của tài liệu XML đem lại nên nó chạy tốt hơn Nhưng DTD thì lại được sử dụng rộng rãi và hỗ trợ nhiều hơn Trong tương lai xu hướng sử dụng Schema phổ biến hơn [5]

II.1.2 XML Schema

II.1.2.1 Khái niệm chung

XML Schema là một ngôn ngữ định nghĩa lược đồ biểu diễn theo cú pháp XML được W3C đưa ra vào ngày 02/05/2001, với mục đích mô tả cấu trúc và các ràng buộc nội dung của tài liệu XML Ngôn ngữ XML Schema biểu diễn các dàng buộc theo luật hoặc mô hình hóa cấu trúc áp dụng cho lớp các tài liệu XML Theo

đó các ứng dụng của schema có thể phân thành các loại : kiểm hợp dữ liệu, lập tài liệu, truy vấn, binding, và editing [15]

- Kiểm hợp dữ liệu : Kiểm hợp dữ liệu là cách sử dụng phổ biến nhất

trong thế giới XML Khi nhận được dữ liệu XML, trước khi đưa vào sử dụng cần phải kiểm hợp dữ liệu XML nhận được vì dữ liệu được tạo ra đó

có thể từ biên tập thủ công Các loại schema khác nhau thực hiện kiểm hợp dữ liệu theo các cách khác nhau Kiểm hợp dữ liệu của schema có thể xem như “tường lửa” kiểm tra XML

- Documention : XML Schema thường xuyên được sử dụng để dẫn chứng

lại từ vựng XML Schema cung cấp một mô tả chính quy từ vựng XML một cách chính xác và ngắn gọn Từ đó đem lại :

 Máy có thể đọc được và đưa ra các chỉ dẫn tài liệu

 Người có thể đọc được

 Có thể đưa ra các khung nhìn đồ họa để dễ dàng hiểu được tài liệu XML

- Hỗ trợ truy vấn : Phiên bản đầu tiên của XPath và XSLT được đưa ra để

làm việc mà không cần hiểu rõ ràng về cấu trúc tài liệu cần xử lý Nhưng khi đó sẽ cho hiệu năng không cao Các tri thức về cấu trúc tài liệu có thể cải thiện được đáng kể hiệu năng xử lý Do đó phiên bản thứ hai của XPath, XSLT và phiên bản đầu tiên của Xquery dựa trên khả năng của XML Schema

- Data Binding : Kiểm soát và gắn kết dữ liệu

II.1.2.2 Các thành phần lược đồ của XSD Schema

XML Schema là một tài liệu XML, có đơn vị cơ bản nhất để tạo thành là element Cấu trúc cơ bản một element là [15]:

<element

abstract = boolean : false

block = (#all | List of (extension | restriction | substitution))

{any attributes with non-schema namespace }>

Content: (annotation?, ((simpleType | complexType)?, (unique | key | keyref)*))

</element>

W3C đưa ra 13 thành phần lược đồ như sau :