Nghiên cứu xây dựng hệ thống trợ giúp bài giảng theo công nghệ hướng đối tượng và ngôn ngữ XML

Nhu cầu có một hệ thống trợ giúp lập bài giảng cho giảng viên, giáo viên là cần thiết và vì thế tôi đã chọn đề tài “Nghiên cứu xây dựng Hệ thống Trợ giúp Lập bài giảng theo Công nghệ Hướ

Danh mục các thuật ngữ i

Danh mục các bảng và hình vẽ ii

Mở đầu 1

Chương 1: Qui trình phát triển phần mềm hướng đối tượng 3

1.1 Giới thiệu qui trình phát triển phần mềm hướng đối tượng 3

1.1.1 Đặc điểm của qui trình RUP 4

1.1.2 Kiến trúc của RUP 5

1.2 Các luồng công việc cơ bản 7

1.2.1 Mô hình hóa nghiệp vụ .7

1.2.2 Xác định các yêu cầu hệ thống .9

1.2.3 Phân tích 14

1.2.4 Thiết kế 19

Chương 2: Ngôn ngữ định dạng mở rộng 25

2.1 Giới thiệu chung 25

2.2 Cấu trúc của tài liệu XML 26

2.2.1 Phần khởi đầu .26

2.2.2 Thân tài liệu 28

2.3 Định nghĩa kiểu tư liệu – DTD (Document Type Definition) 29

2.3.1 Định nghĩa DTD nội 30

2.3.2 Định nghĩa DTD ngoại 32

2.3.3 Thực thể và thuộc tính DTD 33

2.4 Không gian tên của XML Lược đồ XML (XML Schema) 36

2.4.1 Không gian tên của XML 36

2.4.2 Lược đồ XML (XML Schema) 37

2.5 Bảng định kiểu CSS (Cascading Style Sheet) 42

2.6 Phân tích tài liệu XML theo mô hình DOM (Document Object Model) 43

2.7 XPath 45

2.8 Một số đánh giá về XML 45

2.7.1 Ưu điểm 46

2.7.2 Nhược điểm 46

Chương 3: Phân tích và thiết kế hệ thống trợ giúp lập bài giảng 48

3.1 Mô hình nghiệp vụ – Mô hình use-case 48

3.1.1 Mô hình nghiệp vụ 48

3.2.1 Chức năng “Tìm môn học” 61

3.2.2 Nhóm chức năng “Soạn đề cương môn học” 65

3.2.3 Nhóm chức năng “Soạn nội dung bài giảng” 70

3.3 Chương trình thử nghiệm 80

3.3.1 Giải pháp công gnhệ 80

3.3.2 Thiết kế tài liệu XML 81

3.3.3 Một số giao diện chương trình 85

Kết kuận 91

Tài liệu tham khảo 92

RUP Rational Unified Process

SGML Standard Generalized Markup Language

PCDATA Parsed Character Data

FPI Formal Public Identifier

CSS Cascading Style Sheet

TIM Telecommunication Interchange Markup PDML Product Data Markup Language

1 Danh mục các bảng

Bảng 2.1: Tóm tắt cách sử dụng các ký tự đại diện

Bảng 2.2: Các kiểu dữ liệu của thuộc tính

Bảng 2.3: Các thiết lập mặc định cho thuộc tính

Bảng 2.4: Các kiểu dữ liệu đơn giản nội tại

Bảng 2.5: Một số thuộc tính cơ bản

Bảng 2.6: Các kiểu nút trong mô hình DOM

Bảng 2.7: Một số tham chiếu đường dẫn đơn giản

2 Danh mục các hình vẽ

Hình 1.1: Các pha và các bước lặp trong qui trình RUP

Hình 2.1: Tài liệu XML theo cấu trúc hình cây

Hình 3.1: Sơ đồ tiến trình nghiệp vụ “Soạn đề cương môn học”

Hình 3.2: Mô hình miền của hệ thống

Hình 3.3: Mô hình use-case mức cao

Hình 3.4: Mô hình gói use-case “Soạn đề cương môn học”

Hình 3.5: Mô hình gói use-case “Soạn nội dung bài giảng”

Hình 3.6: Biểu đồ cộng tác thực thi use-case “Tìm môn học”

Hình 3.7: Biểu đồ lớp thiết kế use-case “Tìm môn học”

Hình 3.8: Biểu đồ cộng tác thực thi use-case “Tạo đề cương mới” Hình 3.9: Biểu đồ cộng tác thực thi use-case “Xem đề cương môn học” Hình 3.10: Biểu đồ cộng tác thực thi use-case “Sửa đề cương”

Hình 3.11: Biểu đồ cộng tác thực thi use-case “Xoá đề cương”

Hình 3.12: Biểu đồ cộng tác thực thi use-case “Tìm kiếm đề cương”

Hình 3.13: Mô hình phân tích gói use-case “Soạn đề cương môn học” Hình 3.14: Biểu đồ lớp thiết kế use-case “Soạn đề cương môn học”

Hình 3.16: Biểu đồ cộng tác thực thi use-case “Xem nội dung bài giảng” Hình 3.17: Biểu đồ cộng tác thực thi use-case “Sửa nội dung”

Hình 3.18: Biểu đồ cộng tác thực thi use-case “Xóa nội dung”

Hình 3.19: Biểu đồ cộng tác thực thi use-case “Tìm nội dung”

Hình 3.20: Mô hình phân tích gói use-case “Soạn nội dung bài giảng” Hình 3.21: Biểu đồ lớp thiết kế use-case “Soạn nội dung bài giảng” Hình 3.22: Cấu trúc đề cương môn học theo mô hình DOM

Hình 3.23: Cấu trúc nội dung bài giảng theo mô hình DOM

Hình 3.24: Giao diện đăng nhập hệ thống

Hình 3.25: Giao diện soạn đề cương mới

Hình 3.26: Giao diện danh sách đề cương môn học

Hình 3.27: Giao diện danh sách bài giảng

Hình 3.28: Giao diện danh sách chương và thêm chương mới

Hình 3.29: Giao diện soạn nội dung mục mới

Soạn bài giảng là một trong những công việc không thể thiếu đối với bất kỳ một giảng viên hay giáo viên nào ở trong các đơn vị đào tạo Mỗi bài giảng thể hiện trách nhiệm, thể hiện tâm huyết của người tạo ra nó Mặt khác, nội dung mỗi bài giảng môn học không phải là tùy theo ý người soạn mà phải tuyệt đối tuân theo đề cương môn học đã được phê duyệt và phải tham khảo ý kiến của tổ bộ môn Vì vậy, nội dung mỗi bài giảng thường phải được cập nhật, chỉnh sửa cho phù hợp với yêu cầu mới Điều đó cho thấy việc chuẩn bị bài giảng của mỗi cán bộ giảng dạy là khá vất vả Ngoài ra, các tổ bộ môn còn phải theo dõi, giám sát nội dung giảng dạy của mỗi môn học Nhu cầu có một hệ thống trợ giúp lập bài giảng cho giảng viên, giáo

viên là cần thiết và vì thế tôi đã chọn đề tài “Nghiên cứu xây dựng Hệ thống Trợ giúp Lập bài giảng theo Công nghệ Hướng đối tượng và Ngôn ngữ XML” để làm

Nội dung chính của luận văn gồm có 3 chương:

ƒ Chương 1: Trình bày tóm tắt về qui trình phát triển phần mềm hướng đối

tượng, mà cụ thể ở đây là qui trình RUP, trong đó đi sâu vào bốn luồng công việc cơ bản là Mô hình hóa nghiệp vụ, Xác

định các yêu cầu hệ thống, Phân tích và Thiết kế

ƒ Chương 2: Trình bày một số vấn đề cơ bản về ngôn ngữ định dạng mở

rộng - XML, đó là về cấu trúc của tài liệu XML, về việc định nghĩa các thẻ theo mục đích sử dụng, khái niệm DTD, thực thể, lược đồ XML, mô hình DOM, Từ đó nêu bật điểm khác biệt giữa XML và HTML, những ưu điểm cũng như nhược

điểm của XML

thống Trợ giúp Lập bài giảng Công việc cụ thể được tiến hành là:

o Mô tả hoạt động nghiệp vụ của các công việc Soạn đề cương

môn học, Soạn nội dung bài giảng

o Lập mô hình use-case từ mức tổng quát đến chi tiết

o Phân tích, thiết kế hệ thống để đưa ra các biểu đồ lớp thiết kế

o Sử dụng ngôn ngữ lập trình PHP (hỗ trợ cho lập trình hướng đối tượng và xử lý tài liệu XML) để cài đặt thử nghiệm một số module

Cuối cùng là kết luận và hướng phát triển tiếp theo của đề tài

Chương 1 Qui trình phát triển phần mềm

hướng đối tượng

Hướng đối tượng là thuật ngữ hiện đang thông dụng trong công nghiệp phần mềm Phương pháp tiếp cận hướng đối tượng là phương pháp tiếp cận mới nhất để phát triển hệ thống phần mềm Hệ thống được xây dựng trên cơ sở các đối tượng liên kết với nhau Các đối tượng được tổ chức thành lớp đối tượng có cùng cấu trúc

và hành vi Các lớp mới có thể được tạo ra trên cơ sở kế thừa các lớp đã có bằng cách bổ sung thêm một số đặc trưng mới Mỗi đối tượng bao gói trong nó dữ liệu và

xử lý nên hoạt động của mỗi đối tượng manh tính địa phương và sự sửa đổi nó không làm ảnh hưởng đến các đối tượng khác Đây chính là hai đặc điểm nổi trội

nhất của phương pháp tiếp cận hướng đối tượng, đó là kế thừa và bao gói thông tin

