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
Trang 1M C L C
CH 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
Trang 2CH 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
Trang 3Phơ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 ng phần m m, không phân tích hoặc phân tích không t t s dẫn đ n phần m m chất l ng thấp:
Không quản lý đ 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
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ế
Lập trình
Kiểm thử
Thế giới
thực
Phần mềm
Trang 4ph 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 ng trình 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 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 Diagram-
mô 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
Trang 5Tá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,
ph 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
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
Trang 6cũ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 đ c phơn chia thƠnh những vấn đ nh h n,
đ 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 ng đ i t ng lƠ d ng phơn 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 ng đ i t ng lƠ đư giải quy t đ c các vấn đ nảy sinh v i
ph ng pháp h ng cấu trúc:
- 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 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:
…
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 đ c xem nh
m t ti n trình hoƠn chỉ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
Trang 7Nh 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 i dùng cần
Yêu cầu c a ng i dùng th ng thay đ i theo th i gian phát triển
Yêu cầu th ng đ 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ó
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 đ c thi t k sao cho d dƠng phát triển 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 ng gặp trong phát triển phần m m lƠ:
Hiểu không đúng những gì ng 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
Trang 8 Các thƠnh viên trong nhóm không bi t đ c ai đư thay đ i cƠi gì, khi nƠo, đơu, t i sao phải thay đ i
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 ng chúng ta khi nhìn m t chi c xe ô tô th ng s có m t b c tranh từ bên ngoƠi nh sau:
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:
Trang 9Hì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
Trang 10nghiê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 ng nhìn có thực (trong đ i
s ng)
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à t hiế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 các ch c năng c a h th ng cần xơy dựng, chúng ta bắt đầu phơn tích 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
Trang 11Sau 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 đư đ c nêu trong Đặc tả yêu cầu ?
M t s công vi c th ng đ 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
Đả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
Trang 12li u cần thi t cũng nh huấn luy n cho ng i dùng, để đảm bảo h th ng đ c sử dụng hữu hi u nhất
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
đ 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 ng pháp phơn tích thi t k h ng cấu trúc vƠ h ng ch c năng? u vƠ
nh c điểm?
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
Trang 13CH NG II T NG QUAN V PHÂN TệCH THI T K H NG Đ I T NG
1 Nhắc l i các khái ni m c bản v h ng đ i t ng
1.1 Đối tượng (Object)
Đ i t ng (Object) lƠ chìa khoá để hiểu v lập trình h ng đ i t ng Thử nhìn xung quanh
b n s phát hi n nhi u ví dụ trong thực t v đ i t ng: Cái máy tính, cái đèn bƠn, cái bƠn c a b n, cái TV, cái xe đ p
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 ng tự nh vậy, l p có thể đ c hiểu lƠ m t khuôn
mẫu để t o ra các đ i t ng, trong m t l p ng i ta th ng dùng các bi n để mô tả các thuộc tính
vƠ các hƠm để mô tả các phương thức (hàm) c a đ i t ng Hay nói cách khác, l p lƠ m t kiểu dữ
li u bao g m thu c tính vƠ các ph ng th c đ c định nghĩa tr c
1.3 Sự trao đổi và thông điệp (message)
Trang 141.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 ng ti n hƠnh đ c các thao tác Tính chất nƠy th ng đ c gọi lƠ sự trừu t ng c a dữ li u
Tính trừu t ng còn thể hi n qua vi c m t đ i t 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 ng vƠ l p con k thừa nó
Trang 151.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 đ 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
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
Trang 16S đ 2: L p A lƠ l p c s cho các l p B, C, D
S đ 3: L p B, C, D lƠ l p c s cho l p A
S đ 4: L c đ dẫn xuất t ng quát
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
B
A
DC
B
A
DC
Trang 171.5 Tính đa hình (polymorphism)
Đa hình thái trong lập trình h ng đ i t ng đ cập đ n khả năng quy t định trong lúc thi hƠnh (runtime) mư nƠo s đ c ch y, khi có nhi u ph ng th c trùng tên nhau nh ng các l p có cấp bậc khác nhau
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
(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 ng), hoặc triển khai chi ti t nó ( đ i v i l p c
s trừu t ng hoặc giao di n)
(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
- 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 đ i t ng bằng cách sử dụng các ngôn ngữ lập trình h ng đ i t ng (C++, Java, C#…)
Trang 18th 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 ng th c vƠ
m i quan h c bản trong s đ l p
- 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
Trang 19- 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
Trang 20sự 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 ng h p m t ng i khác đảm nhận ti p nhi m vụ khi anh ta r i kh i nhóm
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
Trang 21Đầ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
t 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
n hất (Unifield Modeling Language – UML)
Trang 22Hình 8 Sự ra đời của UML
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
Trang 23đ để 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
Trang 24hoặc cần chuyển thông tin trong mô hình cho những ng i khác, thì UML lƠ sự lựa chọn hiển nhiên
vì nó d dƠng giao ti p giữa các bên tham gia
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 ng ít thƠnh công b i những lý do sau đơy:
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 i
Các h th ng ngƠy cƠng l n vƠ th 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 c lặp Mỗi dự
án nh cũng s đ c phơn tích, thi t k , cƠi đặt vƠ kiểm tra
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
đ c chia trên lƠ m t incremental
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
Trang 25Hình 10 Các mô hình UML
2.5 Các thành phần của UML
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)
Mô hình Use case
Trang 26Mô hình hóa m t h th ng ph c t p lƠ m t vi c lƠm khó khăn Lý t ng nhất lƠ toƠn b h
th ng đ c miêu tả chỉ trong m t bản v , m t bản v định nghĩa m t cách rõ rƠng vƠ m ch l c toƠn
b h th ng, m t bản v ngoƠi ra l i còn d giao ti p vƠ d hiểu Mặc dù vậy, th ng thì đơy lƠ chuy n bất khả thi M t bản v không thể nắm bắt tất cả các thông tin cần thi t để miêu tả m t h
th ng M t h th ng cần phải đ c miêu tả v i m t lo t các khía c nh khác nhau: V mặt ch c năng (cấu trúc tĩnh c a nó cũng nh các t ng tác đ ng), v mặt phi ch c năng (yêu cầu v th i gian, v đ đáng tin cậy, v quá trình thực thi, v.v vƠ v.v.) cũng nh v khía c nh t ch c (t ch c lƠm vi c, ánh x nó vƠo các code module, ) Vì vậy m t h th ng th ng đ c miêu tả trong m t
lo t các h ng nhìn khác nhau, mỗi h ng nhìn s thể hi n m t b c ảnh ánh x c a toƠn b h
th ng vƠ chỉ ra m t khía c nh riêng c a h th ng
Mỗi m t h ng nhìn đ c miêu tả trong m t lo t các biểu đ , ch a đựng các thông tin nêu bật khía c nh đặc bi t đó c a h th ng Trong thực t khi phơn tích vƠ thi t k rất d xảy ra sự trùng lặp thông tin, cho nên m t biểu đ trên thực t có thể lƠ thƠnh phần c a nhi u h ng nhìn khác nhau Khi nhìn h th ng từ nhi u h ng nhìn khác nhau, t i m t th i điểm có thể ng i ta chỉ tập trung vƠo m t khía c nh c a h th ng M t biểu đ trong m t h ng nhìn cụ thể nƠo đó cần phải đ
đ đ n giản để t o đi u ki n giao ti p d dƠng, để dính li n v i các biểu đ khác cũng nh các
h ng nhìn khác, lƠm sao cho b c tranh toƠn cảnh c a h th ng đ c miêu tả bằng sự k t h p tất cả các thông tin từ tất cả các h ng nhìn M t biểu đ ch a các kí hi u hình học mô tả các phần tử mô hình c a h th ng UML có tất cả các h ng nhìn sau:
Hướng nhìn Use case (use case view) : đơy lƠ h ng nhìn chỉ ra khía c nh ch c năng
c a m t h th ng, nhìn từ h ng tác nhơn bên ngoƠi
- H ng nhìn Use case miêu tả ch c năng c a h th ng s phải cung cấp do đ c tác nhơn
từ bên ngoƠi mong đ i Tác nhơn lƠ thực thể t ng tác v i h th ng; đó có thể lƠ m t
ng i sử dụng hoặc lƠ m t h th ng khác H ng nhìn Use case lƠ h ng nhìn dƠnh cho khách hàng, nhƠ thi t k , nhƠ phát triển vƠ ng i thử nghi m; nó đ c miêu tả qua các biểu đồ Use case (use case diagram) vƠ thỉnh thoảng cũng bao g m cả các biểu đồ hoạt động (activity diagram) Cách sử dụng h th ng nhìn chung s đ c miêu tả qua m t
lo t các Use case trong h ng nhìn Use case, n i mỗi m t Use case lƠ m t l i miêu tả mang tính đặc thù cho m t tính năng c a h th ng (có nghĩa lƠ m t ch c năng đ c mong đ i)
- H ng nhìn Use case mang tính trung tơm, b i nó đặt ra n i dung thúc đẩy sự phát triển các h ng nhìn khác Mục tiêu chung c a h th ng lƠ cung cấp các ch c năng miêu tả trong h ng nhìn nƠy – cùng v i m t vƠi các thu c tính mang tính phi ch c năng khác –
vì th h ng nhìn nƠy có ảnh h ng đ n tất cả các h ng nhìn khác H ng nhìn nƠy
Hình 11 Các View trong UML
Trang 27cũng đ c sử dụng để thẩm tra (verify) h th ng qua vi c thử nghi m xem h ng nhìn Use case có đúng v i mong đ i c a khách hƠng (H i: "Đơy có phải lƠ th b n mu n") cũng nh có đúng v i h th ng vừa đ c hoƠn thƠnh (H i: "H th ng có ho t đ ng nh
đư đặc tả?”)
Hướng nhìn logic (logical view): chỉ ra ch c năng s đ c thi t k bên trong h th ng
nh th nƠo, qua các khái ni m v cấu trúc tĩnh cũng nh ng xử đ ng c a h th ng
- H ng nhìn logic miêu tả ph ng th c mƠ các ch c năng c a h th ng s đ c cung cấp Ch y u nó đ c sử dụng cho các nhƠ thi t k vƠ nhƠ phát triển Ng c l i v i
h ng nhìn Use case, h ng nhìn logic nhìn vƠo phía bên trong c a h th ng Nó miêu
tả kể cả cấu trúc tĩnh (l p, đ i t ng, vƠ quan h ) cũng nh sự t ng tác đ ng s xảy ra khi các đ i t ng gửi thông đi p cho nhau để cung cấp ch c năng đư định sẵn
- Cấu trúc tĩnh đ c miêu tả bằng các biểu đồ lớp (class diagram) và biểu đồ đối tượng
(object diagram) Quá trình mô hình hóa đ ng đ c miêu tả trong các biểu đ tr ng thái (state diagram), biểu đ trình tự (sequence diagram), biểu đ t ng tác (collaboration diagram) vƠ biểu đ ho t đ ng (activity diagram)
Hướng nhìn thành phần (component view): chỉ ra khía c nh t ch c c a các thƠnh phần
code
- LƠ m t l i miêu tả c a vi c thực thi các modul cũng nh sự phụ thu c giữa chúng v i nhau Nó th ng đ c sử dụng cho nhƠ phát triển vƠ th ng bao g m nhi u biểu đ thƠnh phần ThƠnh phần đơy lƠ các modul l nh thu c nhi u lo i khác nhau, s đ c chỉ
ra trong biểu đ cùng v i cấu trúc cũng nh sự phụ thu c c a chúng Các thông tin b sung v các thƠnh phần, ví dụ nh vị trí c a tƠi nguyên (trách nhi m đ i v i m t thƠnh phần), hoặc các thông tin quản trị khác, ví dụ nh m t bản báo cáo v ti n trình c a công
vi c cũng có thể đ c b sung vƠo đơy
Hướng nhìn song song (concurrency view): chỉ ra sự t n t i song song/trùng h p trong
h th ng, h ng đ n vấn đ giao ti p vƠ đ ng b hóa trong h th ng
- H ng nhìn song song nhắm t i sự chia h th ng thƠnh các qui trình (process) vƠ các b
xử lý (processor) Khía c nh nƠy, v n lƠ m t thu c tính phi ch c năng c a h th ng, cho phép chúng ta sử dụng m t cách hữu hi u các ngu n tƠi nguyên, thực thi song song, cũng nh xử lý các sự ki n không đ ng b từ môi tr ng Bên c nh vi c chia h th ng thƠnh các tiểu trình có thể đ c thực thi song song, h ng nhìn nƠy cũng phải quan tơm
đ n vấn đ giao ti p vƠ đ ng b hóa các tiểu trình đó
- H ng nhìn song song giƠnh cho nhƠ phát triển vƠ ng i tích h p h th ng, nó bao g m các biểu đồ động (tr ng thái, trình tự, t ng tác vƠ ho t đ ng) cùng các biểu đ thực thi
(biểu đ thƠnh phần vƠ biểu đ triển khai)
Hướng nhìn triển khai (deployment view): chỉ ra khía c nh triển khai h th ng vƠo các
ki n trúc vật lý (các máy tính hay trang thi t bị đ c coi lƠ tr m công tác)
Trang 28- H ng nhìn triển khai chỉ cho chúng ta s đ triển khai v mặt vật lý c a h th ng, ví dụ
nh các máy tính cũng nh các máy móc vƠ sự liên k t giữa chúng v i nhau H ng nhìn triển khai giƠnh cho các nhƠ phát triển, ng i tích h p cũng nh ng i thử nghi m
h th ng vƠ đ c thể hi n bằng các biểu đồ triển khai H ng nhìn nƠy cũng bao g m
sự ánh x các thƠnh phần c a h th ng vƠo cấu trúc vật lý; ví dụ nh ch ng trình nào hay đ i t ng nƠo s đ c thực thi trên máy tính nƠo
Khi b n chọn công cụ để v biểu đ , hưy chọn công cụ nƠo t o đi u ki n d dƠng chuyển từ
h ng nhìn nƠy sang h ng nhìn khác NgoƠi ra, cho mục đích quan sát m t ch c năng s đ c thi t k nh th nƠo, công cụ nƠy cũng phải t o đi u ki n d dƠng cho b n chuyển sang h ng nhìn Use case (để xem ch c năng nƠy đ c miêu tả nh th nƠo từ phía tác nhơn), hoặc chuyển sang
h ng nhìn triển khai (để xem ch c năng nƠy s đ c phơn b ra sao trong cấu trúc vật lý - Nói m t cách khác lƠ nó có thể nằm trong máy tính nƠo)
NgoƠi các h ng nhìn kể trên, ngƠnh công nghi p phần m m còn sử dụng cả các h ng nhìn khác, ví dụ h ng nhìn tĩnh-đ ng, h ng nhìn logic-vật lý, quy trình nghi p vụ (workflow) vƠ các
h ng nhìn khác UML không yêu cầu chúng ta phải sử dụng các h ng nhìn nƠy, nh ng đơy cũng chính lƠ những h ng nhìn mƠ các nhƠ thi t k c a UML đư nghĩ t i, nên có khả năng nhi u công
cụ s dựa trên các h ng nhìn đó
b) Biểu đồ (Diagram)
Biểu đ lƠ các hình v bao g m các ký hi u phần tử mô hình hóa đ c sắp x p để minh họa
m t thƠnh phần cụ thể hay m t khía c nh cụ thể c a h th ng M t mô hình h th ng th ng có nhi u lo i biểu đ , mỗi lo i có nhi u biểu đ khác nhau M t biểu đ lƠ m t thƠnh phần c a m t
h ng nhìn cụ thể; vƠ khi đ c v ra, nó th ng th ng cũng đ c x p vƠo m t h ng nhìn Mặt khác, m t s lo i biểu đ có thể lƠ thƠnh phần c a nhi u h ng nhìn khác nhau, tùy thu c vƠo n i dung c a biểu đ UML cung cấp những biểu đ trực quan để biểu di n các khía c nh khác nhau
c a h th ng, bao g m:
1 Biểu đồ Use Case mô tả sự t ng tác giữa các tác nhơn ngoƠi vƠ h th ng thông qua các Use
Case Các Use Case lƠ những nhi m vụ chính, các dịch vụ, những tr ng h p sử dụng cụ thể
mƠ h th ng cung cấp cho ng i sử dụng vƠ ng c l i
2 Biểu đồ lớp mô tả cấu trúc tĩnh, mô tả mô hình khái ni m bao g m các l p đ i t ng vƠ các
m i quan h c a chúng trong h th ng h ng đ i t ng
3 Biểu đồ trình tự thể hi n sự t ng tác c a các đ i t ng v i nhau, ch y u lƠ trình tự gửi vƠ nhận thông đi p để thực thi các yêu cầu, các công vi c theo thời gian
4 Biểu đồ cộng tác t ng tự nh biểu đ trình tự nh ng nhấn m nh vƠo sự t ng tác c a các
đ i t ng trên c s c ng tác v i nhau bằng cách trao đ i các thông đi p để thực hi n các
yêu cầu theo ngữ cảnh công việc
5 Biểu đồ trạng thái thể hi n chu kỳ ho t đ ng c a các đ i t ng, c a các h th ng con vƠ c a
cả h th ng Nó lƠ m t lo i ôtômát hữu h n tr ng thái, mô tả các tr ng thái, các hƠnh đ ng
mƠ đ i t ng có thể có vƠ các sự ki n gắn v i các tr ng thái theo th i gian
Trang 296 Biểu đồ hành động chỉ ra dòng ho t đ ng c a h th ng, bao g m các tr ng thái ho t đ ng,
trong đó từ m t tr ng thái ho t đ ng s chuyển sang tr ng thái khác sau khi m t ho t đ ng
t ng ng đ c thực hi n Nó chỉ ra trình tự các b c, ti n trình thực hi n cũng nh các điểm quy t định vƠ sự r nhánh theo lu ng sự ki n
7 Biểu đồ thành phần chỉ ra cấu trúc vật lý c a các thƠnh phần trong h th ng, bao g m: các
thƠnh phần mư ngu n, mư nhị phơn, th vi n vƠ các thƠnh phần thực thi
8 Biểu đồ triển khai chỉ ra cách b trí vật lý các thƠnh phần theo ki n trúc đ c thi t k c a h
d i vƠ có thể đ c coi lƠ cả tên c a thực thể lẫn tên c a lo i đó M t hình chữ nhật thể hi n l p
v i tên đ c in đậm s thể hi n m t l p vƠ tên đ c g ch d i s thể hi n m t đ i t ng, đơy lƠ
m t ví dụ tiêu biểu c a adornment Cũng nguyên tắc đó đ c áp dụng cho các nút m ng, khi ký
hi u nút đ c in đậm lƠ thể hi n m t lo i nút, ví dụ nh máy in (Printer), khi ký hi u đ c g ch
d i lƠ thể hi n m t thực thể c a l p nút m ng nƠy ví dụ John’s HP 5MP-printer Các kiểu trang trí khác là các l i đặc tả v s l ng trong quan h (multiplicity), n i s l ng lƠ m t s hay m t khoảng s chỉ ra bao nhiêu thực thể c a các lo i thực thể đ c n i v i nhau s có thể tham gia trong
kỳ lo i thông tin nƠo D ng thông tin c a bản thơn nó lƠ chuỗi ký tự (string), không đ c UML di n giải L i ghi chú th ng đi kèm theo m t s các phần tử mô hình trong biểu đ , đ c n i bằng m t
đ ng chấm chấm, chỉ ra phần tử mô hình nƠo đ c chi ti t hóa hoặc đ c giải thích (hình 2.4)
M t l i ghi chú th ng ch a l i nhận xét hoặc các cơu h i c a nhƠ t o mô hình, ví dụ l i nhắc nh cần phải xử lý vấn đ nƠo đó trong th i gian sau nƠy L i ghi chú cũng có thể ch a các
Trang 30Hình 13 Một ví dụ về ghi chú
Đặc tả (Specification)
Các phần tử mô hình có thu c tính (Property) ch a các giá trị dữ li u v phần tử nƠy M t thu c tính đ c định nghĩa v i m t tên vƠ m t giá trị đính kèm (tagged value), th ng chúng trong m t d ng thông tin đ c xác định tr c, ví dụ nh s nguyên hay chuỗi kí tự Có m t lo t thu c tính đư đ c định nghĩa tr c, ví dụ nh tƠi li u (docement), trách nhi m (Responsibility), sự
tr ng t n (Persistence) vƠ tính song song (Conccurency)
Thu c tính đ c sử dụng để thêm các đặc tả b sung v m t phần tử, những thông tin bình
th ng ra không đ c thể hi n trong biểu đ Ví dụ tiêu biểu lƠ m t l p s đ c miêu tả bằng m t tƠi li u văn bản nhất định, cung cấp nhi u thông tin h n v trách nhi m cũng nh khả năng c a l p nƠy Lo i đặc tả nƠy bình th ng ra không đ c chỉ ra trong các biểu đ , nh ng th ng thì trong đa phần các công cụ mô hình hóa chúng s có thể đ c truy cập qua hƠnh đ ng nhấp nút vƠo m t phần
tử nƠo đó, hi u quả lƠ m t cửa s ch a đặc tả v i tất cả các thu c tính s đ c chỉ ra (Hình 2.5)
Hình 14 Một cửa sổ đặc tả thể hiện các đặc tính của class
2.6 Mở rộng UML
Trang 31UML có thể đ c m r ng hoặc có thể đ c sửa đ i để phù h p v i m t ph ng pháp đặc
bi t, m t t ch c cụ thể hay m t ng i dùng cụ thể Chúng ta s bƠn luận s qua đ n ba c ch m
r ng UML: khuôn mẫu (stereotype), giá trị đính kèm (tagged value) vƠ h n ch (constraint)
2.6.1 Khuôn mẫu (Stereotype)
C ch m r ng khuôn mẫu định nghĩa m t lo i phần tử mô hình m i dựa trên m t phần tử
mô hình đư t n t i Khuôn mẫu có thể đ c coi lƠ "t ng tự" nh m t phần tử đư có sẵn, c ng thêm phần quy định ngữ nghĩa (semantic) riêng bi t không có trong phần tử g c kia Khuôn mẫu c a m t phần tử có thể đ c sử dụng trong cùng tình hu ng nh phần tử căn bản Khuôn mẫu dựa trên tất cả các lo i phần tử mô hình sẵn có - l p, nút m ng, thƠnh phần, cũng nh các m i quan h nh liên
k t, khái quát hóa, sự phụ thu c Ngôn ngữ UML có ch a m t s l ng l n các khuôn mẫu đ c định nghĩa sẵn vƠ chúng đ c sử dụng để sửa đ i các phần tử mô hình sẵn có, thay cho vi c phải định nghĩa hoƠn toƠn m i C ch nƠy giúp gìn giữ tính đ n giản c a n n tảng ngôn ngữ UML
Khuôn mẫu đ c miêu tả qua vi c đ a tên c a chúng vƠo trong m t cặp ký tự ngoặc nhọn
<<>>, theo ví dụ hình 2.6 Ký tự ngoặc nhọn nƠy đ c gọi lƠ guillements Khuôn mẫu cũng có thể
có ký hi u hình học riêng M t phần tử c a m t lo i khuôn mẫu cụ thể có thể đ c k t h p v i tên khuôn mẫu đi kèm ký hi u hình học mô tả phần tử căn bản, hay lƠ sự k t h p c a hai y u t nƠy Bất kỳ khi nƠo m t phần tử mô hình đ c n i k t v i m t ký hi u khuôn mẫu, ta s đọc “đơy lƠ lo i phần tử thu c lo i khuôn mẫu …” Ví dụ, m t l p v i <<Window>> s đ c gọi lƠ “M t l p trong
d ng khuôn mẫu cửa s ”, ý nghĩa c a nó lƠ m t d ng l p cửa s Những thu c tính cụ thể mƠ m t
l p cửa s cần phải có s đ c định nghĩa khi khuôn mẫu nƠy đ c định nghĩa
Nh đư nói, khuôn mẫu lƠ m t c ch m r ng xuất sắc, lƠ m t c ch ngăn cho ngôn ngữ UML không tr nên quá ph c t p, mặc dù vẫn cho phép thực hi n sự m r ng vƠ sửa đ i cần thi t
Đa phần các phần tử mô hình m i mƠ b n cần đ n đ u có m t khuôn mẫu n n tảng trong ngôn ngữ UML M t khuôn mẫu sau đó có thể đ c sử dụng để c ng thêm các ngữ nghĩa cần thi t, nhằm mục đích định nghĩa nên các phần tử mô hình còn thi u
Hình 15 Customer là một khuôn mẫu của <<actor>>
2.6.2 Giá trị đính kèm (Tagged value)
Nh đư nói, các phần tử mô hình có thể có các thu c tính ch a m t cặp tên-giá trị v bản thân chúng (hình 2.7) Các thu c tính nƠy cũng còn đ c gọi lƠ các giá trị đính kèm UML ch a
m t lo t các thu c tính đ c định nghĩa tr c, nh ng kể cả ng i sử dụng cũng có thể định nghĩa ra các thu c tính m i để ch a các thông tin b sung v các phần tử mô hình Mọi hình d ng thông tin
đ u có thể đ c đính kèm vƠo phần tử: các thông tin chuyên bi t v ph ng pháp, các thông tin c a
Trang 32các công cụ t o code hay bất kỳ m t lo i thông tin nƠo mƠ ng i sử dụng mu n đính kèm vƠo phần
tử mô hình
Hình 2.7 Một ví dụ về tagged value 2.6.3 Hạn chế (Constraint)
M t sự h n ch lƠ m t sự gi i h n v sự sử dụng hoặc ý nghĩa c a m t phần tử Sự h n ch hoặc s đ c khai báo trong công cụ vƠ đ c sử dụng nhi u lần trong rất nhi u biểu đ khác nhau, hay đ c định nghĩa vƠ sử dụng trong chỉ m t biểu đ , theo nh nhu cầu
Hình 2.8 chỉ ra m i quan h n i k t giữa nhóm các công dơn l n tu i vƠ l p con ng i, chỉ
ra rằng nhóm công dơn có thể có nhi u liên quan Mặc dù vậy, để miêu tả rằng chỉ những ng i nƠo
l n h n 60 tu i m i có thể tham gia vƠo nhóm nƠy, ng i ta định nghĩa m t sự h n ch , thu hẹp tiêu chuẩn tham gia đ i v i chỉ những ng i nƠo mƠ thu c tính tu i tác có giá trị l n h n 60 Định nghĩa nƠy s h n ch s l ng những ng i đ c sử dụng trong m i quan h N u không có nó, ng i ta rất d hiểu lầm khi di n tả biểu đ Trong tr ng h p t i t , nó có thể dẫn đ n sự thực thi sai trái
c a h th ng
Trong tr ng h p nƠy, h n ch đ c định nghĩa vƠ ng dụng trực ti p trong chính bi u đ
mƠ nó đ c cần t i Nh ng nhìn chung thì h n ch cũng có thể đ c định nghĩa v i tên cùng l i đặc
tả riêng, ví dụ: “công dơn giƠ” vƠ “ng i l n h n 60 tu i” vƠ h n ch nƠy s đ c sử dụng trong nhi u biểu đ khác nhau UML có ch a m t lo t các h n ch đ c định nghĩa sẵn
Hình 2.8 Một ràng buộc hạn chế đối với Person góp phần vào quan hệ kết hợp
3 Công c hỗ tr Visual Paradigm
3.1 Cài đặt phần mềm
Môi tr ng cƠi đặt:
Cặt đặt Visual paradigm for UML:
a) Download b cƠi Visual Paradigm Suite
Để thực hi n cƠi đặt tr c h t b n cần download b cƠi t i địa chỉ paradigm.com/download/
Trang 33Click chọn browse để chọn th mục cƠi đặt (th mục mặc định lƠ C:\Program Files\VP Suite 4.0)
Trang 34- Check chọn Visual Paradigm for UML (VP-UML) r i click next:
Trang 35- Check chọn Signle License key, r i click next:
Trang 36Browse đ n file vpsuite.zvpl
Trang 37- Click finish để hoƠn thƠnh cƠi đặt:
Trang 393.2 Màn hình khởi động Visual Paradigm
Sau khi hoƠn tất cƠi đặt, click vƠo biểu t ng Visual Paradigm for UML 7.0 Enterprise Edition hoặc vƠo Start Visual Paradigm Visual Paradigm for UML 7.0 Enterprise Edition để kh i đ ng phần m m:
Khi kh i đ ng phần m m Visual Paradigm, h p tho i đầu tiên xuất hi n yêu cầu ng i dùng chọn th mục Workspace Launcher, th mục mặc định lƠ th mục nằm trong Documents and Settings và có tên trùng v i tên user đăng nhập máy (Hình 2.9)
Hình 2.9 Hộp thoại chọn thư mục Workspace
Mặc định khi kh i đ ng Visual Paradigm mƠn hình boa g m năm phần chính:
Phần đầu lƠ thanh Menu vƠ các thanh công cụ (Tool bar)
- Thanh Menu bao g m các menu: File, Edit, View, Tools, Window, Help
Hình 2.10 Thanh menu
- Thanh công cụ bao g m các thanh: Standard, Diagram, ORM, Teamwork, Navigate, Report, Import and Export, Tools
o Thanh Standard lƠ thanh công cụ chuẩn, dùng cho các thao tác c bản nh T o
m t project m i (New project), M m t project đư t n t i (Open project), L u project, Copy, Paste, Undo, Redo, các công cụ room mƠn hình, …
Hình 2.11 Thanh standard
o Thanh Diagram lƠ thanh dùng để t o các biểu đ trong UML, nh : Biểu đồ Use case (Use case diagram), Biểu đồ lớp (Class diagram), Biểu đồ tuần tự (Sequence
Trang 40(State diagram), Biểu đồ hoạt động (Activity diagram), Biểu đồ thành phần
(Component diagram), Biểu đồ triển khai (Deployment diagram), …
UML đ c chia thƠnh nhi u h ng nhìn, mỗi h ng nhìn quan tơm đ n h th ng phần
m m từ m t khía c nh cụ thể
N u xét theo tính chất mô hình thì UML có hai d ng mô hình chính lƠ mô hình tĩnh vƠ
mô hình đ ng Mỗi mô hình l i bao g m m t nhóm các biểu đ khác nhau
Mỗi biểu đ UML có m t tập ký hi u riêng để biểu di n các thƠnh phần c a biểu đ đó Quá trình biểu di n các biểu đ cũng phải tuơn theo các quy tắc đ c định nghĩa trong UML