1. Trang chủ
  2. » Công Nghệ Thông Tin

Giáo trình Phân tích thiết kế hệ thống hướng đối tượng

169 500 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 169
Dung lượng 5,21 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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 1

M 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 2

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

Trang 3

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 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 4

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 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 5

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,

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 6

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 đ 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 7

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 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 9

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

Trang 10

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 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 11

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 đư đ 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 12

li 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 13

CH 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 14

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 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 15

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 đ 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 16

S đ 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 17

1.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 18

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 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 20

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 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 22

Hì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 24

hoặ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 25

Hì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 26

Mô 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 27

cũ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 29

6 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 30

Hì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 31

UML 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 32

cá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 33

Click 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 36

Browse đ n file vpsuite.zvpl

Trang 37

- Click finish để hoƠn thƠnh cƠi đặt:

Trang 39

3.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

Ngày đăng: 04/08/2016, 13:23

HÌNH ẢNH LIÊN QUAN

Hình 1.1  Mô phỏng quá trình phát triển HTTT - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 1.1 Mô phỏng quá trình phát triển HTTT (Trang 3)
Hình 7.  Các bước phân tích thiết kế theo UML - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 7. Các bước phân tích thiết kế theo UML (Trang 18)
Hình  8 Sự ra đời của UML - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
nh 8 Sự ra đời của UML (Trang 22)
Hình 9.  Các phiên bản UML - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 9. Các phiên bản UML (Trang 22)
Hình 10. Các mô hình UML - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 10. Các mô hình UML (Trang 25)
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 - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
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 30)
Hình 2.9 Hộp thoại chọn thư mục Workspace - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 2.9 Hộp thoại chọn thư mục Workspace (Trang 39)
Hình 2.12 Thanh diagram - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 2.12 Thanh diagram (Trang 40)
Hình 3.1 Mối quan hệ giữa các công việc trong pha phân tích yêu cầu hệ thống - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 3.1 Mối quan hệ giữa các công việc trong pha phân tích yêu cầu hệ thống (Trang 45)
Hình 3.2 Biểu đồ Use case trong Hệ thống bán hàng trực tuyến - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 3.2 Biểu đồ Use case trong Hệ thống bán hàng trực tuyến (Trang 46)
Hình 3.15  Mô hình Use case của hệ thống ATM 3.4.4 Phân chia các use case thành các gói (package) - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 3.15 Mô hình Use case của hệ thống ATM 3.4.4 Phân chia các use case thành các gói (package) (Trang 62)
Hình 3.16  Hộp thoại chono workspace - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 3.16 Hộp thoại chono workspace (Trang 63)
Hình 3. Sự tương quan giữa các lớp trong quan hệ tổng quát hoá - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Hình 3. Sự tương quan giữa các lớp trong quan hệ tổng quát hoá (Trang 99)
Sơ đồ lớp của hệ thống ATM sau khi đã tính chế thuộc  tính  Tinh chế hành vi (method) - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Sơ đồ l ớp của hệ thống ATM sau khi đã tính chế thuộc tính Tinh chế hành vi (method) (Trang 128)
Sơ đồ lớp của hệ thống máy ATM với kết quả tinh chế đầu tiên về thuộc tính và hành vi - Giáo trình Phân tích thiết kế hệ thống hướng đối tượng
Sơ đồ l ớp của hệ thống máy ATM với kết quả tinh chế đầu tiên về thuộc tính và hành vi (Trang 134)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w