Các đối tượng được ghép nối với nhau thông qua việc gửi và nhận thông điệp, các chức năng hệ thống được biểu diễn thông qua cộng tác của các đối tượng [1] Sức mạnh của tiếp cận hướng đối tượng là việc tách và nhập được thực hiện nhờ tập phong phú các cơ chế tích hợp của chúng, khả năng thống nhất cao những cái nó đã

được tách ra để xây dựng các thực thể phức tạp từ các thực thể đơn giản Phát triển phần mềm hướng đối tượng sẽ cho các phần mềm thương mại chất lượng cao: tin cậy, dễ bảo trì, dễ sử dụng lại, dễ dàng tăng qui mô,…phù hợp với yêu cầu ngày càng tăng về chất lượng phần mềm của người sử dụng [2]

1.1 Giới thiệu qui trình phát triển phần mềm hướng đối tượng

Qui trình phát triển một phần mềm thông thường là một tập hợp các hoạt

động cần thiết với mục đích chuyển các yêu cầu của người dùng thành hệ thống phần mềm đáp ứng các yêu cầu đó

Hiện nay có rất nhiều qui trình phát triển phần mềm khác nhau được sử dụng rộng rãi tuỳ thuộc vào qui mô của vấn đề và cách thức làm việc của tổ chức phát triển như: Waterfall Process, OPEN Process, Object-Oriented Software Process, Unified Process, … Mỗi qui trình đều có những ưu/nhược điểm riêng nhưng nổi bật nhất và có xu hướng ngày càng được sử dụng rộng rãi nhất là Unified Process của hãng Rational (còn được gọi là qui trình RUP - Rational Unified Process) để phát

chuyên biệt hoá cho mỗi lớp lớn của các hệ thống phần mềm, cho các lĩnh vực ứng dụng khác nhau, các kiểu tổ chức khác nhau, các cấp độ hoàn thiện khác nhau, các

cỡ dự án khác nhau Theo qui trình này, hệ thống phần mềm sẽ được xây dựng dựa trên các thành phần phần mềm kết nối với nhau thông qua các giao diện đã được

định nghĩa trước Qui trình này sử dụng Ngôn ngữ Mô hình hoá Thống nhất (UML- Unified Modeling Language) để thiết các hệ thống phần mềm [11, 12]

Qui trình RUP mô tả ai (Who) đang làm gì (What), làm như thế nào (How)

và khi nào (When) thông qua việc xác định bốn thành phần sau [4, 11, 12]:

ắ Worker – Who: vị trí mà con người được gán vào và được chấp nhận Nó xác

định công việc và trách nhiệm của mỗi cá nhân hoặc một tập hợp các cá nhân làm việc cùng nhau Chẳng hạn: trưởng dự án (Project Manager), phân tích viên hệ thống (System Analyst), người kiểm thử (Tester),…

ắ Hoạt động – How: hoạt động của một worker là một tập các công việc có

mục đích rõ ràng Chẳng hạn: việc lập kế hoạch của trưởng sự án, việc tìm các use-case và các actor cho hệ thống của phân tích viên hệ thống,…

ắ Chế tác – What: những thông tin được tạo lập, được sản xuất, được thay đổi,

hay được sử dụng bởi các worker khi phát triển hệ thống Chẳng hạn: mô hình use-case (use-case model), mô hình thiết kế (design model), các tài liệu (document), các thành phần thực thi…

ắ Luồng công việc – When: mô tả cách thức tiến hành các hoạt động theo trình

tự và vai trò của mỗi worker

1.1.1 Đặc điểm của qui trình RUP [1, 4, 11]

ắ Là qui trình hướng use-case: thay cho cách mô tả chức năng điều khiển

truyền thống, RUP sử dụng mô hình Use Case để mô hình hoá chức năng cho từng loại người sử dụng Ngoài ra, các use-case còn đóng vai trò dẫn dắt qui trình phát triển đến các bước phân tích, thiết kế, cài đặt và kiểm chứng Dựa trên use-case, người phát triển tạo ra một loạt các mô hình thiết kế và cài đặt thực hiện các use-case sao cho mỗi mô hình này phù hợp với mô hình use-case Người kiểm tra sẽ kiểm tra các cài đặt để đảm bảo rằng các thành phần của mô hình cài đặt đã được cài đặt đúng các use-case Qui trình phát triển tuân theo một dòng, nó tiếp diễn thông qua một loạt các luồng công việc (workflow) được điều khiển bởi use-case

ắ Tập trung vào kiến trúc phần mềm: kiến trúc là cái nhìn tổng thể về thiết kế

của hệ thống Qui trình RUP cung cấp phương hướng để từng bước xác định kiến trúc của hệ thống, đáp ứng các yêu cầu cho việc thay đổi và tái sử dụng phần mềm Qui trình xác định mối liên hệ giữa kiến trúc với use-case vì mọi sản phẩm đều bao gồm chức năng và hình thức thể hiện, chức năng tương ứng với use-case còn hình thức thể hiện tương ứng với kiến trúc Do đó cần

có sự đan xen giữa use-case và kiến trúc, người ta gọi đó là vấn đề “con gà và quả trứng” Kiến trúc phải được xây dựng sao cho đáp ứng tất cả các chức năng trong hiện tại và tương lai Việc xác định kiến trúc đòi hỏi phải xác

định những chức năng cốt yếu của hệ thống, đó là các use-case chính Phát triển các use-case này (được thực hiện dưới dạng các hệ thống con, các lớp,

và các thành phần), các chi tiết thêm về kiến trúc sẽ được khám phá Từ đó lại dẫn đến sự tăng trưởng của các use-case Quá trình này tiếp diễn cho dến khi kiến trúc trở nên tương đối ổn định

ắ Là qui trình lặp và tăng dần: phát triển một phần mềm phức tạp ngoài việc

đòi hỏi thời gian còn đòi hỏi kỹ thuật phân chia hệ thống thành những phần nhỏ Qui trình RUP gồm nhiều bước lặp để xây dựng phần mềm Mỗi tập chức năng của hệ thống được phát triển trong một bước lặp và tiến dần đến

sự hoàn chỉnh về tổng thể Các bước lặp được thực hiện có kế hoạch và được kiểm soát Đó là một trình tự các hoạt động được lên kế hoạch theo một tiêu chuẩn xác định và cho kết quả là một xuất phẩm của phần mềm Trong mỗi bước lặp, người phát triển chọn một nhóm chức năng rồi tiến hành phân tích, thiết kế, cài đặt và kiểm thử các chức năng này Nếu bước lặp đáp ứng được yêu cầu đề ra thì chuyển sang bước lặp mới với một nhóm các chức năng kế tiếp

1.1.2 Kiến trúc của RUP

RUP là một qui trình lặp lại một chuỗi các vòng đời (lifecycle) để xây dựng

hệ thống Mỗi vòng đời cho kết quả là một xuất phẩm (release) cho khách hàng bao gồm mã nguồn trong các thành phần có thể biên dịch và thực thi Mỗi vòng đời

được chia thành bốn pha (phase) [1, 2, 3]:

ắ Khởi đầu hay còn gọi là Khảo sát khả thi (Inception): xác định phạm vi dự

án, các tài nguyên cần thiết và phác thảo chức năng cho người sử dụng

ắ Chi tiết (Elaboration): phân tích vấn đề, lập kế hoạch dự án, đánh giá rủi ro

và xác định kiến trúc hệ thống

ắ Xây dựng (Construction): phát triển các thành phần, tích hợp vào sản phẩm và

kiểm chứng các chức năng

ắ Chuyển giao (Transition): chuyển giao sản phẩm đến khách hàng, huấn luyện

khách hàng sử dụng, bảo trì đồng thời điều chỉnh một số chức năng cần thiết Mỗi pha lại bao gồm nhiều bước lặp (iteration) thực hiện một dãy các công việc còn gọi là luồng công việc (workflow) Các luồng công việc cơ bản là: mô hình hóa nghiệp vụ (business modeling), xác định yêu cầu (requirements), phân tích (analysis), thiết kế (design), cài đặt (implementation), kiểm thử (test), triển khai (deployment) Ngoài ra còn có các luồng công việc: hỗ trợ quản lý dự án (project management), quản lý cấu hình và thay đổi (configuration and change management), quản lý môi trường (environment) Tuy nhiên, bước lặp trong mỗi pha không giống nhau về nội dung cũng như khối lượng thực hiện các công việc này [12]

Hình 1.1 : Các pha và các bước lặp trong qui trình RUP

1.2.1 Mô hình hoá nghiệp vụ [1, 4]

Việc mô hình hoá nghiệp vụ nhằm mục đích nắm bắt qui trình hoạt động của

tổ chức nơi cần xây dựng hệ thống phần mềm bao gồm qui trình nghiệp vụ và cách thức thực hiện, đối tượng thực hiện nghiệp vụ và đối tượng thao tác nghiệp vụ, các tác nhân bên ngoài có giao tiếp và ảnh hưởng đến hoạt động của tổ chức

Để làm được điều đó cần xác định phạm vi và chức năng của hệ thống cần nghiên cứu bằng cách liệt kê các chức năng mà hệ thống phải thực hiện, chỉ ra mối quan hệ của nó với môi trường (các hệ thống khác đang tồn tại và những người tương tác với hệ thống) thông qua việc sử dụng các chức năng của hệ thống Sau đó

từ các chức năng của hệ thống mà qua đó con người và các hệ thống khác sử dụng cần xác định các use-case nghiệp vụ Mô tả nội dung của các use-case này để hiểu

được nội dung các dịch vụ mà hệ thống cần cung cấp Các công việc này được trợ giúp bằng việc xây dựng mô hình miền (domain model) và mô hình nghiệp vụ (business model)

