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
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.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
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)
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
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
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-
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
ắ 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ọ
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.
đợ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
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.
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
Copyright: Tài liệu đại học ©