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

Mục lục
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.1.2. Mô hình use-case 51
3.2. Phân tích và thiết kế hệ thống 61
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





Danh môc c¸c thuËt ng÷
RUP Rational Unified Process
UML Unified Modeling Language

XML eXtensible Markup Language
SGML Standard Generalized Markup Language
HTML Hypertext Markup Language
W3C World Wide Web Consortium

DTD Document Type Definition
DOM Document Object Model

CDATA Character Data
PCDATA Parsed Character Data
FPI Formal Public Identifier
IE Internet Explorer
CSS Cascading Style Sheet
PHP Personal Home Page
URL Universal Resource Locator
URI Universal Resource Identifier
TIM Telecommunication Interchange Markup
PDML Product Data Markup Language
IFX Financial Exchange


i
Danh mục các bảng v hình vẽ
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

ii
Hình 3.15: Biểu đồ cộng tác thực thi use-case Tạo nội dung mới
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

iii
Mở đầu
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
luận văn tốt nghiệp.
Phơng pháp phát triển phần mềm hớng đối tợng sử dụng đối với bài toán
này là thích hợp do Hệ thống Trợ giúp Lập bài giảng phải thờng xuyên đợc thay
đổi, bổ sung, nâng cấp. Trong luận văn này, công cụ đợc sử dụng để phân tích,
thiết kế hớng đối tợng và biểu diễn các bản thiết kế là Ngôn ngữ mô hình hóa
thống nhất UML cùng với phần mềm Rational Rose. Hơn nữa, để biểu diễn dữ
liệu trên nền Web thì hiện nay, ngôn ngữ định dạng mở rộng XML cũng đang trở
nên khá phổ biến.
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

1
Chơng 3: áp dụng qui trình RUP để thực hiện phân tích thiết kế Hệ
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.

2
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 3
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 trng 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 nhng 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
triển các phần mềm hớng đối tợng. Nó là khung làm việc chung mà có thể đợc
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 4
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.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 5
ắ 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.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng

Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 6
ắ 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
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 7
1.2. Các luồng công việc cơ bản
Nh đã trình bày ở trên, các bớc lặp có sự khác nhau về khối lợng mỗi loại
công việc cần thực hiện, tuy nhiên về cơ bản chúng đều phải thực hiện các hoạt
động: mô hình hoá nghiệp vụ, xác định yêu cầu, phân tích, thiết kế. Sau đây sẽ đề
cập chi tiết những hoạt động này.
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.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 8
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ụ.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 9
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 đó.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 10
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à use-case để chuẩn bị một phiên bản đầu tiên của mô hình use-

case.
ắ 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 nhng đợ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 lu ý 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à
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 11

một use-case hay không thì phải xem nó có đầy đủ hay nó luôn đi tiếp sau một use-
case khác hay không.
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 cha 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
cha?
ắ Chuỗi các hành động đã đúng, đầy đủ và có thể hiểu đợc đối với mỗi use-
case cha?
ắ 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 cha?
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 12
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, lu ý tách riêng các trách nhiệm của hệ thống ra khỏi
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 13
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
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 14
để 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, use-case, mô tả chúng trong các biểu đồ và diễn đạt mô hình use-
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.

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.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 15
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 cha giải quyết đợc. Đó là do ta đã sử dụng ngôn ngữ trực quan
nhng 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
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 16
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 nhng 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.
a2. Xác định các lớp thực thể
Một công việc nữa cần đợc thực hiện trong phân tích kiến trúc là đa ra các
lớp thực thể quan trọng nhất dựa trên các lớp miền và các thực thể nghiệp vụ đã

đợc xác định trong quá trình nắm bắt yêu cầu. Vì đa số các lớp sẽ đợc xác định
khi thực thi use-case nên cần tránh xác định quá nhiều lớp và đi quá chi tiết tại
bớc này, chỉ cần phác thảo ban đầu về các lớp có tầm quan trọng về mặt kiến trúc
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 trng 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.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 17
ắ 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 nhng đợ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ể lu 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
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 18
đị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 lu ý: 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 nhng đợ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.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 19
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.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng
Nguyễn Thị Hồng Hơng Luận văn thạc sỹ 20
ắ 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á
và chia sẻ thông tin.
ắ Xác định các cơ chế thiết kế chung. Các cơ chế này có thể thể hiện dới dạng
các lớp thiết kế, các cộng tác và các hệ thống con. Chúng đợc sử dụng để xử
lý những yêu cầu chung (ví dụ các yêu cầu đặc biệt đã xác định trong phân
tích). Có thể ngay từ ban đầu cha tìm đợc cơ chế mà lại tìm đợc khi khám
phá các thực thi use-case và các lớp thiết kế. Đa số các cơ chế chung cần
đợ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 đó.
Chơng 1: Quy trình phát triển phần mềm hớng đối tợng