a Xây dựng mô hình miền

Một mô hình miền nắm bắt phần lớn các kiểu đối tượng quan trọng nhất trong ngữ cảnh của hệ thống Các đối tượng miền thể hiện những vật đã tồn tại hoặc các sự kiện diễn ra trong mô trường mà hệ thống làm việc Có ba dạng lớp miền

điển hình:

ắ Các đối tượng nghiệp vụ thể hiện những vật được thao tác trong một nghiệp

vụ

ắ Các đối tượng thế giới thực và các khái niệm mà một hệ thống cần theo dõi

ắ Các sự kiện sẽ hoặc đã xuất hiện

Mô hình miền được mô tả trong các biểu đồ lớp của UML Các biểu đồ minh hoạ cho khách hàng, người dùng, người thẩm định, những người phát triển các lớp miền và làm thế nào chúng liên quan đến nhau thông qua các mối liên kết

Những miền có cỡ vừa thường cần từ 10 đến 50 lớp, những miền lớn hơn có thể đòi hỏi nhiều lớp hơn Các lớp được giữ lại như những định nghĩa trong từ điển thuật ngữ Đối với những miền nghiệp vụ rất nhỏ thì việc phát triển một mô hình đối tượng cho miền là không cần thiết và thay vào đó một từ điển thuật ngữ là đủ Từ

điển thuật ngữ và mô hình miền giúp cho những người dùng, khách hàng, người phát triển và những người có liên quan khác thống nhất trong việc định nghĩa các khái niệm và các cách diễn đạt giữa họ

Các lớp miền và từ điển thuật ngữ được sử dụng khi phát triển các mô hình use-case và mô hình phân tích Cụ thể, chúng được sử dụng khi mô tả các use-case, khi thiết kế giao diện người dùng, để gợi ý các lớp nội tại đối với hệ thống trong quá trình phân tích

b Xây dựng mô hình nghiệp vụ

Mô hình nghiệp vụ bao gồm mô hình use-case nghiệp vụ (business use-case model) và mô hình đối tượng nghiệp vụ (business object model)

Một mô hình use-case nghiệp vụ mô tả các quá trình nghiệp vụ của một công

ty dưới dạng các use-case nghiệp vụ và các actor nghiệp vụ tương ứng với quá trình nghiệp vụ và khách hàng Mô hình này thể hiện hệ thống nghiệp vụ từ quan điểm sử dụng và chỉ ra làm thế nào nó cung cấp được giá trị đối với người dùng Mô hình use-case nghiệp vụ được mô tả trong các biểu đồ use-case của UML

Một mô hình đối tượng nghiệp vụ sử dụng chủ yếu biểu đồ lớp trong UML bao gồm đơn vị tổ chức và thực thể nghiệp vụ, trong đó đơn vị tổ chức là đơn vị cấu trúc của tổ chức (phòng, ban hay bộ phận trong tổ chức) còn thực thể nghiệp vụ là

đối tượng thao tác của nghiệp vụ (thường là dữ liệu, các loại hồ sơ) Nó mô tả worker nào sử dụng tài nguyên, tài liệu gì của tổ chức và sử dụng như thế nào để thực hiện nghiệp vụ cụ thể Mỗi sự thực hiện của một use-case nghiệp vụ có thể

được thể hiện trên các biểu đồ tương tác và biểu đồ hoạt động của UML

Mô hình nghiệp vụ được phát triển theo hai bước:

ắ Chuẩn bị một mô hình nghiệp vụ để xác định các actor đối với nghiệp vụ và các use-case nghiệp vụ mà actor sử dụng

ắ Phát triển một mô hình đối tượng nghiệp vụ chứa đựng những worker, các thực thể nghiệp vụ, các đơn vị tổ chức cùng nhau thực hiện các use-case nghiệp vụ

Có thể nhận thấy rằng, mô hình miền là một trường hợp đặc biệt của mô hình nghiệp vụ đầy đủ vì trong mô hình miền chỉ tập trung vào các vật, đó là các lớp miền hoặc cá thực thể nghiệp vụ mà worker sẽ phải làm việc cùng

Với mục đích mô tả bối cảnh của một hệ thống và nội dung hoạt động nghiệp

vụ của hệ thống nên tuỳ theo yêu cầu của từng bài toán cụ thể mà ta có thể xây dựng hoặc một mô hình miền, hoặc một mô hình nghiệp vụ, hoặc cả hai hoặc không cần một mô hình nào

c Xác định các yêu cầu bổ sung

Đây là những yêu cầu phi chức năng chính mà không thể liên kết với bất cứ use-case cụ thể nào tuy nhiên lại ảnh hưởng đến nhiều use-case hoặc không ảnh hưởng đến use-case nào Chúng được nắm bắt như những yêu cầu truyền thống, là một danh sách các yêu cầu và sẽ được sử dụng trong phân tích, thiết kế cùng với mô hình use-case

Một số loại yêu cầu phi chức năng:

ắ Yêu cầu về giao diện

ắ Yêu cầu về vật lý

ắ Yêu cầu về ràng buộc thiết kế

ắ Yêu cầu về ràng buộc cài đặt

1.2.2 Xác định các yêu cầu hệ thống [1, 4]

Mục đích của xác định yêu cầu là có được sự thống nhất giữa khách hàng với các nhà phát triển về những gì mà hệ thống sẽ thực hiện Nhiệm vụ chính ở đây là phát triển một mô hình của hệ thống cần xây dựng bằng cách dùng các use-case

Điều này là do các yêu cầu về chức năng được cấu trúc một cách tự nhiên thành các use-case và đa phần các yêu cầu phi chức năng đều mang tính cụ thể cho một use-case đơn nào đó sẽ được xử lý trong ngữ cảnh của use-case đó Các yêu cầu phi chức năng còn lại mang tính chung cho nhiều use-case thì được đưa vào tài liệu riêng và được gọi là các yêu cầu bổ sung Các use-case cung cấp một cách thức có

hệ thống và trực quan đẻ nắm bắt các yêu cầu có tính chức năng Qua đó buộc người phân tích phải suy nghĩ theo mong muốn của người sử dụng hệ thống và những nhu cầu, nhiệm vụ nào có thể được hoàn thành nhờ có các use-case đó

Nội dung chính của luồng công việc xác định yêu cầu là:

ắ Tìm actor và case để chuẩn bị một phiên bản đầu tiên của mô hình case

use-ắ Tiến hành phân quyền ưu tiên cho các use-case được phát triển trong lần lặp hiện thời trên cơ sở xác định các use-case có ý nghĩa về mặt kiến trúc

ắ Mô tả các use-case đã được sắp thứ tự ưu tiên đồng thời có thể gợi ý các giao diện người dùng thích hợp cho mỗi actor dựa trên các use-case đó

ắ Cấu trúc lại mô hình use-case bằng cách định nghĩa các tổng quát hoá giữa các use-case làm cho mô hình rõ ràng và dễ hiểu hơn

Sau lần lặp đầu tiên, luồng công việc này cho kết quả là một phiên bản đầu tiên của mô hình use-case, các use-case và các bản mẫu giao diện người dùng được kết hợp Các kết quả bất kỳ của bước lặp tiếp sau sẽ gồm các phiên bản mới của những chế tác này nhưng được cải tiến thêm dần

Sau đây sẽ mô tả chi tiết từng công việc nêu trên được tiến hành như thế nào trong luồng xác định yêu cầu hệ thống

a Lập mô hình use-case

Các hoạt động của việc lập mô hình use-case có sự khác nhau trong các pha khác nhau của dự án Sau đây ta sẽ đi sâu vào mô tả các hoạt động chủ yếu được thực hiện trong pha Chi tiết

a1 Tìm actor

Actor tham gia vào các use-case và kích hoạt hệ thống với các sự kiện vào hoặc nhận kết quả từ hệ thống Actor giao tiếp với hệ thống thông qua việc gửi và nhận các thông điệp Actor được xác định thông qua mô hình nghiệp vụ Khi tìm

được actor cần đặt tên cho nó và mô tả ngắn gọn các vai trò của actor, mục tiêu actor sử dụng hệ thống Cần lưu ý việc mô tả mỗi actor phải nêu bật được các yêu cầu và các trách nhiệm của actor đó

a2 Tìm use-case

Từ các actor đã xác định được ở bước trên, ta xác định các use-case dự tuyển

mà mỗi actor này sử dụng Có thể sẽ có những dự tuyển không trở thành use-case

mà chỉ làm bộ phận của use-case thì tốt hơn Để xem xét một dự tuyển có phải là

một case hay không thì phải xem nó có đầy đủ hay nó luôn đi tiếp sau một case khác hay không

use-Có thể căn cứ vào hai tiêu chuẩn sau để tìm use-case:

ắ Kết quả có giá trị: căn cứ vào kết quả mà việc thực hiện use-case mang lại,

tức là mỗi use-case được thực hiện thành công phải cung cấp một giá trị nào

đó cho actor sao cho actor này đạt được một mục tiêu nào đó

ắ Actor cụ thể: từ việc xác định các use-case cung cấp giá trị cho người dùng

thực ta có thể đảm bảo rằng các use-case không trở nên quá lớn

Việc đặt tên cho use-case cũng nên được cân nhắc, tên use-case nên đề cập

đến chuỗi các hành động riêng biệt đem lại giá trị cho một actor, tên phải ngắn gọn

và nên bắt đầu bằng động từ

Mô tả use-case một cách ngắn gọn giúp ta có thể hiểu được các hành động, cái mà hệ thống có thể làm khi tương tác với actor của nó Nội dung mô tả use-case gồm có: tên use-case, danh sách các actor, mục đích của use-case, mô tả ngắn gọn tiến trình, các chức năng hệ thống thực hiện và các use-case khác có liên quan

