Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (5.21 MB, 169 trang )
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
CH
M CL C
NG I. Đ I C
NG V PHÂN TệCH THI T K H TH NG ............................................. 2
1.2 Nhi m vụ, vai trò c a h th ng thông tin quản lý .................................................................. 2
1.3 Các thƠnh phần h p thƠnh c a h th ng thông tin ................................................................. 2
2. Các h th ng tự đ ng hóa ............................................................................................................. 2
3. Phơn tích thi t k lƠ gì, t i sao phải phơn tích thi t k h th ng ? ............................................... 2
4.1 Phát triển h th ng thông tin – m t bƠi toán ph c t p ........................................................... 7
4.2 Chu trình phát triển phần m m (Software Development Life Cycle) .................................... 8
4.3 Các giai đo n c a quy trình phát triển phần m m .................................................................. 9
5. Các cách ti p cận phơn tích vƠ thi t k h th ng thông tin ........................................................ 12
5.1 Ph ng pháp h ng cấu trúc................................................................................................ 12
5.2 Ph ng pháp h ng đ i t ng ............................................................................................. 12
5.3 u điểm c a mô hình h ng đ i t ng ............................................................................... 12
CH NG II. T NG QUAN V PHÂN TệCH THI T K H
NG Đ I T
NG ....................... 13
1. Nhắc l i các khái ni m c bản v h ng đ i t ng ................................................................... 13
1.1 Đ i t ng (Object) ............................................................................................................... 13
1.2 L p (Class) vƠ thể hi n (instance) ........................................................................................ 13
1.3 Sự trao đ i vƠ thông đi p (message) .................................................................................... 13
1.4 Sự phơn cấp (hierarchy) ....................................................................................................... 14
1.5 Tính bao bọc (encapsulation) ............................................................................................... 17
1.6 Tính đa hình (polymorphism) .............................................................................................. 17
2. Gi i thi u ngôn ngữ mô hình hóa h p nhất UML (Unified Modeling Language) .................... 18
2.1 UML là gì ? .......................................................................................................................... 19
2.2 Lịch sử phát triển vƠ t ng lai c a UML ............................................................................. 20
2.3 T i sao dùng UML ?............................................................................................................. 22
2.4 M t s đặc điểm chính c a ph ng pháp phơn tích thi t k bằng UML ............................. 24
2.5 Các thƠnh phần c a UML..................................................................................................... 25
2.6 M r ng UML ...................................................................................................................... 30
3. Công cụ hỗ tr Visual Paradigm ................................................................................................ 32
3.1 CƠi đặt phần m m ................................................................................................................. 32
3.2 MƠn hình kh i đ ng Visual Paradigm ................................................................................. 39
CH NG 3. PHÂN TệCH H TH NG ........................................................................................... 42
1. Gi i thi u Case study ................................................................................................................. 42
2. Xác định yêu cầu c a h th ng................................................................................................... 43
3. Mô hình hóa Use case ................................................................................................................ 45
3.1 Gi i thi u.............................................................................................................................. 45
3.2 Mục đích vƠ các ký hi u trong Use case .............................................................................. 47
3.3 Các kiểu k t h p (association) vƠ quan h (relationship) .................................................... 50
3.4 S đ Use case ..................................................................................................................... 53
4. Mô hình hóa nghi p vụ (Business modeling)............................................................................. 65
5.2 S đ l p (Class diagram) .................................................................................................... 93
5.4 Xác định m i quan h giữa các l p .................................................................................... 111
CH NG 4. THI T K H TH NG ............................................................................................ 121
1. Thi t k l p .............................................................................................................................. 121
1.1 Các tiên đ vƠ h luận trong thi t k h ng đ i t ng ...................................................... 121
1.2 Thi t k l p ........................................................................................................................ 125
2. Thi t k Use case...................................................................................................................... 134
2.2 Xác định l p tầng truy cập dữ li u (data layer) ............................................................... 137
2.3 Xác định l p tầng giao di n ng i dùng (user interface layer) .......................................... 153
Biên soạn: Nguyễn Thị Điệu
1
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
CH
NG I. Đ I C
NG V PHÂN TệCH THI T K H TH NG
1. Các h th ng thông tin
NgƠy nay, h th ng thông tin đư đ c ng dụng trong mọi lĩnh vựa khác nhau c a đ i s ng
xư h i. Tuỳ theo quan điểm mƠ có thể phơn lo i các h th ng thông tin theo các tiêu chí khác nhau.
Xét v mặt ng dụng, h th ng thông tin có thể đ
c phơn chia thƠnh m t s d ng nh sau:
H th ng thông tin quản lý: Bao g m các h th ng thông tin hỗ tr các ho t đ ng nghi p
vụ vƠ quản lý c a các doanh nghi p, các t ch c. Ví dụ các h th ng quản lý nhơn sự, h
th ng k toán, h th ng tính c c vƠ chăm sóc khách hƠng, h th ng quản lý th vi n, h
th ng đƠo t o trực tuy n ...
Các h th ng Website: lƠ các h th ng có nhi m vụ cung cấp thông tin cho ng
i dùng trên
môi tr ng m ng Internet. Các h th ng Website có đặc điểm lƠ thông tin cung cấp cho
ng i dùng có tính đa d ng (có thể lƠ tin t c hoặc các d ng file đa ph ng ti n) vƠ đ c cập
nhật th
ng xuyên.
H th ng th
ng m i đi n tử: LƠ các h th ng website đặc bi t phục vụ vi c trao đ i mua
bán hàng hoá, dich vụ trên môi tr ng Internet. H th ng th ng m i đi n tử bao g m cả
các n n tảng hỗ tr các giao th c mua bán, các hình th c thanh toán, chuyển giao hàng hoá.
H th ng đi u khiển: lƠ các h th ng phần m m gắn v i các thi t bị phần c ng hoặc các h
th ng khác nhằm mục đích đi u khiển vƠ giám sát ho t đ ng c a thi t bị hay h th ng đó.
Mỗi lo i h th ng thông tin có những đặc tr ng riêng vƠ cũng đặt ra những yêu cầu riêng
cho vi c phát triển h th ng. Ví dụ, các h th ng đi u khiển đòi h i những yêu cầu v môi tr ng
phát triển, h đi u hƠnh vƠ ngôn ngữ lập trình riêng; các h website thực thi các ch c năng trên m i
tr ng m ng phơn tán đòi h i cách phát triển riêng...Do vậy, không có m t ph ng pháp luận chung
cho tất cả các d ng h th ng thông tin. Ph m vi c a tƠi li u nƠy nhằm gi i thi u m t s khái ni m
c bản c a UML cho phát phiển các h th ng vƠ để d dƠng minh ho chúng ta s xem xét vấn đ
phát triển d ng h th ng thông tin ph bi n nhất lƠ h th ng thông tin quản lý.
2. Phơn tích thi t k là gì, t i sao phải phơn tích thi t k h th ng ?
H th ng thông tin tin học lƠ m t ng dụng đầy đ vƠ toƠn di n nhất các thƠnh tựu c a công
ngh thông tin vƠo t ch c, quản lý. NgƠy nay, không m t t ch c hay đ n vị nƠo lƠ không có nhu
cầu xơy dựng h th ng thông tin. Không những nhu cầu xơy dựng h th ng thông tin tăng lên, mƠ
quy mô vƠ m c đ ph c t p c a chúng cũng không ngừng tăng lên. Do đặc thù c a h th ng thông
tin lƠ sản phẩm “không nhìn thấy”, nên phơn tích thi t k tr thƠnh m t yêu cầu bắt bu c để có đ c
m t h th ng t t.
Trong thực t , để giải quy t m t vấn đ hay m t bƠi toán chúng ta cần xác định rõ yêu cầu
c a bƠi toán, xác định ph ng pháp và các b c để giải bƠi toán đó sao cho hi u quả nhất, nhanh
nhất vƠ k t quả chính xác nhất.
Biên soạn: Nguyễn Thị Điệu
2
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Phơn tích thi t k h th ng thông tin lƠ quá trình tìm hiểu vƠ mô ph ng l i hi n t ng, quy
trình nghi p vụ trong th gi i thực từ đó xơy dựng h th ng để giải quy t bƠi toán đặt ra trên máy
tính (Hình 1.1).
Chất l
ng phân tích thi t k lƠ nhơn t quy t định chất l
hoặc phân tích không t t s dẫn đ n phần m m chất l
Không quản lý đ
ng phần m m, không phân tích
ng thấp:
c những thay đ i v yêu cầu
Khó kiểm thử
Khó bảo trì
Không có tính ti n hóa
Không tái sử dụng đ
c
Thế giới
thực
Thiết
kế
Lập
trình
Phần mềm
Kiểm
thử
Hình 1.1 Mô phỏng quá trình phát triển HTTT
Theo đi u tra c a IBM, thì những sai sót trong phơn tích vƠ thi t k lƠm cho chi phí bảo trì
trung bình c a các h th ng thông tin chi m t i gần 60% t ng chi phí. M t lỗi b sót trong giai
đo n phơn tích đ n khi lập trình vƠ cƠi đặt m i phát hi n ra thì chi phí sửa chữa tăng 40 lần, vƠ n u
để đ n giai đo n bảo trì m i phát hi n ra thì chi phí sửa chữa tăng 90 lần. Thêm vƠo đó, n u thi u
các tài li u phơn tích thi t k có thể dẫn đ n h th ng không thể bảo trì.
Thi t k t t s đem l i m t sản phẩm phần m m chất l
D dƠng thay đ i theo các yêu cầu c a ng
ng t t:
i sử dụng
D dƠng kiểm thử
D bảo trì
Có tính ti n hóa cao
Có khả năng tái sử dụng
Do tầm quan trọng vƠ nhu cầu thực t , phơn tích các h th ng thông tin đư tr thƠnh m t
ngh nghi p có tính chuyên môn cao. M t kỹ s công ngh thông tin bất kỳ không thể không bi t
đọc các bản v phơn tích vƠ thi t k h th ng thông tin. M t kỹ s CNTT sau m t năm có thể tr
thƠnh lập trình viên gi i, thì họ cần phải mất nhi u năm m i tr thƠnh m t nhƠ phơn tích vƠ thi t k
viên vƠ sau nhi u năm nữa m i tr thƠnh m t nhƠ phơn tích thi t k viên gi i.
Biên soạn: Nguyễn Thị Điệu
3
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
3. Các cách ti p c n phơn tích thi t k h th ng
Trong những năm 70 - 80, ph
ng pháp h
ng cấu trúc đ
c coi lƠ ph
ng pháp chuẩn để
phát triển phần m m. Tuy nhiên, ph ng pháp nƠy t ra không phù h p trong phát triển các h phần
m m l n vƠ đặc bi t lƠ kém hi u quả trong sử dụng l i - m t yêu cầu quan trọng trong công nghi p
phần m m. Thập niên 90 ch ng ki n sự n r trong nghiên c u vƠ xơy dựng ph ng pháp luận phát
triển phần m m h ng đ i t ng vƠ nhanh chóng tr thƠnh ph bi n trong công nghi p phần m m
ngƠy nay. Để hiểu rõ phần nƠo sự khác bi t nƠy phần này dành so sánh m t s khác bi t giữa hai
ph ng pháp nƠy.
3.1 Giới thiệu về phương pháp phát triển hướng cấu trúc
Đặc tr ng c a ph ng pháp h ng cấu trúc lƠ phơn chia ch ng trình chính thƠnh nhi u
ch ng trình con, mỗi ch ng trình con nhằm đ n thực hi n m t công vi c xác định. Trong ph ng
pháp h ng cấu trúc, phần m m đ c thi t k dựa trên m t trong hai h ng: h ng dữ li u vƠ
h ng hƠnh đ ng.
-
Cách ti p cận h ng dữ li u xơy dựng phần m m dựa trên vi c phơn rư phần m m theo các
ch c năng cần đáp ng vƠ dữ li u cho các ch c năng đó. Cách ti p cận h ng dữ li u s
giúp cho những ng
-
i phát triển h th ng d dƠng xơy dựng ngơn hƠng dữ li u.
Cách ti p cận h ng hƠnh đ ng l i tập trung phơn tích h phần m m dựa trên các ho t đ ng
thực thi các ch c năng c a phần m m đó.
Cách th c thực hi n c a ph ng pháp h ng cấu trúc lƠ ph ng pháp thi t k từ trên
xu ng (top-down). Ph ng pháp nƠy ti n hƠnh phơn rư bƠi toán thƠnh các bƠi toán nh h n, r i ti p
tục phơn rư các bƠi toán con cho đ n khi nhận đ c các bƠi toán có thể cƠi đặt đ c ngay sử dụng
các hƠm c a ngôn ngữ lập trình h ng cấu trúc.
Ph ng pháp h ng cấu trúc có u điểm lƠ t duy phơn tích thi t k rõ rƠng, ch
sáng s a d hiểu. Tuy nhiên, ph ng pháp nƠy có m t s nh c điểm sau:
- Không hỗ tr vi c sử dụng l i. Các ch
ng trình h
ng trình
ng cấu trúc phụ thu c chặt ch vƠo
cấu trúc dữ li u vƠ bƠi toán cụ thể, do đó không thể dùng l i m t modul nƠo đó trong phần
m m nƠy cho phần m m m i v i các yêu cầu v dữ li u khác.
- Không phù h p cho phát triển các phần m m l n. N u h th ng thông tin l n, vi c phơn ra
thƠnh các bƠi toán con cũng nh phơn các bƠi toán con thƠnh các modul vƠ quản lý m i quan
h giữa các modul đó s lƠ không phải lƠ d dƠng vƠ d gơy ra các lỗi trong phơn tích vƠ
thi t k h th ng, cũng nh khó kiểm thử vƠ bảo trì.
Mô hình dữ li u trong ph ng pháp nƠy trả l i cho cơu h i H th ng sử dụng dữ li u gì? Mô
tả các dữ li u chính s có trong h th ng vƠ m i quan h rƠng bu c giữa chúng sử dụng s đ quan
h thực thể, các bảng thu c tính, các rƠng bu c dữ li u; mô hình thực thể (Entity Relationship
Diagram - ERD) phản ánh h th ng đầy đ h n, b sung cho BFD (Bussiness Function Diagrammô hình phơn rư ch c năng); kho dữ li u (Data store): Ký hi u bằng 2 đ ng kẻ song song hoặc
hình chữ nhật tròn góc, biểu di n thông tin cần l u trữ (s lƠ file hoặc CSDL)
Kho dữ li u
Biên soạn: Nguyễn Thị Điệu
4
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Tác nhơn ngoƠi: Ng i/nhóm ng i/t ch c bên ngoƠi h th ng ti p xúc v i h th ng. Đó lƠ
ngu n cung cấp thông tin, lƠ ngu n s ng còn c a h th ng. Tác nhơn trong: Ch c năng/quá trình
trong h th ng. Các mô hình có quan h mật thi t, xơy dựng theo th tự: BFD, ERD, DFD(Data
Flow Diagram) khi định h ng lập trình, thể hi n rõ quan h . N u cần lƠm rõ các yêu cầu ng i
dùng, DFD đ c xơy dựng tr c thể hi n quy trình nghi p vụ, sau đó xơy dựng BFD và ERD
Ví d : S đ phơn rư ch c năng cho h th ng Quản lý doanh nghi p
Hình 1.2 Sơ đồ phân rã chức năng
Hình 1.3 Mối quan hệ giữa các chức năng trong hệ thống
3.2 Giới thiệu về phương pháp phát triển hệ thống hướng đối tượng
Khác v i ph ng pháp h ng cấu trúc chỉ tập trung hoặc vƠo dữ li u hoặc vƠo hƠnh đ ng,
ng pháp h ng đ i t ng tập trung vƠo cả hai khía c nh c a h th ng lƠ dữ li u vƠ hƠnh đ ng.
ph
Cách ti p cận h ng đ i t ng lƠ m t l i t duy theo cách ánh x các thƠnh phần trong bƠi
toán vƠo các đ i t ng ngoƠi đ i thực. V i cách ti p cận nƠy, m t h th ng đ c chia t ng ng
thƠnh các thƠnh phần nh gọi lƠ các đ i t ng, mỗi đ i t ng bao g m đầy đ cả dữ li u vƠ hƠnh
đ ng liên quan đ n đ i t ng đó. Các đ i t ng trong m t h th ng t ng đ i đ c lập v i nhau vƠ
phần m m s đ c xơy dựng bằng cách k t h p các đ i t ng đó l i v i nhau thông qua các m i
quan h vƠ t ng tác giữa chúng. Các nguyên tắc c bản c a ph ng pháp h ng đ i t ng bao
g m:
-
Trừu t ng hóa (abstraction): trong ph ng pháp h ng đ i t ng, các thực thể phần m m
đ c mô hình hóa d i d ng các đ i t ng. Các đ i t ng nƠy đ c trừu t ng hóa m c
cao h n dựa trên thu c tính vƠ ph ng th c mô tả đ i t ng để t o thƠnh các l p. Các l p
Biên soạn: Nguyễn Thị Điệu
5
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
cũng s đ c trừu t ng hóa m c cao h n nữa để t o thƠnh m t s đ các l p đ c k
thừa lẫn nhau. Trong ph ng pháp h ng đ i t ng có thể t n t i những l p không có đ i
t ng t ng ng, gọi lƠ l p trừu t ng. Nh vậy, nguyên tắc c bản để xơy dựng các khái
ni m trong h ng đ i t ng lƠ sự trừu t ng hóa theo các m c đ khác nhau.
-
Tính đóng gói (encapsulation) vƠ ẩn dấu thông tin: các đ i t ng có thể có những ph ng
th c hoặc thu c tính riêng (kiểu private) mƠ các đ i t ng khác không thể sử dụng đ c.
Dựa trên nguyên tắc ẩn giấu thông tin nƠy, cƠi đặt c a các đ i t ng s hoƠn toƠn đ c lập
v i các đ i t ng khác, các l p đ c lập v i nhau vƠ cao h n nữa lƠ cƠi đặt c a h th ng
hoƠn toƠn đ c lập v i ng i sử dụng cũng nh các h th ng khác sử dụng k t quả c a nó.
-
Tính modul hóa (modularity): các bƠi toán s đ
đ n giản vƠ quản lý đ c.
-
Tính phơn cấp (hierarchy): cấu trúc chung c a m t h th ng h
cấp theo các m c đ trừu t ng từ cao đ n thấp.
u điểm n i bật c a ph ng pháp h
ph ng pháp h ng cấu trúc:
ng đ i t
c phơn chia thƠnh những vấn đ nh h n,
ng lƠ đư giải quy t đ
ng đ i t
ng lƠ d ng phơn
c các vấn đ nảy sinh v i
-
Hỗ tr sử dụng l i mư ngu n : Ch ng trình lập trình theo ph ng pháp h ng đ i t ng
th ng đ c chia thƠnh các gói lƠ các nhóm c a các l p đ i t ng khác nhau. Các gói này
ho t đ ng t ng đ i đ c lập vƠ hoƠn toƠn có thể sử dụng l i trong các h th ng thông tin
t ng tự.
-
Phù h p v i các h th ng l n: Ph ng pháp h ng đ i t ng không chia bƠi toán thành các
bƠi toán nh mƠ tập trung vƠo vi c xác định các đ i t ng, dữ li u vƠ hƠnh đ ng gắn v i đ i
t ng vƠ m i quan h giữa các đ i t ng. Các đ i t ng ho t đ ng đ c lập vƠ chỉ thực hi n
hƠnh đ ng khi nhận đ c yêu cầu từ các đ i t ng khác. Vì vậy, ph ng pháp nƠy hỗ tr
phơn tích, thi t k vƠ quản lý m t h th ng l n, có thể mô tả các ho t đ ng nghi p vụ ph c
t p b i quá trình phơn tích thi t k không phụ thu c vƠo s bi n dữ li u hay s l ng thao
tác cần thực hi n mƠ chỉ quan tơm đ n các đ i t ng t n t i trong h th ng đó.
Ví d : Cũng vẫn v i bƠi toán Quản lý doanh nghi p. V i ph ng pháp ti p cận nƠy vi c phơn tích
bƠi toán xoay quanh vi c xác định các l p, đ i t ng c a bƠi toán:
Nhơn sự
Vật t
Hàng hóa
Đ n hƠng
…
4. Quy trình/Chu trình phát triển h th ng thông tin
Vi c phát triển các h th ng thông tin không chỉ đ n giản lƠ lập trình mƠ luôn đ
m t ti n trình hoƠn chỉnh.
c xem nh
Tiến trình phần mềm là phương cách sản xuất ra phần mềm với các thành phần chủ yếu bao
gồm: mô hình vòng đời phát triển phần mềm, các công cụ hỗ trợ cho phát triển phần mềm và những
người trong nhóm phát triển phần mềm.
Biên soạn: Nguyễn Thị Điệu
6
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Nh vậy, ti n trình phát triển phần m m nói chung lƠ sự k t h p cả hai khía c nh kỹ thuật
(vòng đ i phát triển, ph ng pháp phát triển, các công cụ vƠ ngôn ngữ sử dụng, …) vƠ khía c nh
quản lý (quản lý dự án phần m m).
4.1 Phát triển hệ thống thông tin – một bài toán phức tạp
Kinh nghi m c a nhi u nhƠ thi t k vƠ phát triển cho thấy phát triển phần m m lƠ m t bƠi
toán ph c t p. Xin nêu m t s các lý do th ng đ c kể đ n:
Những ng
i phát triển rất khó hiểu cho đúng những gì ng
Yêu cầu c a ng
Yêu cầu th
ng đ
i dùng th
i dùng cần.
ng thay đ i theo th i gian phát triển.
c miêu tả bằng văn bản, dƠi dòng, nhi u khi mơu thuẫn nhau.
Đ i quơn phát triển phần m m v n lƠ những ng i “ngoƠi cu c”, rất khó nhận th c thấu
đáo các m i quan h ti m ẩn vƠ ph c t p cần đ c thể hi n chính xác trong các ng
dụng l n.
Khả năng nắm bắt các dữ li u ph c t p c a con ng
i (t i cùng m t th i điểm) lƠ có
h n.
Khó định l ng chính xác hi u xuất c a thƠnh phẩm vƠ th a mưn chính xác sự mong ch
từ phía ng i dùng.
Chọn phần c ng vƠ phần m m thích h p cho giải pháp lƠ m t trong những thách th c
l n đ i v i Designer.
Phần m m ngoƠi ra còn cần có khả năng thích ứng và mở rộng. Phần m m đ c thi t k t t
lƠ phần m m đ ng vững tr c những bi n đ i trong môi tr ng, dừ từ phía c ng đ ng ng i dùng
hay từ phía công ngh . Ví dụ phần m m đ c phát triển cho m t Ngơn hƠng cần có khả năng tái sử
dụng cho Ngơn hƠng khác v i rất ít sửa đ i hoặc hoƠn toƠn không cần sửa đ i. Phần m m th a mưn
các yêu cầu đó đ c coi lƠ phần m m có khả năng thích ng.
M t phần m m có khả năng m r ng lƠ phần m m đ
theo yêu cầu c a ng
i dùng mƠ không cần sửa chữa nhi u.
Chính vì vậy, m t s khác khi m khuy t th
c thi t k sao cho d dƠng phát triển
Hiểu không đúng những gì ng
ng gặp trong phát triển phần m m lƠ:
i dùng cần.
Không thể thích ng cho phù h p v i những thay đ i v yêu cầu đ i v i h th ng.
Các module không kh p nhau.
Phần m m khó bảo trì vƠ nơng cấp, m r ng.
Phát hi n tr các lỗ h ng c a dự án.
Chất l
ng phần m m kém.
Hi u năng phần m m thấp.
Biên soạn: Nguyễn Thị Điệu
7
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Các thƠnh viên trong nhóm không bi t đ
phải thay đ i.
c ai đư thay đ i cƠi gì, khi nƠo,
đơu, t i sao
4.2 Chu trình phát triển phần mềm (Software Development Life Cycle)
Vì sao phát triển phần m m cần phải có quy trình ? Phát triển phần m m lƠ m t bƠi toán
khó, nên có l tr c h t ta cần điểm qua m t s công vi c căn bản c a quá trình nƠy. Th ng ng i
ta hay tập h p chúng theo ti n trình th i gian m t cách t ng đ i, xoay quanh chu trình c a m t
phần m m, dẫn t i k t quả khái ni m Quy trình phát triển phần m m (Software development life
cycle - SDLC) nh sau: Chu trình phát triển phần m m lƠ m t chuỗi các ho t đ ng c a nhƠ phơn
tích (Analyst), nhƠ thi t k (Designer), ng i phát triển (Developer) vƠ ng i dùng (User) để phát
triển vƠ thực hi n h th ng thông tin. Những ho t đ ng nƠy đ c thực hi n trong nhi u giai đo n
khác nhau, trong đó:
Nhà phân tích (Analyst): lƠ ng
i nghiên c u yêu cầu c a khách hƠng/ng
i dùng để
định nghĩa m t ph m vi bƠi toán, nhận d ng nhu cầu c a t ch c, xác định xem nhân
lực, ph ng pháp vƠ công ngh máy tính có thể lƠm sao để cải thi n m t cách t t nhất
công tác c a t ch c nƠy.
Nhà thiết kế (Designer): thi t k h th ng theo h ng cấu trúc c a database, screens,
forms và reports – quy t định các yêu cầu v phần c ng vƠ phần m m cho h th ng cần
đ c phát triển.
Chuyên gia lĩnh vực (Domain experts): lƠ những ng i hiểu thực chất vấn đ cùng tất
cả những sự ph c t p c a h th ng cần tin học hóa. Họ không nhất thi t phải lƠ nhƠ lập
trình, nh ng họ có thể giúp nhƠ lập trình hiểu yêu cầu đặt ra đ i v i h th ng cần phát
triển. Quá trình phát triển phần m m có thể có rất nhi u thuận l i n u đ i ngũ lƠm phần
m m có đ c sự tr giúp c a họ.
Lập trình viên (Programmer): lƠ những ng i dựa trên các phơn tích vƠ thi t k để vi t
ch ng trình (coding) cho h th ng bằng ngôn ngữ lập trình đư đ c th ng nhất.
Người dùng (User): lƠ đ i t
ng phục vụ c a h th ng cần đ
c phát triển.
Để cho rõ h n, xin lấy ví dụ v m t vấn đ đ n giản sau: Ng i bình th
nhìn m t chi c xe ô tô th ng s có m t b c tranh từ bên ngoƠi nh sau:
ng chúng ta khi
Vấn đ
Hình 1.4 Nhìn vấn đề ô tô của người bình thường
Chuyên gia lĩnh vực s giúp nhƠ phơn tích "trình bƠy l i" vấn đ nh sau:
Biên soạn: Nguyễn Thị Điệu
8
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 1.5 Nhìn vấn đề ô tô của chuyên gia phân tích
Chính vì sự tr giúp c a chuyên gia lĩnh vực có thể đóng vai trò rất quan trọng nên trong
những giai đo n đầu c a quá trình phát triển phần m m, k t quả phơn tích nên đ c thể hi n sao
cho d hiểu đ i v i các chuyên gia lĩnh vực. Đơy cũng lƠ môt trong rất nhi u lý do khi n cho
ph ng pháp h ng đ i t ng đ c nhi u ng i h ng ng.
4.3 Các giai đoạn của quy trình phát triển phần mềm
Quy trình c a m t phần m m có thể đ
c chia thƠnh các giai đo n nh sau:
Nghiên c u s b (Preliminary Investigation hay còn gọi lƠ Feasibility Study)
Phân tích yêu cầu (Analysis)
Phân tích và thi t k h th ng (Analysis and Design of the System)
Xơy dựng phần m m (Software Construction)
Thử nghi m h th ng (System Testing)
Thực hi n triển khai (System Implementation)
Bảo trì vƠ nơng cấp (Maintain and upgrade)
a) Nghiên cứu sơ bộ
Tr c khi bắt tay vƠo m t dự án, b n phải có m t ý t ng cho nó. Ý t ng nƠy đi song song
v i vi c nắm bắt các yêu cầu vƠ xuất hi n trong giai đo n kh i đầu. Nó hoƠn tất m t phát biểu: "H
th ng mƠ chúng ta mong mu n s lƠm đ c những vi c nh sau ....". Trong su t giai đo n nƠy,
chúng ta t o nên m t b c tranh v ý t ng đó, rất nhi u giả thuy t s đ c công nhận hay lo i b .
Các ho t đ ng trong th i gian nƠy th ng bao g m: thu thập các ý tưởng, nhận biết rủi ro,
nhận biết các giao diện bên ngoài, nhận biết các các chức năng chính mƠ h th ng cần cung cấp, vƠ
có thể tạo một vài nguyên mẫu dùng để “minh ch ng các khái ni m c a h th ng”. Ý t ng có thể
đ n từ nhi u ngu n khác nhau: khách hƠng, chuyên gia lĩnh vực, các nhƠ phát triển khác, chuyên gia
v kỹ ngh , các bản nghiên c u tính khả thi cũng nh vi c xem xét các h th ng khác đang t n t i.
M t khía c nh cần nhắc t i lƠ code vi t trong th i kỳ nƠy th ng s bị "b đi”, b i chúng đ c vi t
nhằm mục đích thẩm tra hay tr giúp các giả thuy t khác nhau, ch ch a phải th code đ c vi t
theo k t quả phơn tích vƠ thi t k thấu đáo.
Trong giai đọan nghiên c u s b , nhóm phát triển h th ng cần xem xét các yêu cầu c a
doanh nghi p (cần dùng h th ng), những ngu n tƠi nguyên có thể sử dụng, công ngh cũng nh
c ng đ ng ng i dùng cùng các ý t ng c a họ đ i v i h th ng m i. Có thể thực hi n thảo luận,
Biên soạn: Nguyễn Thị Điệu
9
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
nghiên c u, xem xét khía c nh th ng m i, phơn tích khả năng l i-lỗ, phơn tích các tr ng h p sử
dụng vƠ t o các nguyên mẫu để xơy dựng nên m t khái ni m cho h th ng đích cùng v i các mục
đích, quy n u tiên vƠ ph m vi c a nó.
Th
ng trong giai đo n nƠy ng
i ta cũng ti n hƠnh t o m t phiên bản thô c a lịch trình vƠ
k ho ch sử dụng tƠi nguyên. M t giai đo n nghiên c u s b thích đáng s lập nên tập h p các yêu
cầu (dù m c đ khái quát cao) đ i v i m t h th ng khả thi vƠ đ c mong mu n, kể cả v ph ng
di n kỹ thuật lẫn xư h i. M t giai đo n nghiên c u s b không đ c thực hi n thoả đáng s dẫn t i
các h th ng không đ c mong mu n, đắt ti n, bất khả thi vƠ đ c định nghĩa lầm l c – những h
th ng thừ ng chẳng đ c hoƠn tất hay sử dụng.
K t quả c a giai đo n nghiên c u s b lƠ Báo cáo kết quả nghiên cứu tính khả thi. Khi h
th ng t ng lai đ c chấp nhận dựa trên bản báo cáo nƠy cũng lƠ lúc giai đo n Phơn tích bắt đầu.
b) Phân tích yêu cầu
Sau khi đư xem xét v tính khả thi c a h th ng cũng nh t o lập b c tranh s b c a dự án,
chúng ta b c sang giai đo n th ng đ c coi lƠ quan trọng nhất trong các công vi c lập trình: hiểu
h th ng cần xơy dựng. Ng i thực hi n công vi c nƠy lƠ nhà phân tích.
Quá trình phơn tích nhìn chung lƠ h quả c a vi c trả l i cơu h i “H th ng cần phải lƠm gì
?”. Quá trình phơn tích bao g m vi c nghiên c u chi ti t h th ng doanh nghi p hi n th i, tìm cho
ra nguyên lý ho t đ ng c a nó vƠ những vị trí có thể nơng cao, cải thi n. Bên c nh đó lƠ vi c nghiên
c u xem xét các ch c năng mƠ h th ng cần cung cấp vƠ các m i quan h c a chúng, bên trong
cũng nh v i phía ngoƠi h th ng. Trong toƠn b giai đo n nƠy, nhƠ phơn tích vƠ ng i dùng cần
c ng tác mật thi t v i nhau để xác định các yêu cầu đ i v i h th ng, t c lƠ các tính năng m i cần
phải đ c đ a vƠo h th ng.
Những mục tiêu cụ thể c a giai đo n phơn tích lƠ:
Xác định h th ng cần phải lƠm gì.
Nghiên c u thấu đáo tất cả các ch c năng cần cung cấp vƠ những y u t liên quan.
Xơy dựng m t mô hình nêu bật bản chất vẫn đ từ m t h
s ng).
ng nhìn có thực (trong đ i
Trao định nghĩa vấn đ cho chuyên gia lĩnh vực để nhận sự đánh giá, góp ý.
K t quả c a giai đo n phơn tích lƠ bản Đặc tả yêu cầu (Requirements Specifications).
c) Phân tích và thiết kế hệ thống
Sau khi có đ c các yêu cầu từ phía khách hƠng, xác định đ
cần xơy dựng, chúng ta bắt đầu phơn tích h th ng.
c các ch c năng c a h th ng
giai đo n nƠy, chúng ta s mô hình hóa h th ng d i d ng các biểu đ . Mục đích c a giai
đo n nƠy lƠ giúp ng i phát triển có cái nhìn sơu h n v toƠn cảnh h th ng, v các ho t đ ng s
di n ra trong h th ng. Từ đó xơy dựng dữ li u c a h th ng.
Biên soạn: Nguyễn Thị Điệu
10
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Sau giai đo n phơn tích, khi các yêu cầu cụ thể đ i v i h th ng đư đ c xác định, giai đo n
ti p theo lƠ thi t k cho các yêu cầu m i. Công tác thi t k xoay quanh cơu h i chính: H th ng lƠm
cách nƠo để th a mưn các yêu cầu đư đ
M t s công vi c th
ng đ
c nêu trong Đặc tả yêu cầu ?
c thực hi n trong giai đo n thi t k :
Nhận bi t form nhập li u tùy theo các thƠnh phần dữ li u cần nhập.
Nhận bi t reports vƠ những output mƠ h th ng m i phải sản sinh.
Thi t k forms (v trên giấy hay máy tínhm sử dụng công cụ thi t k ).
Nhận bi t các thƠnh phần dữ li u vƠ bảng để t o database.
c tính các th tục giải thích quá trình xử lý từ input đ n output.
K t quả c a giai đo n thi t k là Đặc tả thiết kế (Designer Specifications). Đặc tả thi t k
chi ti t s đ c chuyển sang cho các lập trình viên để thực hi n giai đo n xơy dựng phần m m.
d) Xây dựng phần mềm
Đơy lƠ giai đo n vi t l nh (code) thực sự, t o h th ng. Từng ng
i vi t code thực hi n
những yêu cầu đư đ c nhƠ thi t k định sẵn. Cũng chính ng i vi t code chịu trách nhi m vi t tƠi
li u liên quan đ n ch ng trình, giải thích th tục (procedure) mƠ anh ta t o nên đ c vi t nh th
nƠo vƠ lý do cho vi c nƠy.
Đảm bảo ch ng trình đ c vi t lên th a mưn mọi yêu cầu trong bản Đặc tả thi t k , ng i
vi t code cũng đ ng th i phải ti n hƠnh thử nghi m phần ch ng trình c a mình. Phần thử nghi m
trong giai đo n nƠy có thể đ c chia thƠnh hai b c chính:
Thử nghi m đ n vị (Unit test)
Ng i vi t code ch y thử các phần ch ng trình c a mình v i dữ li u giả (test/dummy data).
Vi c nƠy đ c thực hi n theo m t k ho ch thử, cũng do chính ng i vi t code so n ra. Mục đích
chính trong giai đo n thử nƠy lƠ xem ch ng trình có cho ra những k t quả mong đ i.
Thử nghi m đ n vị đ c lập
Công vi c nƠy do m t thƠnh viên khác trong nhóm đảm trách. Cần chon ng i không có liên
quan trực ti p đ n vi c vi t code c a đ n vị ch ng trình cần thử nghi m để đảm bảo tính “đ c
lập”. Công vi c thử đ t nƠy cũng đ c thực hi n dựa trên k ho ch thử do ng i vi t code so n lên.
e) Thử nghiệm hệ thống
Sau khi các th tục đ c thử nghi m riêng, cần phải thử nghi m l i toƠn b h th ng. Mọi
th tục đ c tích h p vƠ ch y thử, kiểm tra xem mọi chi ti t trong Đặc tả yêu cầu vƠ những mong
đ i c a ng i dùng có đ c th a mưn. Dữ li u thử cần đ c chọn lọc đặc bi t, k t quả cần đ c
chọn lọc đặc bi t, k t quả cần đ
c phơn tích để phát hi n mọi l ch l c so v i mong ch .
f) Thực hiện, triển khai
Trong giai đo n nƠy, h th ng vừa phát triển s đ c triển khai cho phía ng i dùng. Tr c
khi để ng i dùng thực sự bắt tay vƠo sử dụng h th ng, nhóm các nhƠ phát triển cần t o các file dữ
Biên soạn: Nguyễn Thị Điệu
11
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
li u cần thi t cũng nh huấn luy n cho ng
nhất.
i dùng, để đảm bảo h th ng đ
c sử dụng hữu hi u
g) Bảo trì, nâng cấp
Tùy theo các bi n đ i trong môi tr ng sử dụng, h th ng có thể tr nên lỗi th i hay cần
phải đ c sửa đ i nơng cấp để sử dụng có hi u quả. Ho t đ ng bảo trì h th ng có thể rất khác bi t
tùy theo m c đ sửa đ i vƠ nơng cấp cần thi t.
Hình 1.6 Sơ đồ tổng quát các giai đoạn của Quy trình phát
triển phần mềm
T NG K T CH
t
NG 1
Ch ng nƠy đư trình bƠy các n i dung m đầu cho phơn tích thi t k h th ng h
ng. Các n i dung c bản cần nh g m:
ng đ i
-
Có nhi u lo i h th ng thông tin khác nhau nh : h th ng thông tin quản lý, các Website,
các h th ng th ng m i, các h th ng đi u khiển ... Mỗi lo i h th ng thông tin s t ng
ng v i m t ph ng pháp phát triển riêng.
-
Vi c phát triển các h th ng thông tin nói chung đ c xem nh m t vòng đ i v i các pha :
Xác định yêu cầu, đặc tả, thi t k , cƠi đặt tích h p, bảo trì vƠ lo i b . Có hai mô hình vòng
đ i đ n giản vƠ hay dùng nhất lƠ mô hình thác n c vƠ mô hình lƠm bản mẫu nhanh.
-
Ph ng pháp phát triển phần m m h ng đ i t ng t ra có nhi u u điểm h n so v i
ph ng pháp h ng cấu trúc. Các pha đặc tr ng trong vòng đ i phát triển phần m m h ng
đ i t ng lƠ phơn tích h ng đ i t ng, thi t k h ng đ i t ng vƠ lập trình h ng đ i
t ng.
CÂU H I VÀ BÀI T P CH
NG I
Câu 1. T i sao khi xơy dựng m t HTTT cần phải có phơn tích vƠ thi t k h th ng?
Câu 2. Nêu các giai đo n trong m t chu trình phát triển m t h th ng thông tin? Giai đo n nƠo lƠ
quan trọng? Có thể thi u m t trong các giai đo n đó đ c không?
Câu 3. Kể tên m t s ví dụ cho các lo i h th ng thông tin: h th ng thông tin quản lý, h th ng
website th ng m i đi n tử, h th ng đi u khiển ...
Câu 5. So sánh hai ph
nh c điểm?
ng pháp phơn tích thi t k h
Biên soạn: Nguyễn Thị Điệu
ng cấu trúc vƠ h
ng ch c năng?
u vƠ
12
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
CH
NG II. T NG QUAN V PHÂN TệCH THI T K H
1. Nhắc l i các khái ni m c bản v h
ng đ i t
NG Đ I T
NG
ng
1.1 Đối tượng (Object)
Đ it
ng (Object) lƠ chìa khoá để hiểu v lập trình h
b n s phát hi n nhi u ví dụ trong thực t v đ i t
cái TV, cái xe đ p...
ng đ i t
ng. Thử nhìn xung quanh
ng: Cái máy tính, cái đèn bƠn, cái bƠn c a b n,
Các đ i t ng trong th gi i thực có chung hai nét đặc tr ng: tất cả đ u có các state (tr ng
thái) và behavior (cách hƠnh xử). Các đ i t ng trong thực t h t s c ph c t p: Cái đèn bƠn c a b n
có thể có 2 state (bật hoặc tắt) vƠ 2 behavior ( bật lên hoặc tắt đi), nh ng cái radio c a b n thì l i có
thể có các state ( bật, tắt, ơm l ng hi n t i, kênh hi n t i...) vƠ các behavior ( bật lên, tắt đi,
tăng/giảm ơm thanh, dò kênh,...). B n cũng s nhận ra rằng, vƠi đ i t ng cũng s ch a các đ i
t
ng khác
Nhận ra các state vƠ behavior c a các đ i t ng trong thực t lƠ cách tuy t v i để bắt đầu
suy nghĩ v các thuật ngữ trong lập trình h ng đ i t ng.
V i mỗi đ i t ng b n nhìn thấy, hưy tự h i mình hai cơu h i: Các state mƠ đ i t ng có thể
có là gì? và Các behavior mƠ đ i t ng có thể lƠm lƠ gì? Tất cả các quan sát trong th gi i thực đ u
đ c chuyển vƠo bên trong c a th gi i lập trình h ng đ i t ng.
Đối tượng trong phần mềm lƠ khái ni m t ng tự nh đ i t ng trong th gi i thực. Nó
cũng bao g m : các state vƠ behavior có liên quan. M t object ch a các state c a nó trong các field (
gọi lƠ bi n - variable trong m t s ngôn ngữ lập trình) vƠ ph i bƠy các behavior thông qua các
method ( function trong m t s ngôn ngữ lập trình khác). Các method tác đ ng lên các state bên
trong c a đ i t ng vƠ ho t đ ng nh m t kĩ thuật g c trong vi c trao đ i từ object t i object. Vi c
che giấu các state bên trong vƠ yêu cầu tất cả các t ng tác phải đ c lƠm thông qua các method
c a object đ c gọi lƠ đóng gói dữ li u (data encapsulation) - m t y u t c bản c a lập trình h ng
đ i t ng
1.2 Lớp (Class) và thể hiện (instance)
Trong th gi i thực, b n th ng xuyên gặp các đ i t ng khác nhau c a cùng m t kiểu. Ví
dụ: có hƠng nghìn chi c xe đ p khác nhau đang t n t i, mƠ tất cả chúng đ u có cùng cấu t o vƠ
t ng tự nhau hình dáng. Mỗi cái xe đ p đ u đ c xơy dựng từ m t tập h p các thi t k vƠ đ u
ch a các thƠnh phần gi ng nhau. Chúng ta gọi chung xe đ p lƠ m t lớp (class) các xe đ p, mỗi xe
đ p lƠ m t thể hiện (instance) cụ thể c a l p xe đ p đó.
Trong lập trình h ng đ i t ng cũng t
mẫu để t o ra các đ i t ng, trong m t l p ng
vƠ các hƠm để mô tả các phương thức (hàm) c
li u bao g m thu c tính vƠ các ph ng th c đ
ng tự nh vậy, l p có thể đ c hiểu lƠ m t khuôn
i ta th ng dùng các bi n để mô tả các thuộc tính
a đ i t ng. Hay nói cách khác, l p lƠ m t kiểu dữ
c định nghĩa tr c.
1.3 Sự trao đổi và thông điệp (message)
Các đ i t
ng trao đ i các thông đi p v i nhau thông qua các ph
Biên soạn: Nguyễn Thị Điệu
ng th c (hƠm).
13
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
1.4 Sự phân cấp (hierarchy)
1.4.1 Tính trừu tượng (abstraction), lớp trừu tượng (abstract class)
Tính trừu tượng (abstraction): Đơy lƠ khả năng c a ch ng trình b qua hay không chú ý
đ n m t s khía c nh c a thông tin mƠ nó đang trực ti p lƠm vi c lên, nghĩa lƠ nó có khả năng tập
trung vƠo những c t lõi cần thi t. Mỗi đ i t ng phục vụ nh lƠ m t “đ ng tử” có thể hoƠn tất các
công vi c m t cách n i b , báo cáo, thay đ i tr ng thái c a nó vƠ liên l c v i các đ i t ng khác mƠ
không cần cho bi t lƠm cách nƠo đ i t
gọi lƠ sự trừu t ng c a dữ li u.
Tính trừu t
ng ti n hƠnh đ
c các thao tác. Tính chất nƠy th
ng còn thể hi n qua vi c m t đ i t
ng đ
c
ng ban đầu có thể có m t s đặc điểm
chung cho nhi u đ i t ng khác nh lƠ sự m r ng c a nó nh ng bản thơn đ i t ng ban đầu này
có thể không có các bi n pháp thi hƠnh. Tính trừu t ng nƠy th ng đ c xác định trong khái ni m
gọi lƠ l p trừu t ng hay hay l p c s trừu t ng.
Nh vậy, Lớp trừu tượng: LƠ m t l p mƠ nó không thể thực thể hóa thƠnh m t đ i t
ng
thực dụng đ c. L p nƠy đ c thi t k nhằm t o ra m t l p có các đặc tính t ng quát nh ng bản
thơn l p đó ch a có ý nghĩa (hay không đ ý nghĩa) để có thể ti n hƠnh vi t mư cho vi c thực thể
hóa. (xem thí dụ)
Thí dụ: L p "hinh_thang" đ c định nghĩa không có dữ li u n i t i vƠ chỉ có các ph ng
th c (hƠm n i t i) "tinh_chu_vi", "tinh_dien_tich". Nh ng vì l p hinh_thang nƠy ch a xác định
đ c đầy đ các đặc tính c a nó (cụ thể các bi n n i t i lƠ tọa đ các đỉnh n u lƠ đa giác, lƠ đ ng
bán kính vƠ to đ tơm n u lƠ hình tròn, ...) nên nó chỉ có thể đ c vi t thƠnh m t l p trừu t ng.
Sau đó, ng i lập trình có thể t o ra các l p con chẳng h n nh lƠ l p "tam_giac", l p "hinh_tron",
l p "tu_giac",.... VƠ trong các l p con nƠy ng i vi t mư s cung cấp các dữ li u n i t i (nh lƠ bi n
n i t i r lƠm bán kính vƠ hằng s n i t i Pi cho l p "hinh_tron" vƠ sau đó vi t mư cụ thể cho các
ph ng th c "tinh_chu_vi" vƠ "tinh_dien_tich").
Ví dụ v l p c s trừu t
Biên soạn: Nguyễn Thị Điệu
ng vƠ l p con k thừa nó.
14
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
1.4.2 Sự kế thừa (inheritance)
Có hai khái ni m quan trọng lƠm nên th m nh c a c a lập trình h ng đ i t ng đó lƠ tính
k thừa (inheritance) vƠ tính t ng ng b i – tính đa hình (polymorphism). Tính k thừa cho phép
các l p đ c xơy dựng trên các l p sẵn có.
L p c sở vƠ l p d n xuất: M t l p đ c xơy dựng bằng cách k thừa từ l p khác đ
gọi lƠ l p dẫn xuất. L p dùng để xơy dựng l p dẫn xuất gọi lƠ l p c s .
c
L p nƠo cùng có thể đ c xơy dựng lƠm l p c s cho các l p khác k thừa nó. H n th
nữa, m t l p có thể lƠm l p c s cho nhi u l p dẫn xuất khác nhau. Đ n l t mình l p dẫn xuất l i
dùng lƠm c s cho các l p dẫn xuất khác. NgoƠi ra m t l p còn có thể dẫn xuất từ nhi u l p c s .
S đ 1: L p B dẫn xuất từ l p A, l p C dẫn xuất từ l p B
Biên soạn: Nguyễn Thị Điệu
15
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
A
B
C
S đ 2: L p A lƠ l p c s cho các l p B, C, D
A
B
C
D
S đ 3: L p B, C, D lƠ l p c s cho l p A
B
C
D
A
S đ 4: L
c đ dẫn xuất t ng quát
A
B
D
F
C
E
G
H
Tính k thừa: m t l p dẫn xuất ngoƠi các thƠnh phần c a riêng nó, nó còn đ c k thừa tất
cả các thƠnh phần c a l p c s có liên quan. Ví dụ trong s đ 1 thì l p C đ c k thừa các thƠnh
phần c a l p A vƠ B. Trong s đ 3 l p A đ c k thừa các thƠnh phần c a l p B, C, D.
1.4.3 Sự đa kế thừa (multiple inheritance)
Sự đa k thừa lƠ hi n t ng m t l p đ c xơy dựng bằng cách k thừa từ nhi u l p khác.
Trong s đ 3 l p A k thừa từ 2 l p B, C, D lƠ hi n t ng đa k thừa.
Biên soạn: Nguyễn Thị Điệu
16
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
1.5 Tính đa hình (polymorphism)
Đa hình thái trong lập trình h
hƠnh (runtime) mư nƠo s đ
cấp bậc khác nhau.
ng đ i t
ng đ cập đ n khả năng quy t định trong lúc thi
c ch y, khi có nhi u ph
ng th c trùng tên nhau nh ng
các l p có
Chú ý: khả năng đa hình thái trong lập trình hướng đối tượng còn được gọi với nhi u cái
tên khác nhau nh : t ng ng b i, k t ghép đ ng,..
Đa hình thái cho phép các vấn đ khác nhau, các đ i t ng khác nhau, các ph
khác nhau, các cách giải quy t khác nhau theo cùng m t l c đ chung.
Các b
ng th c
c để t o đa hình thái:
(1). Xơy dựng l p c s ( th ng lƠ l p c s trừu t ng, hoặc lƠ m t giao di n – trong java hay
C#), l p nƠy s đ c các l p con m r ng( đ i v i l p th ng, hoặc l p trừu t ng), hoặc triển
khai chi ti t ( đ i v i giao di n ).
(2). Xơy dựng các l p dẫn xuất từ l p c s vừa t o. Trong l p dẫn xuất nƠy ta s ghi đè các
ph ng th c c a l p c s ( đ i v i l p c s th
s trừu t ng hoặc giao di n).
ng), hoặc triển khai chi ti t nó ( đ i v i l p c
(3). Thực hi n vi c t o khuôn xu ng, thông qua l p c s , để thực hi n hƠnh vi đa hình thái
Khái ni m v t o khuôn lên, t o khuôn xu ng
-
Hi n t ng m t đ i t ng c a l p cha tham tr đ n m t đ i t ng c a l p con thì đ c gọi lƠ
t o khuôn xu ng, vi c t o khuôn xu ng luôn đ c java chấp thuận, do vậy khi t o khuôn xu ng
ta không cần phải ép kiểu t ng minh.
-
Hi n t ng m t đ i t ng c a l p con tham tr t i m t đ i t ng c a l p cha thì đ c gọi lƠ t o
khuôn lên, vi c t o khuôn lên lƠ an toƠn, vì m t đ i t ng c a l p con cũng có đầy đ các thƠnh
phần c a l p cha, tuy nhiên vi c t o khuôn lên s bị báo lỗi n u nh ta không ép kiểu m t cách
t ng minh.
1.6 Gói (package)
thể đ
LƠ m t cách t ch c các thƠnh phần, phần tử trong h th ng thƠnh các nhóm. Nhi u gói có
c k t h p v i nhau để tr thƠnh m t h th ng con (subsystem).
Nh v y:
- Phơn tích h ng đ i t ng: xơy dựng m t mô hình chính xác để mô tả h th ng cần xơy
dựng lƠ gì. ThƠnh phần c a mô hình nƠy lƠ các đ i t ng gắn v i h th ng thực.
- Thi t k h ng đ i t ng: LƠ giai đo n t ch c ch ng trình thƠnh các tập h p đ i t ng
c ng tác, mỗi đ i t ng trong đó lƠ thực thể c a m t l p. K t quả c a pha thi t k cho bi t h th ng
s đ c xơy dựng nh th nƠo qua các bản thi t k ki n trúc vƠ thi t k chi ti t.
- Lập trình vƠ tích h p: Thực hi n bản thi t k h
ngữ lập trình h ng đ i t ng (C++, Java, C#…).
Biên soạn: Nguyễn Thị Điệu
ng đ i t
ng bằng cách sử dụng các ngôn
17
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
2. Các b
c phơn tích thi t k h
Các b
ng đ i t
c phơn tích thi t k h
ng
ng đ i t
ng đ
c xơy dựng dựa trên biểu đ các ký hi u
UML. Đó lƠ ngôn ngữ mô hình hoá th ng nhất đ c xơy dựng để mô hình hoá quá trình phát triển
h th ng phần m m h ng đ i t ng. Các vấn đ c bản v UML s đ c gi i thi u chi ti t trong
mục 3. Mục nƠy chỉ nhằm gi i thi u m t cách khái quát các b
đ i t ng.
c trong phơn tích vƠ thi t k h
ng
Hình 7. Các bước phân tích thiết kế theo UML
Pha phân tích:
- Xơy dựng Biểu đ use case: Dựa trên tập yêu cầu ban đầu, ng i phơn tích ti n hành xác
định các tác nhơn, use case vƠ các quan h giữa các use case để mô tả l i các ch c năng c a h
th ng. M t thƠnh phần quan trọng trong biểu đ use case lƠ các kịch bản mô tả ho t đ ng c a h
th ng trong mỗi use case cụ thể.
- Xơy dựng Biểu đ l p: Xác định tên các l p, các thu c tính c a l p, m t s ph
m i quan h c bản trong s đ l p.
ng th c vƠ
- Xơy dựng biểu đ tr ng thái: Mô tả các tr ng thái vƠ chuyển ti p tr ng thái trong ho t đ ng
c a m t đ i t ng thu c m t l p nƠo đó.
Trong Pha thi t k :
-
Xơy dựng các biểu đ t ng tác (g m biểu đ c ng tác vƠ biểu đ tuần tự): mô tả chi ti t
ho t đ ng c a các use case dựa trên các scenario đư có vƠ các l p đư xác định trong pha
phân tích.
-
Xơy dựng biểu đ l p chi ti t: ti p tục hoƠn thi n biểu đ l p bao g m b sung các l p còn
thi u, dựa trên biểu đ tr ng thái để b sung các thu c tính, dựa trên biểu đ t ng tác để
xác định các ph ng th c vƠ m i quan h giữa các l p.
Biên soạn: Nguyễn Thị Điệu
18
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
-
Xơy dựng biểu đ ho t đ ng: mô tả ho t đ ng c a các ph ng th c ph c t p trong mỗi l p
hoặc các ho t đ ng h th ng có sự liên quan c a nhi u l p. Biểu đ ho t đ ng lƠ c s để
cƠi đặt các ph
-
ng th c trong các l p.
Xơy dựng biểu đ thƠnh phần: xác định các gói, các thƠnh phần vƠ t ch c phần m m theo
các thƠnh phần đó.
-
Xơy dựng biểu đ triển khai h th ng: xác định các thƠnh phần vƠ các thi t bị cần thi t để
triển khai h th ng, các giao th c vƠ dịch vụ hỗ tr .
2. Gi i thi u ngôn ngữ mô hình hóa h p nhất UML (Unified Modeling Language)
2.1 UML là gì ?
UML (Unified Modeling Language) lƠ ngôn ngữ trực quan đ c dùng trong quy trình phát
triển các h th ng phần m m. UML lƠ ngôn ngữ đặc tả hình thức (formal specication language),
đ c dùng để đặc tả, trực quan hóa, và tư liệu hóa phần m m h ng đ i t ng, nó không phải lƠ
m t ti n trình vƠ cũng không mô tả m t ti n trình hay m t ph ng pháp, do đó UML phải đ c sử
dụng k t h p v i m t ti n trình ph ng pháp luận. Ví dụ: Công tu Rational Software đư đ xuất m t
quy trình phát triển phần m m – ti n trình RUP (Rational Unified Process) đ c xem nh lƠ m t
ph ng pháp luận phát triển h th ng vƠ có ngôn ngữ mô hình hóa lƠ UML.
Chúng ta cần chú ý đ n thuật ngữ “ngôn ngữ”, ngôn ngữ
đơy không gi ng v i ngôn ngữ
tự nhiên c a con ng i hay ngôn ngữ lập trình. Tuy nhiên nó cũng có m t tập các quy luật xác định
cách sử dụng. Các ngôn ngữ lập trình có m t h th ng các ký hi u, các quy tắc cú pháp, các l nh
dùng để xơy dựng các ch ng trình; nói cách khác, ngôn ngữ lập trình bao g m m t tập các phần tử
vƠ m t tập các quy luật cho phép chúng ta t h p các phần tử l i v i nhau để t o các ch ng trình
h p l . Các ngôn ngữ mô hình hóa h p nhất cũng có m t tập các phần tử vƠ m t tập các quy luật
riêng. Các phần tử trong UML hầu h t lƠ các đ i t ng đ họa nh đ ng thẳng, hình chữ nhật,
hình oval, …. Chúng th ng đ c đặt nhưn để cung cấp thêm thông tin.
Mô hình hóa mang l i sự hiểu bi t v m t h th ng. M t mô hình không thể giúp chúng ta
hiểu rõ m t h th ng, th ng lƠ phải xơy dựng m t s mô hình xét từ những góc đ khác nhau. Các
mô hình nƠy có quan h v i nhau.
UML s cho ta bi t cách t o ra vƠ đọc hiểu đ c m t mô hình đ c cấu trúc t t, nh ng nó
không cho ta bi t những mô hình nƠo nên t o ra vƠ khi nƠo t o ra chúng. Đó lƠ nhi m vụ c a quy
trình phát triển phần m m.
a) UML là ngôn ngữ dùng để trực quan hóa
Đ i v i nhi u lập trình viên, không có khoảng cách nƠo giữa ý t ng để giải quy t m t vấn
đ vƠ vi c thể hi n đi u đó thông qua các đo n mư. Họ nghĩ ra vƠ họ vi t mư. Trên thực t , đi u này
gặp m t s vấn đ . Th nhất, vi c trao đ i v các ý t ng giữa những ng i lập trình s gặp khó
khăn, trừ khi tất cả đ u nói cùng m t ngôn ngữ. Thậm chí ngay cả khi không gặp tr ng i v ngôn
ngữ thì đ i v i từng công ty, từng nhóm cũng có những “ngôn ngữ” riêng c a họ. Đi u nƠy gơy tr
ng i cho m t ng i m i vƠo để có thể hiểu đ c những vi c đang đ c ti n hƠnh. H n nữa, trong
lĩnh vực phần m m, nhi u khi khó có thể hiểu đ c n u chỉ xem xét các đo n mư l nh. Ví dụ nh
Biên soạn: Nguyễn Thị Điệu
19
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
sự phơn cấp c a các l p, ta có thể phải duy t rất nhi u đo n l nh để hiểu đ c sự phơn cấp c a các
l p. VƠ n u nh ng i lập trình không mô tả các ý t ng mƠ anh ta đư xơy dựng thƠnh mư l nh thì
nhi u khi cách t t nhất lƠ xơy dựng l i trong tr
khi anh ta r i kh i nhóm.
ng h p m t ng
i khác đảm nhận ti p nhi m vụ
Xơy dựng mô hình sử dụng ngôn ngữ UML đư giải quy t đ c các khó khăn trên. Khi tr
thƠnh m t chuẩn trong vi c lập mô hình, mỗi kí hi u mang m t ý nghĩa rõ rƠng vƠ duy nhất, m t
nhƠ phát triển có thể đọc đ
c mô hình xơy dựng bằng UML do m t ng
i khác vi t.
Những cấu trúc mƠ vi c nắm bắt thông qua đọc mư l nh lƠ khó khăn nay đư đ c thể hi n
trực quan. M t mô hình rõ rƠng, sáng s a lƠm tăng khả năng giao ti p, trao đ i giữa các nhƠ phát
triển.
b) UML là ngôn ngữ dùng để chi tiết hóa
Có nghĩa lƠ xơy dựng các mô hình m t cách tỉ mỉ, rõ rƠng, đầy đ
các m c đ chi ti t khác
nhau. Đặc bi t lƠ UML thực hi n vi c chi ti t hoá tất cả các quy t định quan trọng trong phơn tích,
thi t k vƠ thực thi m t h th ng phần m m.
c) UML là ngôn ngữ dùng để sinh ra mã ở dạng nguyên mẫu
Các mô hình xơy dựng b i UML có thể ánh x t i m t ngôn ngữ lập trình cụ thể nh : Java,
C++... thậm chí cả các bảng trong m t c s dữ li u quan h hay CSDL h ng đ i t ng.
Vi c các yêu cầu có khả năng th ng xuyên thay đ i trong quá trình phát triển h th ng dẫn
đ n vi c các cấu trúc vƠ hƠnh vi c a h th ng đ c xơy dựng có thể khác mô hình mƠ ta đư xơy
dựng. Đi u nƠy có thể lƠm cho m t mô hình t t tr nên vô nghĩa vì nó không còn phản ánh đúng h
th ng nữa. Cho nên phải có m t c ch để đ ng b hóa giữa mô hình vƠ mư l nh.
UML cho phép cập nhật m t mô hình từ các mư thực thi (ánh x ng c). Đi u nƠy t o ra sự
nhất quán giữa mô hình c a h th ng vƠ các đo n mư thực thi mƠ ta xơy dựng cho h th ng đó.
d) UML là ngôn ngữ dùng để lập và cung cấp tài liệu
M t t ch c phần m m ngoƠi vi c t o ra các đo n mư l nh (thực thi) thì còn t o ra các tƠi
li u sau:
Ghi chép v các yêu cầu c a h th ng
Ki n trúc c a h th ng
Thi t k
Mư ngu n
K ho ch dự án
Tests
Các nguyên mẫu
2.2 Lịch sử phát triển và tương lai của UML
Biên soạn: Nguyễn Thị Điệu
20
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
t
Đầu những năm 1980, ngƠnh công ngh phần m m chỉ có duy nhất m t ngôn ngữ h ng đ i
ng lƠ Simula. Sang nửa sau c a thập kỷ 1980, các ngôn ngữ h ng đ i t ng nh Smalltalk vƠ
C++ xuất hi n. Cùng v i chúng, nảy sinh nhu cầu mô hình hoá các h th ng phần m m theo h ng
đ i t ng. VƠ m t vƠi trong s những ngôn ngữ mô hình hoá xuất hi n những năm đầu thập kỷ 90
đ c nhi u ng i dùng lƠ:
Grady Booch’s Booch Modeling Methodology
James Rambaugh’s Object Modeling Technique – OMT
Ivar Jacobson’s OOSE Methodology
Hewlett- Packard’s Fusion
Coad and Yordon’s OOA and OOD
Mỗi ph ng pháp luận vƠ ngôn ngữ trên đ u có h th ng ký hi u riêng, ph ng pháp xử lý
riêng vƠ công cụ hỗ tr riêng, khi n nảy ra cu c tranh luận ph ng pháp nƠo lƠ t t nhất. Đơy lƠ
cu c tranh luận khó có cơu trả l i, b i tất cả các ph ng pháp trên đ u có những điểm m nh vƠ
điểm y u riêng. Vì th , các nhƠ phát triển phần m m nhi u kinh nghi m th ng sử dụng ph i h p
các điểm m nh c a mỗi ph ng pháp cho ng dụng c a mình. Trong thực t , sự khác bi t giữa các
ph ng pháp đó hầu nh không đáng kể vƠ theo cùng ti n trình th i gian, tất cả những ph ng pháp
trên đư ti m cận l i vƠ b sung lẫn cho nhau. Chính hi n thực nƠy đư đ c những ng i tiên phong
trong lĩnh vực mô hình hoá h ng đ i t ng nhận ra vƠ họ quy t định ng i l i cùng nhau để tích
h p những điểm m nh c a mỗi ph ng pháp vƠ đ a ra m t mô hình th ng nhất cho lĩnh vực công
ngh phần m m.
Trong b i cảnh trên, ng i ta nhận thấy cần thi t phải cung cấp m t ph ng pháp ti m cận
đ c chuẩn hoá vƠ th ng nhất cho vi c mô hình hoá h ng đ i t ng. Yêu cầu cụ thể lƠ đ a ra m t
tập h p chuẩn hoá các ký hi u (Notation) vƠ các biểu đ (Diagram) để nắm bắt các quy t định v
mặt thi t k m t cách rõ rƠng, rƠnh m ch. Đư có ba công trình tiên phong nhắm t i mục tiêu đó,
chúng đ c thực hi n d i sự lưnh đ o c a James Rumbaugh, Grady Booch vƠ Ivar Jacobson.
Chính những c gắng nƠy dẫn đ n k t quả lƠ xơy dựng đ c m t Ngôn ngữ mô hình hoá thống
nhất (Unifield Modeling Language – UML).
Biên soạn: Nguyễn Thị Điệu
21
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 8 Sự ra đời của UML
``
Hình 9. Các phiên bản UML
Những tƠi li u đầu tiên v UML đư đ
công b vƠo tháng giêng năm 1997.
c trình lƠng vƠo năm 1996 vƠ phiên bản 1.0 đ
c
VƠ hi n nay, phiên bản m i nhất c a UML lƠ 2.1.2 phát hƠnh chính th c năm 2007. TƠi li u
đặc tả đ c công b vƠo tháng 11 năm 2007.
2.3 Tại sao dùng UML ?
2.3.1 Tại sao dùng biểu đồ trong phân tích thiết kế?
Khi thi t k các sản phẩm chúng ta đ u dùng hình ảnh hoặc biểu đ để tr giúp. Các nhà
thi t k th i trang, các kỹ s , các ki n trúc s vƠ các nhƠ phơn tích thi t k - tất cả đ u sử dụng biểu
Biên soạn: Nguyễn Thị Điệu
22
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
đ để hình dung công vi c c a họ. Các phơn tích vƠ thi t k viên dùng các biểu đ để hình dung h
th ng phần m m mƠ họ đang thi t k , mặc dù sự thật sản phẩm c a quy trình thi t k (t c lƠ các
ch ng trình máy tính) v n không trực quan. Vậy vi c sử dụng biểu đ mang l i cho quy trình thi t
k những thuận l i gì?
Có hai l i ích chính khi sử dụng biểu đ để t o m t thi t k :
Trừu t
ng hóa các thu c tính c a bản thi t k .
Chi ra các m i quan h giữa các thƠnh phần c a bản thi t k .
Khi ki n trúc s thi t k m t tòa nhƠ, anh ta s đ a ra m t s bản v v i nhi u mục đích
khác nhau. Bao g m m t biểu đ cho m t cái nhìn về toàn bộ tòa nhà với rất ít chi tiết nhằm chỉ ra
các đặc điểm đặc bi t c a bản thi t k , chẳng h n nh vị trí c a ng n c; các biểu đ v ra chi tiết
bản thiết kế, chẳng h n nh hình dáng c a các vật bằng gỗ hoặc mƠu vƠ vơn b mặt bên ngoƠi.
Không có biểu đ nƠo có thể biểu hi n h t mọi ph ng di n c a m t đ i t ng ph c t p, chẳng h n
nh m t tòa nhƠ, vƠ không m t ai có thể xử lý h t mọi thông tin c a m t bản thi t k tòa nhƠ trong
m t lần. Đi u nƠy cũng gi ng v i các h th ng phần m m: chúng rất ph c t p, vƠ ng i thi t k s
biểu di n các khía c nh khác nhau c a m t bản thi t k bằng các biểu đ khác nhau. Mỗi biểu đồ
chỉ biểu diễn một hoặc nhiều khía cạnh đặc trưng từ bản thiết kế tổng quát. Mặc dù th , mỗi biểu
đ không thể biểu di n từng chi ti t c a các khía c nh c a bản thi t k . M t biểu đ ng n c trong
m t tòa nhƠ chỉ có thể sử dụng các đ ng thẳng để biểu di n cho các ng n c thay vì tìm cách v
đ r ng c a ng n c theo tỷ l . T ng tự nh vậy, m t biểu đ biểu di n giao ti p giữa các thƠnh
phần khác nhau trong m t h th ng phần m m có thể dùng các đ ng thẳng để biểu di n cho giao
ti p mƠ không cần tìm cách biểu di n cách th c mƠ giao ti p xảy ra.
Sử dụng biểu đ để đ n giản hóa h th ng vƠ để biểu di n các đặc điểm chính nƠo đó đ c
gọi lƠ sự trừu tượng. Trừu t ng hóa lƠ m t c ch đ c dùng để biểu di n m t sự vật ph c t p tr
nên đ n giản h n bằng cách dùng m t s lo i mô hình. H n nữa, n u sự trừu t ng đ c biểu di n
m c vật lý, chẳng h n nh m t biểu đ trên giấy hoặc m t đ i t ng vật lý, thì chúng ta s dùng
thuật ngữ mô hình.
Trong phơn tích thi t k h th ng, các mô hình đ c t o ra để trừu t ng hóa các đặc điểm
quan trọng c a h th ng th gi i thực. M t l p UML mô tả m t khách hƠng chỉ g m những đặc
điểm c a khách hƠng liên quan đ n h th ng nghi p vụ. M t l p UML mô hình hƠnh vi c a chi c
máy bay trong h th ng đi u khiển không l u s mô hình chỉ các đặc điểm mƠ h th ng đi u khiển
th i gian thực quan tơm. Trong cả hai tr ng h p, ng i phơn tích hoặc thi t k quy t định đặc
điểm nƠo lƠ cần, đặc điểm nƠo lƠ không cần.
Ví dụ: Trong hầu h t các h th ng nghi p vụ, các đặc điểm c a khách hƠng quan tơm bao
g m tên, địa chỉ, số điện thoại, số fax và địa chỉ email. MƠu tóc, cơn nặng vƠ chi u cao không phải
lƠ các đặc điểm cần thi t.
2.3.2 Tại sao dùng đặc tả UML?
Trong dự án phát triển h th ng h ng đ i t ng, UML lƠ ngôn ngữ mô hình đ c u tiên
cho vi c phơn tích vƠ thi t k m t sản phẩm. Lý do m nh m nhất để sử dụng UML b i vì nó đư tr
thƠnh chuẩn thực t đ i v i mô hình h ng đ i t ng. N u cần thu hút m t nhóm các nhƠ phát triển
Biên soạn: Nguyễn Thị Điệu
23
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
hoặc cần chuyển thông tin trong mô hình cho những ng
vì nó d dƠng giao ti p giữa các bên tham gia.
i khác, thì UML lƠ sự lựa chọn hiển nhiên
Lý do th hai UML lƠ ngôn ngữ mô hình h p nhất. Nó lƠ sản phẩm k t h p từ ý t ng c a
ba nhƠ dẫn đầu trong vi c lập mô hình h ng đ i t ng vƠ k t h p chúng thƠnh m t mô hình duy
nhất. Từ các phiên bản đầu tiên, m t s t ch c liên quan đ n phát triển UML cũng c gắng h p tác
các đặc điểm t t nhất c a ngôn ngữ mô hình khác, vì th UML có thể đ c xem lƠ m t ngôn ngữ t t
nhất trong lĩnh vực nƠy. Tuy nhiên, có m t đi u nguy hiểm đay lƠ vi c c gắng h p nhất nhi u
quan điểm trên mô hình h ng đ i t ng lƠm cho UML phình ra v i nhi u ký hi u thừa. RTF c a
OMG đư c gắng tránh đi u nƠy bằng cách giữ cho phần c t lõi c a UML đ n giản, đ ng th i dùng
profile vƠ c các ch m r ng khác để m r ng nó.
Lý do th ba mƠ chúng ta nên sử dụng UML đó lƠ các profile đặc bi t đư t n t i để giúp
ng i sử dụng áp dụng cho m t vấn đ đặc tr ng, hi n m t s lo i profile khác cũng đang đ c xơy
dựng. N u m t vấn đ nƠo đó ch a có profile t ng ng, thì ta có thể m r ng ký hi u để áp dụng.
2.4 Một số đặc điểm chính của phương pháp phân tích thiết kế bằng UML
Tr
c đơy, quy trình tuần tự đ
c xem lƠ ph
ng pháp h p lý nhất để phát triển h th ng.
Tuy nhiên, trải qua vƠi thập niên, đư cho thấy các dự án sử dụng quy trình tuần tự th
công b i những lý do sau đơy:
ng ít thƠnh
Sự giả định ban đầu khi phát triển h th ng có sai sót.
Thất b i trong vi c k t h p các nhơn t con ng
Các h th ng ngƠy cƠng l n vƠ th
i.
ng hay thay đ i.
Chúng ta vẫn còn đang trong giai đo n thăm dò c a công ngh phần m m vƠ ch a có
nhi u kinh nghi m.
Nh đư trình bƠy trên, UML không phải lƠ m t ti n trình vƠ cũng không mô tả m t ti n
trình hay m t ph ng pháp, do đó UML phải đ c sử dụng k t h p v i m t ti n trình ph ng pháp
luận hay còn gọi lần ti n trình lặp. Tính chất lặp g m các đặc tr ng c bản sau:
Tính lặp (iterative): Dự án s đ c chia thƠnh các dự án nh trong mỗi b
án nh cũng s đ c phơn tích, thi t k , cƠi đặt vƠ kiểm tra.
c lặp. Mỗi dự
Gia tăng (incremental): H th ng ti n hóa thông qua m t tập các sự gia tăng, mỗi b
đ c chia trên lƠ m t incremental.
c
Tập chung kiến trúc (architecture centric): Ki n trúc c a h th ng phải đ c phát triển
nhằm đáp ng các yêu cầu c a use case chính, trong gi i h n c a chuẩn phần c ng mƠ
h th ng s ch y.
Biên soạn: Nguyễn Thị Điệu
24
Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Mô hình Use case
Đ
c xác định bởi
Mô hình phân tích
Thực hi n hóa bởi
Mô hình thi t k
Phơn b bởi
Mô hình triển khai
Hình 10. Các mô hình UML
CƠi đặt bởi
Mô hình cƠi đặt
Kiểm tra bởi
2.5 Các thành phần của UML
Mô hình thử
nghi m
Ngôn ngữ UML bao g m m t lo t các phần tử đ họa (graphic element) có thể đ c k t h p
v i nhau để t o các biểu đ . B i đơy lƠ m t ngôn ngữ, nên UML cũng có các nguyên tắc k t h p
các phần tử đó. M t s thƠnh phần ch y u c a ngôn ngữ UML:
Hướng nhìn (View): H ng nhìn chỉ ra những khía c nh khác nhau c a h th ng cần
phải đ c mô hình hóa. M t h ng nhìn không phải lƠ m t bản v , mƠ lƠ m t sự trừu
t ng hóa bao g m m t lo t các biểu đ khác nhau. Chỉ qua vi c định nghĩa m t lo t các
h ng nhìn khác nhau, mỗi h ng nhìn chỉ ra m t khía c nh riêng bi t c a h th ng,
ng i ta m i có thể t o dựng nên môt b c tranh toƠn di n v h th ng. Cũng chính các
h ng nhìn nƠy n i k t ngôn ngữ mô hình hóa v i quy trình đ c chọn cho giai đo n
phát triển.
Biểu đồ (diagram): Biểu đ lƠ các hình v miêu tả n i dung trong m t h ng nhìn. UML
có tất cả 9 lo i biểu đ khác nhau đ c sử dụng trong những sự k t h p khác nhau để
cung cấp tất cả các h ng nhìn c a m t h th ng.
Phần tử mô hình hóa (model element): Các khái ni m đ c sử dụng trong các biểu đ
đ c gọi lƠ các phần tử mô hình, thể hi n các khái ni m h ng đ i t ng quen thu c. Ví
dụ nh l p, đ i t ng, thông đi p cũng nh các quan h giữa các khái ni m nƠy, bao
g m cả liên k t, phụ thu c, khái quát hóa. M t phần tử mô hình th ng đ c sử dụng
trong nhi u biểu đ khác nhau, nh ng nó luôn luôn có chỉ m t ý nghĩa vƠ m t kí hi u.
Cơ chế chung: C ch chung cung cấp thêm những l i nhận xét b sung, các thông tin
cũng nh các quy tắc ngữ pháp chung v m t phần tử mô hình; chúng còn cung cấp
thêm các c ch để có thể m r ng ngôn ngữ UML cho phù h p v i m t ph ng pháp
xác định (m t quy trình, m t t ch c hoặc m t ng i dùng).
a) Hướng nhìn (View)
Biên soạn: Nguyễn Thị Điệu
25