a3 Mô tả mô hình use-case tổng quát

Việc mô tả tiêng rẽ từng actor và từng use-case ở trên chưa thể hiện rõ chúng liên quan với nhau như thế nào và khi hợp lại chúng tạo nên mô hình use-case như thế nào Ta sử dụng các biểu đồ và các mô tả để giải thích mô hình use-case như là một khối, thể hiện mục đích ở trên Để đảm bảo cho tính nhất quán khi mô tả nhiều use-case đồng thời ta nên xây dựng một từ điển chú giải các thuật ngữ Mô hình use-case không hẳn phải là một mô hình phẳng, nó có thể được tổ chức thành các cụm use-case và được gọi là các gói use-case

Kết quả của bước này là một mô tả tổng quan của mô hình use-case Trong quá trình chuẩn bị tổng quan mô hình use-case nên xác định xem:

ắ Mọi yêu cầu về mặt chức năng cần thiết đã được nắm bắt thành các use-case chưa?

ắ Chuỗi các hành động đã đúng, đầy đủ và có thể hiểu được đối với mỗi case chưa?

use-ắ Bất kỳ các use-case nào cung cấp ít hoặc không cung cấp giá trị đã được xác

định chưa?

b Phân quyền ưu tiên các use-case

Có thể không phải tất cả các use-case đã được xác định đều phải phát triển cùng một lúc trong lần lặp hiện thời Chỉ những use-case mang ý nghĩa về mặt kiến trúc trong số các use-case tìm được mới được phát triển ngay trong lần lặp hiện thời, các use-case còn lại có thể để lại trong những lần lặp sau Việc phân quyền ưu tiên các use-case chính là để đạt được mục đích đó

c Chi tiết hoá một use-case

Với mục đích là để mô tả dòng các sự kiện một cách chi tiết (khởi động, kết thúc và tương tác với actor như thế nào), ta sử dụng mô hình use-case và các biểu đồ use-case để chi tiết hoá việc mô tả từng bước mỗi use-case trong một bản đặc tả chính xác chuỗi các hành động Bản đặc tả này có thể dưới dạng văn bản hoặc các biểu đồ

Cấu trúc mô tả use-case dạng văn bản:

ắ Tiền điều kiện (trạng thái xuất phát)

ắ Làm thế nào và khi nào use-case được khởi động

ắ Luồng các sự kiện (đánh số thứ tự thực hiện các hành động)

ắ Use-case kết thúc như thế nào và khi nào

ắ Hậu điều kiện (trạng thái kết thúc)

Luồng các sự kiện mô tả các con đường khác nhau để đi qua use-case Nói một cách cụ thể hơn, chúng được chia thành hai loại: con đường cơ bản và các con

đường ngoại lệ Con đường cơ bản được chọn phải là con đường bình thường, đó là một con đường mà người sử dụng nhận thấy là con đường người ta hay đi theo nhất

và đem lại giá trị hiển nhiên cho actor

Khi mô tả các con đường (cơ bản hay ngoại lệ), cần phải:

ắ Mô tả việc sử dụng các đối tượng, các giá trị, các tài nguyên trong hệ thống

ắ Mô tả chuỗi các hành động trong một use-case và gán giá trị cho các thuộc tính của use-case

ắ Mô tả tường minh các hành động mà hệ thống thực hiện và các hành động

mà actor thực hiện, lưu ý tách riêng các trách nhiệm của hệ thống ra khỏi

các trách nhiệm của actor nếu không việc mô tả use-case sẽ không đủ chính xác để dùng làm một đặc tả của hệ thống

ắ Đặc tả các yêu cầu phi chức năng Đa số trong chúng đều có liên quan đến một use-case nào đó Chẳng hạn những yêu cầu về tốc độ, về tính khả thi, về

độ chính xác, về thời gian phúc đáp,… Các yêu cầu như vậy được gắn vào dưới dạng các yêu cầu riêng của use-case đang xét, cần ghi lại trong phần riêng của mô tả use-case

Trong trường hợp hệ thống có tương tác với actor không phải là người (một

hệ thống khác chẳng hạn) thì cần phải đặc tả tương tác này ngay trong những lần lặp

đầu tiên của pha Chi tiết

Hình thức hoá việc mô tả use-case

Đối với những use-case phức tạp, sự tương tác giữa actor và use-case có thể trải qua nhiều trạng thái và nhiều chuyển tiếp thì việc mô tả bằng văn bản thường khó đảm bảo tính nhất quán Giải pháp cho vấn đề này là sử dụng các biểu đồ có tính trực quan của UML:

ắ Biểu đồ trạng thái: mô tả các trạng thái của use-case và các chuyển tiếp giữa

các trạng thái đó

ắ Biểu đồ hoạt động: mô tả các chuyển tiếp giữa các trạng thái dưới dạng chuỗi

các hành động

ắ Biểu đồ tương tác: mô tả cách thức một thể hiện của một use-case tương tác

với một thể hiện của một actor

Tuy nhiên cần thận trọng khi dùng các loại biểu đồ này Trong nhiều trường hợp, nên sử dụng cả hai cách mô tả use-case bằng văn bản và bằng các biểu đồ bổ sung cho nhau

d Tạo bản mẫu giao diện người dùng

Sau khi phát triển một mô hình use-case đặc tả những người dùng là ai và họ

sử dụng hệ thống để làm gì thì ta cần thiết kế các giao diện người dùng giúp cho người dùng thực hiện các use-case một cách có hiệu quả

Hoạt động này được thực hiện qua nhiều bước Bắt đầu với các use-case để tìm hiểu xem giao diện người dùng cần cái gì sao cho mỗi actor có thể sử dụng các use-case Sau đó ta sẽ thiết kế giao diện người dùng thực và phát triển các bản mẫu

để minh hoạ cách thức thực thi giao diện người dùng mà người dùng có thể dùng hệ thống để thực hiện các use-case

Khi các actor tương tác với hệ thống họ sẽ phải dùng và vận dụng các yếu tố của giao diện người dùng, chúng thể hiện các thuộc tính của use-case Các yếu tố này có thể được thể hiện bằng các biểu tượng, các hạng mục của danh sách, các thư mục hay đối tượng Ta phải đặc tả các yếu tố này đối với một actor tại một thời

điểm bằng cách duyệt mọi use-case mà actor đó có thể truy nhập và xác định các yếu tố giao diện người dùng thích ứng riêng cho mỗi use-case

Tiếp theo ta chuẩn bị các phác thảo thô của chùm các yếu tố giao diện người dùng mà tạo nên giao diện người dùng có ích cho các actor, sau đó sẽ phác hoạ các yếu tố bổ sung cần thiết để tổ hợp các yếu tố giao diện người dùng đa dạng thành các giao diện người dùng hoàn chỉnh

Cuối cùng chuẩn bị xây dựng các bản mẫu có khả năng chạy được cho các chùm yếu tố giao diện người dùng quan trọng nhất Các bản mẫu này nên được thẩm định bằng cách duyệt chúng và các phác thảo càng sớm càng tốt để có thể tránh dược những lỗi lầm Việc cài đặt giao diện người dùng được thực hiện song song với quá trình phân tích, thiết kế, cài đặt hệ thống

e Cấu trúc mô hình use-case

Trước khi thực hiện cấu trúc mô hình use-case thì người phát triển đã xác

định các actor, case, mô tả chúng trong các biểu đồ và diễn đạt mô hình case một cách thống nhất, đã phát triển mô tả chi tiết cho mỗi use-case Sau đó có thể tái cấu trúc toàn bộ các use-case để mô hình trở nên dễ hiểu hơn và từ đó dễ làm việc hơn

use-Mục đích của hoạt động này là tìm ra các mô tả use-case có tính chung và chia sẻ mà có thể được các mô tả use-case có tính cụ thể hơn sử dụng, tìm ra các mô tả use-case phụ hoặc tuỳ chọn mà có thể mở rộng thành các mô tả use-case cụ thể hơn

1.2.3 Phân tích [1, 2, 4]

Phân tích là trọng tâm của các lần lặp đầu tiên của pha Chi tiết Nó góp phần tạo ra kiến trúc vững vàng, ổn định và giúp cho người phát triển hiểu biết sâu hơn về các yêu cầu

Với các kết quả đã có được từ luồng công việc xác định yêu cầu hệ thống vẫn tồn tại những điều chưa giải quyết được Đó là do ta đã sử dụng ngôn ngữ trực quan nhưng không chính xác của khách hàng trong quá trình xác định yêu cầu

Trong quá trình phân tích ta sẽ phân tích các yêu cầu bằng cách tinh lọc và cấu trúc chúng để đạt được sự hiểu biết chính xác hơn về các yêu cầu và có một mô tả các yêu cầu dễ duy trì, giúp cấu trúc lại toàn bộ yêu cầu hệ thống Hay nói cách khác, ta sẽ tìm ra cách thức để thực hiện các yêu cầu hệ thống đã được xác định trong các use-case

Nội dung của luồng phân tích: phân tích mô hình use-case bằng cách tìm ra cách thức tổ chức các thành phần bên trong của hệ thống để thực hiện mỗi use-case Các thành phần bên trong ở đây là các lớp phân tích Để có thể làm được điều đó cần thực hiện các hoạt động: phân tích kiến trúc, phân tích một use-case, phân tích một lớp, phân tích một gói

Kết quả của luồng phân tích cho ta một mô hình phân tích trong đó:

ắ Đem lại sự qui định chính xác hơn về các yêu cầu

ắ Được mô tả bằng ngôn ngữ của người phát triển, mang tính hình thức hơn và

có thể sử dụng để lập luận về các sự việc bên trong hệ thống

ắ Cấu trúc các yêu cầu theo cách dễ hiểu hơn, dễ thay đổi và bảo trì

ắ Là nhát cắt đầu tiên của mô hình thiết kế, là đầu vào thiết yếu cho thiết kế và cài đặt hệ thống

a Phân tích kiến trúc

Mục đích của hoạt động này là phác thảo những nét lớn của mô hình phân tích và của kiến trúc qua việc xác định các gói phân tích, các lớp thực thể và các yêu cầu đặc biệt

a1 Xác định các gói phân tích và các phụ thuộc giữa chúng

Các gói phân tích cung cấp một cách thức cho phép tổ chức mô hình phân tích thành các phần nhỏ hơn và dễ điều khiển hơn Chúng được xác định bằng cách dựa trên các yêu cầu chức năng và miền bài toán Cụ thể hơn có thể xác định một cách trực tiếp là đưa một phần chính các use-case vào một gói riêng Các use-case

được gom vào một gói là những use-case cần thiết hỗ trợ cho một quá trình nghiệp

vụ cụ thể, hoặc các use-case cần thiết hỗ trợ một actor cụ thể, hoặc các use-case liên quan trong quan hệ tổng quát hoá, quan hệ mở rộng

Một gói phân tích có thể chứa các lớp phân tích, các thực thi use-case phân tích và các gói phân tích khác

Theo các cách xác định gói phân tích như trên thì có thể xảy ra trường hợp một số gói có những tính chung, chẳng hạn chung một lớp phân tích Vấn đề này có thể giải quyết bằng cách đưa lớp này vào một gói riêng sau đó để các gói khác phụ thuộc vào gói mới

Việc xác định các phụ thuộc giữa các gói phân tích là để tìm ra các gói tương đối độc lập và ghép cặp lỏng nhưng có tính kết dính cao Tính chất này của các gói làm cho chúng dễ bảo trì hơn vì sự thay đổi một số lớp bên trong một gói sẽ chỉ ảnh hưởng đến chính gói đó Tốt nhất nên giảm số lượng các mối quan hệ giữa các lớp thuộc các gói khác nhau Biện pháp là tổ chức mô hình phân tích thành các tầng ở đó các gói ứng dụng cụ thể ở tầng cao còn các gói tổng quát hơn ở tầng thấp hơn

là đủ

a3 Xác định các yêu cầu chung đặc biệt

Đây là những yêu cầu diễn ra trong quá trình phân tích mà ta cần nắm bắt và

xử lý tiếp một cách thích hợp trong các hoạt động thiết kế và cài đặt Đó có thể là các yêu cầu về: tính lâu bền, tính phân tán và tương tranh, các đặc trưng an toàn, quản lý giao dịch,…

b Phân tích một use-case

Mục đích của hoạt động này là:

ắ Xác định các lớp phân tích mà đối tượng của chúng là cần cho dòng các sự kiện của use-case

ắ Phân phối hành vi của use-case đến các đối tượng phân tích tương tác

ắ Nắm bắt toàn bộ các yêu cầu đặc biệt về thực thi use-case, đó là những yêu cầu được xác định trong phân tích nhưng được xử lý sau trong thiết kế và cài

đặt

Trong hoạt động này ta cần làm mịn dần mỗi use-case qua sự cộng tác giữa các lớp phân tích Sau đây sẽ đề cập chi tiết đến cách xác định lớp phân tích và sự tương tác giữa các đối tượng phân tích

b1 Xác định các lớp phân tích

Thực thi use-case phân tích là một sự cộng tác trong mô hình phân tích Nó mô tả cách thức một use-case cụ thể được thực hiện và thể hiện dưới dạng các lớp phân tích, các đối tượng phân tích tương tác với nhau

Có ba khuôn mẫu lớp cơ bản:

ắ Lớp thực thể (entity class): lớp đại diện cho thực thể nghĩa là các đối tượng

dữ liệu có thể lưu trữ, tham chiếu hay sửa đổi

ắ Lớp biên (boundary class): là lớp trong hệ thống đảm nhận vai trò giao tiếp

giữa hệ thống với actor, thường là nhận/thể hiện thông tin và các yêu cầu từ/đến actor

ắ Lớp điều khiển (control class): là lớp mang chức năng xử lý, điều khiển các

hoạt động xử lý, tính toán Tính động của hệ thống được mô hình hoá bởi các lớp điều khiển

b2 Mô tả tương tác đối tượng phân tích

Để mô tả tương tác đối tượng phân tích ta sử dụng các biểu đồ cộng tác mô tả dòng sự kiện của use-case, chứa các thể hiện của actor tham gia, các đối tượng phân tích và các tương tác của chúng để thực thi use-case đó

Trong trường hợp có nhiều biểu đồ thực thi cùng một use-case hoặc thể hiện các dòng sự kiện phức tạp thì nên bổ sung thêm mô tả bằng văn bản cho biểu đồ cộng tác

c Phân tích một lớp

Trên cơ sở thực thi use-case phân tích và phác thảo lớp phân tích được xác

định từ các bước trước đó ta cần phải xác định lớp phân tích hoàn chỉnh, tức là xác

định được trách nhiệm của lớp phân tích dựa trên vai trò của nó trong các thực thi use-case, xác định được các thuộc tính và các quan hệ của lớp phân tích, các yêu cầu đặc biệt về thực thi của lớp phân tích Cụ thể như sau:

ắ Trách nhiệm của một lớp có thể được xác định bằng cách kết hợp mọi vai trò

mà nó đảm nhận trong các thực thi use-case khác nhau Có thể tìm thấy các thực thi use-case mà lớp dó tham gia bằng cách xem xét các lớp và các biểu

đồ tương tác của các thực thi use-case đó

ắ Để xác định thuộc tính của lớp nên lưu ý: mỗi thuộc tính qui định một đặc

điểm của một lớp phân tích, nó thường được ngầm định và đòi hỏi bởi các trách nhiệm của lớp

ắ Các đối tượng phân tích tương tác với nhau thông qua các liên kết trong biểu

đồ cộng tác Các liên kết này là thể hiện của các kết hợp của các lớp tương ứng Nên tối thiểu hoá số lượng các mối quan hệ giữa các lớp phân tích Các tổng quát hoá phải được xác định vì nó được sử dụng để rút ra các hành vi chung, chia sẻ giữa nhiều lớp phân tích khác nhau và nên giữ ở mức khái niệm cao , đến bước thiết kế nó sẽ được điều chỉnh cho phù hợp hơn

ắ Các yêu cầu đặc biệt đối với lớp phân tích là những yêu cầu đã được xác định trong phân tích nhưng được xử lý trong thiết kế và cài đặt (ví dụ các yêu cầu phi chức năng)

d Phân tích một gói

Từ mô tả kiến trúc (khung nhìn của mô hình use-case) và phác thảo của các gói phân tích, ta tiến hành hoạt động phân tích một gói để có thể đưa ra các gói phân tích hoàn chỉnh Cụ thể hơn nữa là để đảm bảo rằng một gói phân tích càng

độc lập với các gói khác càng tốt, để gói phân tích hoàn thành mục đích của nó về cài đặt các lớp miền hoặc use-case, để mô tả các phụ thuộc sao cho có thể ước lượng

được kết quả của các thay đổi sau này

Để phân tích một gói ta có thể làm theo các hướng dẫn sau:

ắ Xác định và bảo trì các phụ thuộc của các gói này lên gói khác mà các lớp

được chứa trong gói đó được kết hợp với gói này

ắ Đảm bảo rằng gói chứa các lớp đúng

ắ Giới hạn các mối phụ thuộc tới các gói khác

1.2.4 Thiết kế [1, 4]

Thiết kế được tập trung vào lúc kết thúc pha Chi tiết và những bước lặp đầu của pha Xây dựng Thiết kế góp phần xây dựng một kiến trúc vững vàng, ổn định và tạo ra một bản phác thảo cho mô hình cài đặt

Nhiệm vụ của thiết kế là định hình hệ thống và tìm hình thức thể hiện về mặt vật lý để thực hiện mọi yêu cầu (kể cả các yêu cầu phi chức năng và các ràng buộc khác) đã được đặt ra cho hệ thống

Đầu vào của hoạt động thiết kế là mô hình use-case, mô hình phân tích, các yêu cầu bổ sung và mô tả kiến trúc (khung nhìn của mô hình phân tích) còn đầu ra của nó là mô hình thiết kế và mô hình triển khai

Mô hình thiết kế là một mô hình đối tượng mô tả sự cài đặt vật lý của các use-case bằng cách tập trung vào cách thức mà các yêu cầu (chức năng và phi chức năng) và các ràng buộc khác liên quan tới mô trường cài đặt tác động lên hệ thống Mô hình thiết kế là một hệ phân cấp của các hệ thống con thiết kế chứa các lớp thiết

kế, các thực thi use-case thiết kế và các giao diện Trong đó, mỗi lớp thiết kế là sự trừu tượng hoá liền mạch của một lớp hoặc một cấu trúc tương tự trong cài đặt của

hệ thống; mỗi thực thi use-case thiết kế là một sự cộng tác bên trong mô hình thiết

kế, nó mô tả một use-case được thực thi và thể hiện như thế nào dưới dạng các lớp thiết kế và các đối tượng của chúng; còn các giao diện được dùng để đặc tả các thao tác do các lớp thiết kế và các hệ thống con thiết kế cung cấp

Mô hình triển khai cũng là một mô hình đối tượng Nó mô tả sự phân phối về mặt vật lý của hệ thống qua cách thức phân tán chức năng giữa các nút tính toán và

được dùng làm đầu vào cho các hoạt động trong thiết kế và cài đặt

Sau đây sẽ đề cập chi tiết đến các hoạt động của dòng công việc thiết kế

a Thiết kế kiến trúc

Với mục đích phác họa các mô hình thiết kế, mô hình triển khai và cấu trúc của chúng, hoạt động thiết kế kiến trúc bao gồm:

ắ Xác định các nút và các cấu hình mạng của chúng Cấu hình mạng vật lý tác

động lớn lên kiến trúc của phần mềm bao gồm các lớp động được yêu cầu và

sự phân phối chức năng giữa các nút mạng Biết được khả năng và các giới hạn của các nút và kết nối của chúng ta có thể tích hợp các công nghệ để sự phân phối hệ thống trở nên dễ dàng hơn

ắ Xác định các hệ thống con và các giao diện của chúng Các hệ thống con cung cấp cách thức tổ chức mô hình thiết kế thành các phần dễ quản lý Chúng được phân thành các tầng: tầng cụ thể ứng dụng, tầng tổng quát ứng dụng, tầng trung và tầng phần mềm hệ thống Cần xác định các hệ thống con trong từng tầng và mối quan hệ phụ thuộc giữa chúng Các giao diện được cung cấp bởi một hệ thống con xác định các thao tác mà bên ngoài hệ thống con đó có thể được truy cập đến nó Phác thảo giao diện ban đầu xuất phát từ việc xem xét sự phụ thuộc giữa các hệ thống con mà ta đã tìm được

ắ Xác định các lớp thiết kế quan trọng về mặt kiến trúc Không nên xác định quá nhiều lớp và đi quá sâu vào chi tiết vì các lớp thiết kế được xác định và làm mịn dựa trên kết quả thiết kế use-case (sẽ bàn đến sau) Một số lớp thiết

kế có thể được xác định từ các lớp phân tích quan trọng về mặt kiến trúc Các lớp động được xác định bằng cách xem xét vòng đời các đối tượng động của nó và cách thức mà các đối tượng động này truyền thông, đồng bộ hoá

được xác định và thiết kế trong pha Chi tiết

b Thiết kế một use-case

Mục đích của hoạt động thiết kế use-case là:

ắ Xác định các lớp thiết kế và các hệ thống con mà các thể hiện của chúng là cần thiết để thực hiện dòng các sự kiện của use-case đó

ắ Phân phối hành vi của use-case cho các đối tượng thiết kế tương tác hoặc cho các hệ thống con tham gia

ắ Xác định các yêu cầu về các thao tác của các lớp thiết kế và các hệ thống con thông qua giao diện của chúng

ắ Nắm bắt các yêu cầu cài đặt cho use-case đó

b1 Xác định các lớp thiết kế tham gia

Để xác định được các lớp thiết kế tham gia thực thi use-case ta làm như sau:

ắ Nghiên cứu các lớp phân tích tham gia vào thực thi use-case phân tích Ta xác định các lớp thiết kế lần vết tới các lớp phân tích đó

ắ Nghiên cứu các yêu cầu đặc biệt của thực thi use-case phân tích tương ứng Xác định các lớp thiết kế cài đặt các yêu cầu đó

ắ Xác định các lớp được yêu cầu

Sau khi xác định các lớp thiết kế, chúng được đưa vào một biểu đồ lớp chỉ ra

sự kết hợp các lớp trong thực thi use-case

b2 Mô tả tương tác của các đối tượng thiết kế

Ta sử dụng biểu đồ tuần tự chứa các thể hiện của actor tham gia, các đối tượng thiết kế và sự truyền thông điệp giữa chúng để mô tả sự tương tác của các đối tượng thiết kế Thực hiện điều đó bằng cách nghiên cứu thực thi use-case phân tích tương ứng Bắt đầu từ xuất phát điểm của luồng sự kiện use-case (là một thông điệp

từ một thể hiện của actor đến một đối tượng thiết kế), đi theo luồng sự kiện đó, xác

định đối tượng thiết kế và quyết định tương tác nào giữa các đối tượng thiết kế và các thể hiện của actor là cần thiết để thực thi use-case

b3 Xác định các hệ thống con và các giao diện tham gia

Để xác định các hệ thống con cần thiết cho thực thi use-case, ta có thể:

ắ Nghiên cứu các lớp phân tích tham gia vào thực thi use-case phân tích tương ứng Xác định các gói phân tích chứa chúng (nếu có), từ đó xác định các hệ thống con thiết kế lần vết tới các gói phân tích đó

ắ Nghiên cứu các yêu cầu đặc biệt của thực thi use-case phân tích tương ứng Xác định các lớp thiết kế cài đặt các yêu cầu đó (nếu có), từ đó xác định các

hệ thống con thiết kế chứa các lớp đó

Các hệ thống con đã xác định được đưa vào một biểu đồ lớp (biểu đồ này kết hợp với thực thi use-case) mà chỉ ra các phụ thuộc giữa các hệ thống con và các giao diện đã được dùng trong thực thi use-case Đồng thời, ta mô tả cách thức mà các đối tượng của các lớp được chứa trong các hệ thống con đó tương tác ở mức hệ thống bằng cách sử dụng biểu đồ tuần tự tương tự như đã đề cập đến trong phần trước

c Thiết kế một lớp

Mục đích là để tạo ra một lớp thiết kế hoàn chỉnh mà hoàn thành vai trò của

nó trong các thực thi use-case và các yêu cầu phi chức năng áp dụng cho nó từ các thực thi use-case thiết kế, phác thảo lớp thiết kế, phác thảo giao diện và lớp phân tích hoàn chỉnh Các bước tiến hành thiết kế một lớp gồm:

c1 Xác định lớp thiết kế

Trước tiên cần phác thảo một hoặc nhiều lớp thiết kế với đầu vào đã biết là lớp phân tích và các giao diện Các lớp thiết kế được xác định trong bước này được gán quan hệ lần vết tới các lớp ơhân tích tương ứng mà chúng thiết kế, ta cần ghi nnhớ nguồn gốc của lớp thiết kế khi nó được làm mịn dần trong các bước tiếp sau

c2 Xác định thao tác

Xác định các thao tác được cung cấp bởi lớp thiết kế và mô tả chúng bằng cách sử dụng cú pháp của ngôn ngữ lập trình Để xác định thao tác có thể theo các căn cứ sau:

ắ Các trách nhiệm của lớp phân tích bất kỳ mà lớp thiết kế lần vết tới nó Trách nhiệm kéo theo một hoặc nhiều thao tác

ắ Các yêu cầu đặc biệt

ắ Giao diện mà lớp thiết kế cần phải cung cấp Các thao tác của các giao diện này cũng do lớp thiết kế cung cấp

ắ Các thực thi use-case thiết kế mà lớp tham gia

c3 Xác định thuộc tính

Có thể dựa vào các căn cứ sau để xác định thuộc tính mà lớp thiết kế đòi hỏi (chúng được mô tả bằng cú pháp của ngôn ngữ lập trình):

ắ Các thuộc tính của một lớp phân tích bất kỳ mà lớp thiết kế lần vết tới nó

ắ Các kiểu thuộc tính hiện có mà ngôn ngữ lập trình hỗ trợ Thể hiện thuộc tính

đơn không thể chia sẻ cho nhiều đối tượng thiết kế, thuộc tính đó nên được xác định như một lớp riêng

ắ Lớp thiết kế quá phức tạp và khó hiểu do các thuộc tính của nó thì có thể phải tách một số thuộc tính ra thành các lớp riêng

c4 Xác định các mối quan hệ

Ta sử dụng biểu đồ tuần tự để thể hiện sự tương tác của các đối tượng thiết

kế Các tương tác này đòi hỏi sự kết hợp giữa các lớp tương ứng Số lượng các mối quan hệ giữa các lớp nên tối thiểu hoá Quan hệ được mô hình hoá thành kết hợp hay kết tập Khi xác định và làm mịn các kết hợp, kết tập có thể thực hiện theo hướng dẫn sau:

ắ Xem xét các kết hợp hoặc kết tập liên quan đến lớp hoặc các lớp phân tích tương ứng Các mối quan hệ này trong mô hình phân tích kéo theo một hoặc nhiều quan hệ tương ứng trong mô hình thiết kế liên quan đến lớp thiết kế này

ắ Tinh chế bản số của kết hợp, tên gọi các vai trò, các lớp liên kết, các kết hợp

n dựa theo sự hỗ trợ của ngôn ngữ lập trình

ắ Tinh chế hướng của kết hợp bằng cách xem xét hướng của thông điệp giữa các đối tượng thiết kế trong các biểu đồ tương tác

Ngoài ra cần xác định các tổng quát hoá

c5 Xác định phương thức

Phương thức dùng trong quá trình thiết kế để chỉ ra cách thức thao tác được thực thi như thế nào Phương thức có thể được đặc tả bằng ngôn ngữ tự nhiên hoặc các giả mã Tuy nhiên phương thức không được đặc tả trong quá trình thiết kế mà

được tạo ra trong quá trình cài đặt bằng cách sử dụng trực tiếp ngôn ngữ lập trình

c6 Mô tả trạng thái

Một số đối tượng thiết kế được điều khiển qua trạng thái (trạng thái của chúng xác định hành vi khi nhận được thông điệp), vì vậy ta dùng biểu đồ trạng thái để mô tả sự thay đổi trạng thái của đối tượng thiết kế Biều đồ trạng thái đó rất

có ích trong cài đặt lớp thiết kế tương ứng

c7 Xử lý các yêu cầu đặc biệt

Trong bước này, tất cả các yêu cầu chưa được xem xét trong bước trước đều

được xử lý Ta cần nghiên cứu các yêu cầu đước đề ra bởi các thực thi use-case mà lớp này tham gia

Kết quả cuối cùng của hoạt động thiết kế lớp là sơ đồ lớp thiết kế thực thi use-case Sơ đồ lớp gồm các lớp thiết kế với đầy đủ các thuộc tính, thao tác và xử lý khác cùng với các mối liên kết và bản số của các mối liên kết đó

d Thiết kế một hệ thống con

Mục đích của hoạt động thiết kế một hệ thống con là: đảm bảo cho hệ thống con độc lập với các hệ thống con khác hoặc với các giao diện của chúng, cung cấp các giao diện đúng, cung cấp cài dặt đúng cho các thao tác đã đ−ợc xác định bởi các giao diện mà nó cung cấp

Các hoạt động thiết kế một hệ thống con gồm có:

ắ Bảo trì các phụ thuộc của hệ thống con

ắ Bảo trì các giao diện đ−ợc cung cấp bởi hệ thống con

ắ Bảo trì nội dung hệ thống con

Chương 2 ngôn ngữ định dạng mở rộng

2.1 Giới thiệu chung [5, 7, 10]

Ngôn ngữ định dạng mở rộng XML (eXtensible Markup Language) được

định nghĩa bởi tổ chức mạng toàn cầu (World Wide Web Consortium – viết tắt là W3C)

Ngôn ngữ định dạng HTML (Hypertext Markup Language) mà chúng ta từng quen thuộc được tạo ra năm 1990 HTML cho phép tạo ra nội dung các trang Web rất đẹp Tuy nhiên, trong việc xuất bản tài liệu trên Internet như xây dựng các trang cung cấp thông tin, các ứng dụng thương mại điện tử,… thì HTML ngày càng bộc lộ

rõ những hạn chế, cách quản lý lỏng lẻo Vì lẽ đó mà XML được tạo ra để giải quyết những giới hạn này của HTML

Cả hai ngôn ngữ định dạng XML và HTML đều dựa trên chuẩn ngôn ngữ

định dạng tổng quát SGML (Standard Generalized Markup Language) XML ra đời không phải để thay thế HTML mà tồn tại vì HTML đã thành công, nó kết hợp nhiều tính năng thành công của HTML và để đáp ứng những yêu cầu mới

XML và HTML đều sử dụng các thẻ định dạng (tag) Trong khi HTML (phiên bản gần đây nhất) định nghĩa khoảng 120 thẻ – chỉ chứa thông tin định dạng thì XML có thể thiết kế riêng ngôn ngữ đánh dấu rồi định dạng tài liệu bằng ngôn ngữ này Nói cách khác, các thẻ trong XML là tự định nghĩa theo mục đích sử dụng, chứa thông tin về định dạng và thông tin về dữ liệu

Ngày nay hầu hết các nhà cung cấp phần mềm như Microsoft, Oracle, IBM, Sun, và hàng trăm công ty cung cấp phần mềm khác đã đưa XML vào sản phẩm của họ

Nội dung tài liệu XML được ràng buộc bởi hai tính chất: hợp lệ và hợp khuôn dạng Để tạo được tài liệu XML hội tụ đủ cả hai tính chất này cần tuân thủ đúng các bước thiết kế và xây dựng XML mà W3C đưa ra Tài liệu XML cần tuân theo đúng

cú pháp khi khai báo thẻ XML và cách đặt thẻ XML theo trật tự để bộ phân tích có thể phân tích được

Có thể viết XML bằng bất kỳ trình soạn thảo văn bản nào, tuy nhiên có một

số trình soạn thảo chuyên dụng cho XML như XML Writer, XML Spy, Ngoài việc cho phép soạn thảo và xem tài liệu XML tương tự Explorer của Microsoft các trình soạn thảo này còn có thể kiểm tra tính hợp lệ và hợp khuôn dạng của định nghĩa kiểu tư liệu DTD (Document Type Definition) và lược đồ XML (ta sẽ đề cập chi tiết sau)

Những nội dung chính sẽ trình bày trong chương này gồm có: cấu trúc tài liệu XML hợp khuôn dạng, tạo tài liệu XML hợp lệ bằng định nghĩa kiểu tư liệu và lược đồ XML , hiển thị nội dung tài liệu trong trình duyệt bằng bảng định kiểu CSS (Cascading Style Sheet), phân tích tài liệu XML theo mô hình đối tượng tài liệu DOM (Document Object Model) và một số vấn đề có liên quan Sau đây là cụ thể hoá các nội dung vừa nêu

2.2 Cấu trúc của tài liệu XML

Tài liệu XML được tạo thành từ thành phần định dạng và thành phần dữ liệu

ký tự Định dạng bao gồm thẻ bắt đầu, thẻ kết thúc, các phần tử thẻ rỗng, các tham chiếu thực thể, tham chiếu ký tự, lời chú thích, phân đoạn CDATA (Character Data), khai báo kiểu tư liệu và chỉ thị xử lý Tất cả các dữ liệu còn lại trong một tài liệu XML không phải là định dạng đều được xem là dữ liệu ký tự [5]

Xét ví dụ một tài liệu XML đơn giản:

Về mặt cấu trúc, tài liệu XML gồm hai phần:

2.2.1 Phần khởi đầu [5, 10]

Phần khởi đầu bắt đầu từ dòng đầu tiên trong tài liệu XML, thường chứa các khai báo, lời chú thích, chỉ thị xử lý, khoảng trắng và định nghĩa kiểu tư liệu DTD

a Các khai báo

Khai báo XML sử dụng cấu trúc <?xml?> Trong cấu trúc khai báo này có thể sử dụng 3 khai báo thuộc tính:

ắ Phiên bản (version): cho biết phiên bản đặc tả XML mà tài liệu sử dụng

ắ Mã hoá (encoding): cho biết bộ mã mà tài liệu sử dụng Bộ mã mặc định là

UTF-8 Thuộc tính này có thể có mặt hoặc không trong <?xml?>

ắ Thực thể độc lập (standalone): nhận giá trị ‘yes’ nếu tài liệu không tham

chiếu đến các thực thể bên ngoài và ‘no’ trong trường hợp ngược lại Thuộc tính này cũng có thể có mặt hoặc không trong <?xml?>

b Chú thích

Chú thích trong các tài liệu bất kỳ (không chỉ riêng XML) đều giúp ta hiểu rõ hơn nội dung tài liệu Trong tài liệu XML, chú thích được bắt đầu bằng “<! “ và kết thúc bằng “ >” Do đó, khi thêm chú thích vào tài liệu XML không nên dùng

ký tự “ “ trong nội dung chú thích, chú thích không được đặt trước khai báo và cũng không được đặt trong phần định dạng

Trong file danhsach.xml sau đây, đặt chú thích và nội dung là hợp lệ:

2.2.2 Thân tài liệu [5, 10]

Thân tài liệu XML nằm trong phần tử gốc (root) Phần tử gốc này là duy nhất, nó chứa tất cả các phần tử và cặp thẻ khác trong tài liệu

a Thẻ và phần tử

Cấu trúc tài liệu XML dựa trên các thành phần định dạng Các thành phần

này bao gồm các phần tử Mỗi phần tử bao gồm một cặp thẻ: thẻ bắt đầu (thẻ mở) –

ký hiệu là <tên thẻ> và thẻ kết thúc (thẻ đóng) – ký hiệu là </tên thẻ> Trong đó, tên

thẻ có thể bắt đầu bằng ký tự, dấu _ Sau đó có thể là ký tự, chữ số, gạch nối nhưng không chứa khoảng trắng Cần lưu ý phân biệt chữ hoa, chữ thường khi đặt tên thẻ Thẻ đóng và thẻ mở phải hoàn toàn khớp với nhau

Giữa thẻ đóng và thẻ mở có thể chứa dữ liệu ký tự hoặc các cặp thẻ khác Khác với HTML, các thẻ trong XML phải đặt đúng thứ tự, không xen kẽ nhau

Ví dụ đặt thứ tự các thẻ như sau là sai:

Tuy nhiên cũng có phần tử chỉ có một thẻ, nó được gọi là phần tử rỗng,

không kèm theo dữ liệu Cú pháp của phần tử này là <tên thẻ/>

b Thuộc tính của các thẻ

Thuộc tính của thẻ cho phép xác định thêm thông tin và ý nghĩa của thẻ, nó

được đặt bên trong thẻ mở và thẻ thể hiện phần tử rỗng theo cú pháp tương ứng như sau:

<tên thẻ thuộc tính của thẻ = giá trị>

<tên thẻ thuộc tính của thẻ = giá trị/>

Tên thuộc tính được đặt theo qui tắc đặt tên thẻ, còn giá trị gán cho thuộc tính đặt trong cặp dấu “”

Nếu trong giá trị gán cho thuộc tính hay trong dữ liệu ký tự có chứa các ký tự

định dạng như <, >, hay dấu “” thì ta sẽ giải quyết như thế nào vì nếu gõ đúng các

ký tự này, tài liệu sẽ không hợp khuôn dạng Khi đó ta sử dụng tham chiếu thực thể

tổng quát &lt;, &gt;, &amp;, &quot;, &apos; lần lượt thay cho >, <, &, “, ‘

Ví dụ, tài liệu XML sau là hợp khuôn dạng:

2.3 Định nghĩa kiểu tư liệu – DTD (Document Type Definition) [5]

Chúng ta đã đề cập đến cấu trúc tài liệu XML hợp khuông dạng ở phần trước Tuy nhiên, tài liệu XML còn cần phải hợp lệ khi định nghĩa kiểu tư liệu (DTD) cho các phần tử trong tài liệu Như đã nói từ đầu chương, ta có thể tuỳ ý đặt tên thẻ trong tài liệu XML Tài liệu XML được xem là hợp lệ và có giá trị khi toàn bộ các phần tử trong tài liệu đã định nghĩa kiểu mà nó sẽ chứa Việc định nghĩa kiểu dữ liệu cho các phần tử thẻ gọi là định nghĩa kiểu tư liệu, viết tắt là DTD

Cú pháp tổng quát định nghĩa và khai báo kiểu tư liệu cho các phần tử thẻ như sau:

<!DOCTYPE rootName [DTD]>

Trong đó rootName là tên thành phần gốc tài liệu, DTD là các định nghĩa cho phần tử trong tài liệu, nó có thể là định nghĩa nội hoặc ngoại Sau đây ta sẽ xét cụ thể từng trường hợp

2.3.1 Định nghĩa DTD nội

Các phần tử trong [DTD] theo cú pháp trên đều nằm trong tài liệu Mỗi phần

tử được định nghĩa bằng thẻ khai báo <!ELEMENT> theo cú pháp sau:

<!ELEMENT Name Content_Model>

Trong đó Name là tên phần tử muốn định nghĩa, Content –Model có thể đặt

là EMPTY (thành phần không chứa gì cả) hay ANY (chứa tổ hợp thành phần và văn bản không xác định) hoặc chứa cả hai nội dung (bao gồm dữ liệu có thể dùng phân tích hoặc các phần tử con khác)

Sau đây là một số cụ thể hoá nội dung của phần tử:

<!ELEMENT Name (#PCDATA)>

Trong đó Name là tên phần tử cần định nghĩa

c Phần tử chứa nội dung lựa chọn

Cú pháp khai báo: <!ELEMENT Name (Name1⏐Name2)>

Có nghĩa là phần tử Name hoặc chứa thành phần Name1 hoặc chứa thành phần Name2

d Phần tử chứa nhiều phần tử con giống nhau

Định nghĩa DTD sử dụng 3 ký tự đại diện qui định số phần tử con giống nhau

mà một phần tử chứa Đó là các ký tự: *, + và ? Có thể tóm tắt cách sử dụng 3 ký

tự này trong bảng sau (giả sử x và y là hai phần tử muốn khai báo và định nghĩa):

x* Không có hoặc có nhiều phần tử x giống nhau

x+ Có một hoặc có nhiều phần tử x giống nhau

x? Phần tử x hoặc không có phần tử nào

x, y Phần tử x tiếp đến là y

x⏐y Phần tử x hoặc phần tử y (loại trừ lẫn nhau)

(expression) Tập các phần tử expression trong cặp ngoặc sẽ ảnh

hưởng bởi các ký tự đại diện *, +, ?

Bảng 2.1 : Tóm tắt cách sử dụng các ký tự đại diện

Quay lại ví dụ file danhsach.xml đã có từ trước, các bổ sung sau đây làm tài liệu hợp khuôn dạng và hợp lệ:

<?xml version=”1.0” standalone=”yes”?>

< Bắt đầu phần định nghĩa DTD >

<!DOCTYPE danhsachCBCNV [

<!ELEMENT danhsachCBCNV (canbo)*>

<!ELEMENT canbo (hoten, ngaysinh, gioitinh, khoa⏐phong)>

<!ELEMENT hoten (#PCDATA)>

<!ELEMENT ngaysinh (#PCDATA)>

<!ELEMENT gioitinh (#PCDATA)>

<!ELEMENT khoa (#PCDATA)>

<!ELEMENT phong (#PCDATA)>

Trong trường hợp tài liệu XML hiện tại có sử dụng các phần tử thẻ đã được

định nghĩa trong các tài liệu XML trước đó (các định nghĩa DTD xây dựng sẵn thường chứa trong các file dtd), ta phải sử dụng định nghĩa DTD ngoại theo cú pháp sau:

<!DOCTYPE rootName SYSTEM URL [DTD]>

Hoặc

<!DOCTYPE rootName PUBLIC FPI URL [DTD]>

Trong đó: rootName là tên phần tử gốc của tài liệu XML đang xét, SYSTEM

là từ khoá áp dụng cho tham chiếu ngoại riêng, nếu không chỉ ra đường dẫn thì trình

phân tích sẽ tìm các file tham chiếu trong thư mục hiện hành cùng cấp với file tài liệu này Ta cũng có thể chỉ định file tham chiếu ngoại là một tài liệu có thể truy xuất theo địa chỉ tuyệt đối URLs trên Internet

Nếu sử dụng từ khoá PUBLIC trong định nghĩa DTD ngoại thì các phần tử DTD có thể được dùng chung cho nhiều tài liệu Tuy nhiên cần phải tạo ra một định dạng chung hình thức FPI (Formal Public Identifier) và tuân theo các qui tắc áp dụng cho FPI

Lưu ý: khi sử dụng định nghĩa DTD ngoại, trong khai báo đầu tài liệu XML thuộc tính standalone có giá trị “no”

Ví dụ, soạn file data.dtd có nội dung như sau:

<!ELEMENT danhsachCBCNV (canbo)*>

<!ELEMENT canbo (hoten, ngaysinh, gioitinh, khoa⏐phong)>

<!ELEMENT hoten (#PCDATA)>

<!ELEMENT ngaysinh (#PCDATA)>

<!ELEMENT gioitinh (#PCDATA)>

<!ELEMENT khoa (#PCDATA)>

<!ELEMENT phong (#PCDATA)>

Khi đó nội dung file danhsach.xml sẽ là:

2.3.3 Thực thể và thuộc tính DTD

a Thực thể là gì?

Thực thể (entity) là cách XML tham chiếu đến một mục dữ liệu, thường là văn bản (text) hoặc cũng có thể là dữ liệu nhị phân Thực thể được khai báo trong phần định nghĩa DTD, sau đó được sử dụng bằng cách tham chiếu đến nó trong tài liệu Có hai loại thực thể: thực thể tổng quát (general entity) và thực thể tham số (parameter entity) Thực thể có thể là nội (được định nghĩa hoàn toàn trong tài liệu tham chiếu đến nó) hoặc là ngoại (nội dung của nó được định nghĩa từ nguồn dữ liệu bên ngoài, thường được tham chiếu bằng địa chỉ URL hoặc URI)

Thực thể có thể ở dạng phân tích hoặc không phân tích Với thực thể phân tích, nội dung của nó phải hợp khuôn dạng văn bản của XML Còn với thực thể không phân tích, nội dung của nó gồm các dữ liệu text hoặc nhị phân mà người sử dụng không muốn trình phân tích XML phân tích chúng

a1 Thực thể tổng quát

Cú pháp khai báo và định nghĩa thực thể tổng quát:

<!ENTITY Name Definition>

Trong đó: Name là tên thực thể, được dùng để tham chiếu đến nội dung của nó; Definition là định nghĩa của thực thể, nội dung định nghĩa đơn giản nhất là các văn bản cần thay thế khi thực thể được tham chiếu đến

Để tham chiếu đến nội dung thực thể có tên Name ta dùng cú pháp: &Name;

Để khai báo thực thể ngoại ta dùng cú pháp:

<!ENTITY Name SYSTEM URI>

Hoặc <!ENTITY Name PUBLIC FPI URI>

Trong đó ý nghĩa từ khoá SYSTEM và PUBLIC tương tự như trong định nghĩa DTD ngoại

a2 Thực thể tham số

Cú pháp khai báo thực thể tham số nội và ngoại lần lượt như sau:

<!ENTITY %Name Definition>

<!ENTITY %Name SYSTEM URI>

Hoặc <!ENTITY %Name PUBLIC FPI URI>

Để tham chiếu đến nội dung thực thể tham số có tên Name ta dùng cú pháp:

%Name;

a3 Sự khác nhau giữa thực thể tham số và thực thể tổng quát

Ta sử dụng tham chiếu thực thể tổng quát để trình xử lý XML thay thế nội dung tham chiếu bằng chính nội dung của thực thể trong tài liệu Ta không thể dùng

nó trong bản thân các khai báo DTD Tham chiếu đến các thực thể tham số chỉ có thể sử dụng trong định nghĩa DTD Thực thể tham số nội chỉ có thể dùng trong phần khai báo DTD chính Khi sử dụng DTD tham chiếu ngoại, các thực thể tham số có thể dùng ở bất kỳ đâu trong khai báo DTD Mục đích của việc dùng thực thể tham

số là tránh các khai báo lặp đi lặp lại khi định nghĩa DTD, khi cần thiết ta chỉ thay

đổi nội dung thực thể thì các định nghĩa DTD sử dụng tham chiếu đến thực thể sẽ tự

động thay đổi theo

Ví dụ, xây dựng lại file data.dtd như sau:

<!ENTITY %canbo “(hoten, ngaysinh, gioitinh, khoa⏐phong)”>

<!ELEMENT danhsachCBCNV (giangvien⏐nhanvien)*>

<!ELEMENT giangvien %canbo;>

<!ELEMENT nhanvien %canbo;>

<!ELEMENT hoten (#PCDATA)>

<!ELEMENT ngaysinh (#PCDATA)>

<!ELEMENT gioitinh (#PCDATA)>

<!ELEMENT khoa (#PCDATA)>

<!ELEMENT phong (#PCDATA)>

Khi đó, nội dung file danhsach.xml sử dụng định nghĩa DTD trên là:

Trong phần 2.2.2(b) ta dã nói qua về thuộc tính của các thẻ, ý nghĩa và vị trí

đặt chúng Tuy nhiên, trước khi đặt thuộc tính cho một thẻ nào đó, ta cần phải định nghĩa thuộc tính sẽ kết hợp với thẻ đó trong DTD Cú pháp khai báo thuộc tính như sau:

<!ATTLIST Name

attName Type Default_value

attName Type Default_value