Bài giảng Lập trình hướng đối tượng - Bài 9: Tổng quan về UML và phân tích thiết thiết kế hướng đối tượng
12/27/17
Nội dung
Bộ môn Công nghệ Phần mềm
Viện CNTT & TT
Trường Đại học Bách Khoa Hà Nội
1. Mô hình hóa
2. Tổng quan về UML
3. Phân tích thiết kế hướng đối tượng
4. Công cụ phát triển OOAD
LẬP TRÌNH HƯỚNG ĐỐI TƯỢNG
Bài 09. Tổng quan về UML và PTTK
HĐT
2
Nội dung
1.1 Mô hình hóa là gì?
n Giúp đơn giản hóa thế giới thực bằng các mô hình
n Giúp hiểu rõ hơn về hệ thống dưới một góc nhìn
1. Mô hình hóa
nào đó
2. Tổng quan về UML
3. Phân tích thiết kế hướng đối tượng
4. Công cụ phát triển OOAD
3
4
1
12/27/17
1.2. Sự quan trọng của mô hình hóa
1.2. Sự quan trọng của mô hình hóa (2)
n Rất nhiều đội dự án tiến hành xây dựng ứng
dụng theo hướng tiếp cận của việc gấp máy
bay giấy.
Mức độ quan trọng cao hơn
Mức độ quan trọng thấp
n
Bắt đầu lập trình ngay khi có được yêu cầu.
n
Mất rất nhiều thời gian và tạo ra rất nhiều mã
nguồn.
n
n
Không có bất kỳ một kiến trúc nào.
Phải chịu khổ với những lỗi phát sinh.
Máy bay giấy
Máy bay phản lực
n Mô hình hóa là một con đường dẫn đến
thành công của dự án.
6
1.3. Vai trò của mô hình hóa hệ thống
1.4. Yêu cầu khi biểu diễn mô hình
n Hình dung một hệ thống theo thực tế hay
n Chính xác (accurate): Mô tả đúng hệ thống
theo mong muốn của chúng ta .
cần xây dựng.
n Chỉ rõ cấu trúc hoặc ứng xử của hệ thống.
n Đồng nhất (consistent): Các view khác nhau
không được mâu thuẩn với nhau.
n Tạo một khuôn mẫu hướng dẫn nhà phát
triển trong suốt quá trình xây dựng hệ thống.
n Ghi lại các quyết định của nhà phát triển để
n Có thể hiểu được (understandable): Cho
những người xây dựng lẫn sử dụng
sử dụng sau này
n Dễ thay đổi (changeable)
n Dễ dàng liên lạc với các mô hình khác.
7
8
2
12/27/17
Nội dung
2.1. UML là gì?
n Ngôn ngữ mô hình hóa thống nhất UML
(Unified Modeling Language)
n UML là ngôn ngữ để:
1. Mô hình hóa
2. Tổng quan về UML
3. Phân tích thiết kế hướng đối tượng
4. Công cụ phát triển OOAD
n
n
n
n
trực quan hóa (visualizing)
xác định rõ (đặc tả - Specifying)
xây dựng (constructing)
tài liệu hóa (documenting)
các cấu phần (artifact) của một hệ thống
phần mềm
9
10
UML là ngôn ngữ trực quan
UML là ngôn ngữ để đặc tả
n UML là ngôn ngữ thống nhất trực
quan giúp công việc được xử lý nhất
quán, giảm thiểu lỗi xảy ra
n UML xây dựng các mô hình chính xác, rõ
ràng và đầy đủ.
n
Có những thứ mà nếu không mô hình
hóa thì không hoặc khó có thể hiểu
được
n
Mô hình trợ giúp hiệu quả trong việc
liên lạc, trao đổi
n
Trong tổ chức
n
Bên ngoài tổ chức
3
12/27/17
UML là ngôn ngữ để xây dựng HT
UML là ngôn ngữ để tài liệu hóa
n UML giúp tài liệu
hóa về kiến trúc,
yêu cầu, kiểm thử,
lập kế hoạch dự án,
và quản lý việc bàn
giao phần mềm
n Các biểu đồ khác
nhau, các ghi chú,
ràng buộc được đặc
tả trong tài liệu
n Các mô hình UML có thể kết nối trực tiếp với
Use Case
Diagram
Deployment Diagram
º
Ð
Ȑ
È
¯°æ
À
Ç
Ç
Ï
µ
å
¿
þ
¾
î
¹
×
³
×
Æ
®
¿
÷À
¸
·
ÎÀ
Ç
Á
¤º
¸
½
Ã
½
º
Å
Û
¿
¬
°á
¸
ðµ
¨
-
À
©
µ
µ
µ
¿
¿
ì
95
:
Å
À
¬
¿
¶
ó
À
Ì
¾
ð
Æ
®
-
À
©
µ
ì
N
T
:
À
ë¼
¹
ö
-
À
¯´
Ð
½
º
¸
Ó
½
Å
:
À
À
¿
ë
¼
¹
ö
¹
×
µ
¥ÀÌÅ
¸
¼
¹
ö,
Å
ë½
Å
¼
¹
ö
-
IB
M
¸
Þ
À
ÎÇ
Á
·
¹
À
Ó
:
µ
¥ÀÌÅ
¸
¼
¹
ö,
Å
ë½
Å
¼
¹
ö
rất nhiều ngôn ngữ lập trình.
W
i
n
d
o
w
s
9
5
W
w
W
i
n
d
o
w
s
9
5
Use Case
Use Case
1
2
¹
®
¼
°
ü
¸
®
Ŭ¶óÀ̾ðÆ®.EXE
¹
®
¼
°
ü
¸
®
¾
Ö
Ç
Ã
¸
´
W
i
ndow
T
s
N
Actor
A
Actor B
n
Ánh xạ sang Java, C++, Visual Basic…
S
o
l
a
r
i
s
¹
®
¼
°
ü
¸
®
¿
£
Á
ø
.
E
X
E
A
l
pha
IX
U
N
ÀÀ¿ë¼¹ö.EXE
W
i
n
d
o
w
s
N
T
IB
M
M
ainfram
e
Use Case
3
n
Các bảng trong RDBMS hoặc kho lưu trữ trong
OODBMS
µ
¥ÀÌÅ
¸
º
£À̽
º
¼
¹
ö
D
ocumentList
m
a
i
n
W
n
d
fi
l
e
M
g
r
:
d
o
c
u
m
e
n
t
:
g
F
i
l
e
repository
D
o
c
u
m
e
n
t
F
i
l
e
M
g
r
F
i
l
e
M
g
r
D
o
c
u
m
e
n
t
user
add(
)
nam
doc
e
:
:
i
nt
f
e
t
c
h
D
o
c
(
)
d
e
l
e
t
e
(
)
i
d
i
nt
s
o
r
t
B
y
N
a
m
e
(
)
num
F
i
el
d
:
i
nt
get(
)
Æ
¯Á¤¹
®
¼
¿
¡
´
ëÇ
Ñ
º
.
¸
±â¸
¦
1:
D
oc
v
i
ew
r
eques
t
(
)
ȍ
¿
ë
À
Ú
°
¡
¿
äûÇ
Ñ
´
Ù
open(
)
r
e
a
d
(
)
f
i
l
l
t
h
e
c
ode..
c
l
o
s
e
(
)
2
:
f
e
t
c
h
D
o
c
(
)
r
ead(
)
F
ileList
s
ortF
eate(
fi
i
l
eLi
s
t(
)
f
L
i
s
t
c
r
)
3
:
c
r
e
a
t
e
(
)
l
l
D
o
c
u
m
e
n
t
(
)
add(
)
n
n
Cho phép các kỹ nghệ xuôi (chuyển UML thành
mã nguồn)
Cho phép kỹ nghệ ngược (xây dựng mô hình hệ
thống từ mã nguồn)
d
e
l
e
t
e
(
)
1
4
:
c
r
e
a
t
e
(
)
5
:
r
e
a
d
D
o
c
(
)
È
À
Ï°ü¸
®
À
Ú
´
Â
À
Ð
Ç
¾
Ø
î¿
Â
6
:
f
i
l
l
D
o
c
u
m
e
n
t
(
)
¹
®
¼
À
Ç
Á
¤º
¸
¸
¦
´
ç
¹
®
¼
°
´
Ã
¼
¿
¡
¼
³
Á
¤À
»
¿
äûÇ
Ñ
´
Ù
.
r
ep
7
:
r
e
a
d
F
i
l
e
(
)
F
i
l
e
R
epository
8
:
f
i
l
l
F
i
l
e
(
)
(
f
r
o
m
P
e
r
s
i
s
t
e
n
c
e
)
r
ead(
)
G
r
p
F
i
l
e
È
¸
é
°
´
Ã
¼
´
Â
À
Ð
¾
îµéÀ
̸§º°·
é¿
Î
9:
s
o
r
t
B
y
N
am
e
(
)
nam
e
)
:
c
har
*
=
0
°
´
Ã
¼
µ
é¿
¡
´
ëÇ
Ø
À
Î
Á
¤·
Ä
À
»
½
Ã
Ä
Ñ
È
¸
¡
r
ead(
open(
eate(
e(
)
º
¸
¿
©
Á
Ø
´
Ù
.
r
e
a
d
D
o
c
(
)
r
e
a
d
F
i
l
e
(
)
c
r
)
fi
l
l
F
i
l
)
Sequence Diagram
Class Diagram
2.2. Lịch sử phát triển của UML
2.2. Lịch sử phát triển của UML (2)
n
Vào 1994, có hơn 50 phương pháp mô hình hóa hướng đối
tượng:
n
UML được 3 chuyên gia hướng đối
tượng hợp nhất các kỹ thuật của họ
vào năm 1994:
n
Fusion, Shlaer-Mellor, ROOM, Class-Relation,Wirfs-Brock, Coad-
Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis,
COMMA, HOOD, Ooram, DOORS …
n
Booch91 (Grady Booch): Conception,
Architecture
n
n
OOSE (Ivar Jacobson): Use cases
OMT (Jim Rumbaugh): Analysis
n
n
n
“Meta-models” tương đồng với nhau
Các ký pháp đồ họa khác nhau
n
Thiết lập một phương thức thống
nhất để xây dựng và “vẽ” ra các
yêu cầu và thiết kế hướng đối
tượng trong quá trình PTTK phần
mềm à UML được công nhận là
chuẩn chung vào năm 1997.
Quy trình khác nhau hoặc không rõ ràng
à Cần chuẩn hóa và thống nhất các phương pháp
4
12/27/17
UML là một ngôn ngữ hợp nhất
UML là một ngôn ngữ thống nhất
Rumbaugh
Booch
Jacobson
Meyer
Fusion
Before and after
conditions
Operation descriptions,
message numbering
Harel
Embley
Singleton classes,
High-level view
State charts
Gamma, et.al
Wirfs-Brock
Frameworks, patterns,
notes
Responsibilities
Shlaer- Mellor
Object lifecycles
Selic, Gullekson, Ward
ROOM (Real-Time
Object-Oriented Modeling)
Odell
Classification
2.3. Các khung nhìn của UML
2.2. Lịch sử phát triển của UML (3)
UML 2.0
(2004)
n Không đơn giản để mô hình hóa hệ thống
UML 1.5
phức tạp
(March, ‘03)
n Lý tưởng: mô tả hệ thống trong 1 bản vẽ duy
nhất à Bất khả thi
UML 1.1
UML
Partners’
Expertise
(Sept. ‘97)
UML 1.0
(Jan. ‘97)
n
Một hệ thống cần được miêu tả trên các khía
cạnh khác nhau: chức năng, phi chức năng, các
thức hoạt động
UML 0.9 and UML 0.91
(June ‘96)
(Oct. ‘96)
Public
Feedback
Unified Method 0.8
(OOPSLA ’95)
n à Hệ thống phải được miêu tả theo các
Booch ’93 OMT - 2
hướng nhìn khác nhau
Other
Methods
OOSE
Booch ‘91
OMT - 1
20
5
12/27/17
2.3. Các khung nhìn của UML (2)
2.4. Các biểu đồ UML
n Khung nhìn của mô hình có ý nghĩa với những
n Biểu đồ:
Biểu diễn các chức
người tham gia nào đó
n 4 + 1 Architectural View
n
là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa
năng và môi
n
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.
trường dự kiến của
hệ thống dưới góc
nhìn của người
Logical View
Implementatio
n 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.
n Một biểu đồ là một thành phần của một hướng nhìn
dùng
Môtảcácnút vật
Analysts/Designers
Structure
Programmers
Software management
Use-Case View
End-user
Functionality
lý khác nhau và
Mô tả việc tổ
chức các mô-đun
phần mềm tĩnh
cụ thể
Process View
Deployment View
System engineering
System topology, delivery,
installation, communication
n Một số loại biểu đồ có thể là thành phần của nhiều
nhằm chia thành
System integrators
Performance, scalability, throughput
package, phân
hướng nhìn khác nhau
lớp và quản lý
cấu hình
22
2.4. Các biểu đồ UML
a. Biểu đồ use case
n
n
Biểu đồ use case (Use Case Diagram)
n Biểu đồ mô tả các yêu cầu chức năng của hệ
Biểu đồ cấu trúc tĩnh (Static Structure Diagrams)
thống dưới dạng các use case.
n
Biểu đồ lớp (Class Diagram)
n
Biểu đồ đối tượng (Object Diagram)
n Bao gồm các chức năng mong đợi của hệ th
n
n
n
Biểu đồ trạng thái (Statechart Diagram)
Biểu đồ hoạt động (Activity Diagram)
Biểu đồ tương tác (Interaction Diagrams)
ống (use case) và môi trường (actor) của nó.
n
Biểu đồ trình tự (Sequence Diagram)
n
Biểu đồ giao tiếp/cộng tác (Communication/Collaboration Diagram)
n
Biểu đồ thực thi (Implementation Diagrams)
n
Biểu đồ thành phần (Component Diagram)
Biểu đồ triển khai (Deployment Diagram)
n
24
6
12/27/17
b. Biểu đồ lớp (Class Diagram)
c. Biểu đồ đối tượng
n Chỉ ra:
n Chỉ ra một loạt các đối tượng thực thể của
lớp
n
cấu trúc tĩnh của các lớp trong hệ thống
n
và các mối quan hệ giữa chúng
n Là 1 ví dụ, bổ sung giải thích thêm cho biểu
đồ lớp
25
26
d. Biểu đồ trạng thái (State Diagram)
e. Biểu đồ hoạt động (Activity Diagram)
n Chỉ ra:
n Chỉ ra một trình tự
lần lượt của các hoạt
động trong 1 tiến
trình xử lý
n
tất cả các trạng thái mà đối tượng của 1 lớp có thể có
n
và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng
thái
n Ví dụ các trạng thái
n Gồm các trạng thái
hành động
của 1 server:
n
Một trạng thái hành
động sẽ qua đi khi
hành động được thực
hiện xong
27
28
7
12/27/17
g. Biểu đồ cộng tác (Collaboration
Diagram)
f. Biểu đồ trình tự (Sequence Diagram)
n Chỉ ra một cộng tác động giữa một loạt các
n Chỉ ra một sự cộng tác động
đối tượng
n Giống biểu đồ trình tự (Thường chỉ chọn 1
n Nhấn mạnh trình tự & thời gian các thông
điệp (message) được gửi giữa các đối
tượng
trong 2)
n
Ưu tiên ngữ cảnh: dùng biểu đồ cộng tác
n
Ưu tiên thời gian, trình tự: dùng biểu đồ trình tự
29
30
h. Biểu đồ thành phần
(Component Diagram)
i. Biểu đồ triển khai (Deployment
Diagram)
n Mô tả các tài nguyên
vật lý trong hệ thố
ng, bao gồm các nút
(node), thành phần v
à kết nối.
n Biểu diễn sự tổ chức và phụ thuộc giữa các
thành phần phần mềm: mã nguồn, mã nhị
phân (binary code) và những thành phần có
khả năng thực thi
n Mỗi mô hình chỉ bao
gồm một deployment
diagram hiển thị ánh
xạ giữa những tiến tr
ình xử lý tới thiết bị
phần cứng
31
32
8
12/27/17
2.5. Quy trình và UML
2.5. Quy trình và UML (2)
n RUP là quy trình
n UML là ký pháp
công nghệ phần
mềm phát triển bởi
hãng Rational
chứ không phải là
phương pháp
n
UML có thể áp dụng
cho tất cả các pha
của quy trình phát
triển phần mềm
n Là quy trình lặp và
tăng trưởng từng
bước
n
"Rational Unified
n Sử dụng các ký hiệu
Process" - quy trình
phát triển cho UML
trực quan của UML
n Phát triển song song
với UML
2.6. Ứng dụng của UML trong phân tích
thiết kế hệ thống
Nội dung
n UML được sử dụng để phân tích nhiều loại hệ
thống
1. Mô hình hóa
2. Tổng quan về UML
3. Phân tích thiết kế hướng đối
n
n
n
n
n
n
Hệ thống thống tin (Information System)
Hệ thống kỹ thuật (Technical System)
Hệ thống nhúng (Embeded System)
Hệ thống phân tán ( Distributed System)
Hệ thống nghiệp vụ (Business System)
Phần mềm hệ thống (System Software)
tượng
4. Công cụ phát triển OOAD
35
36
9
12/27/17
3.1. Tầm quan trọng của OOAD
3.1. Tầm quan trọng của OOAD (2)
n
Nhiều người phát triển dự án
n Cần thiết lập một cơ chế hiệu quả để nắm
n
Cho rằng phần mềm chủ yếu được xây dựng bằng cách
bắt yêu cầu, phân tích thiết kế
gõ “code” từ bàn phím
n
Không dành đủ thời gian cho quá trình phân tích và thiết
kế phần mềm
n Cơ chế này phải như là một “ngôn ngữ thống
nhất” giúp cho quá trình hợp tác hiệu quả
giữa các thành viên trong nhóm phát triển
phần mềm.
n
n
à Họ phải “cày bừa” để hoàn thành chương trình vì
n
n
n
Không hiểu hoặc hiểu sai yêu cầu
Giao tiếp với các thành viên không tốt
Không tích hợp được với module của đồng nghiệp…
n à OOAD
à Họ nhận ra rằng “Phân tích” và “Thiết kế” cần
được coi trọng hơn, nhưng đã quá muộn
37
38
3.2. Mục đích của OOAD
3.3. Phương pháp OOAD
n Chuyển các yêu cầu của bài toán thành một bản
n OOAD được chia thành 2 giai đoạn
thiết kế của hệ thống sẽ được xây dựng
n
Phân tích hướng đối tượng (OOA)
n Tập trung vào quá trình phân tích các YÊU CẦU của
hệ thống và thiết kế các MÔ HÌNH cho hệ thống đó
trước giai đoạn lập trình
n Được thực hiện nhằm đảm bảo mục đích và yêu
cầu của hệ thống được ghi lại một cách hợp lý
trước khi hệ thống được xây dựng
n
Thiết kế hướng đối tượng (OOD)
n OOA là giai đoạn nhằm tạo ra các mô hình cơ
bản (mô hình khái niệm) của hệ thống dựa
theo những gì khách hàng yêu cầu về hệ
thống của họ
n OOD sẽ bổ sung thêm các thông tin thiết kế
n Cung cấp cho người dùng, khách hàng, kỹ sư phân
chi tiết cho các mô hình nói trên
tích, thiết kế nhiều cái nhìn khác nhau về cùng một
hệ thống
39
40
10
12/27/17
3.3. Phương pháp OOAD (2)
3.3.1. OOA
1. Use case modeling to define
6. External Specification Design
requirements
n Tạo được mô hình có các thành phần là đối
tượng và khái niệm đời thực, dễ hiểu với
người dùng
5. Normalization of the data
structure using E-R diagram
2. Object extraction and message
n Mô hình hóa các thực thể, giữ nguyên cấu
sequence design between objects
trúc, quan hệ, hành vi giữa chúng
4. E-R modeling for persistent data
3. Class design
41
42
3.3.1. OOA (2)
3.3.2. OOD
n
Ví dụ với 1 phòng bán ô tô:
n
n
Tổ chức chương trình thành các tập hợp đối tượng
cộng tác
n
Các thực thể:
n
n
n
n
n
Khách hàng
n
Mỗi đối tượng là thực thể của một lớp
Người bán hàng
Phiếu đặt hàng
Phiếu (hoá đơn) thanh toán
Xe ô tô
Thiết kế trên kết quả của OOA
n
Cải thiện, tối ưu hóa thêm
n
Thiết kế các
n
n
n
Phương thức (operations)
Thuộc tính (attributes)
Mối quan hệ giữa các lớp (classes)
n
Tương tác và quan hệ giữa các thực thể trên :
n
n
n
n
n
Người bán hàng dẫn khách hàng tham quan phòng trưng bày xe.
Khách hàng chọn một chiếc xe
Khách hàng viết phiếu đặt xe
Khách hàng trả tiền xe
Xe ô tô được giao đến cho khách hàng
n
Đưa ra các biểu đồ tĩnh và động
n
Tĩnh: biểu thị các lớp và đối tượng
Động: biểu thị tương tác giữa các lớp & phương thức hoạt động
n
43
44
11
12/27/17
Thiết kế biểu đồ lớp
Thiết kế đối tượng (1/2)
n Mục tiêu: cần xác định các thành viên của mỗi lớp và
n Trong PT&TK hướng đối tượng người ta đã
quan hệ giữa các lớp
tổng kết 5 bước để thiết kế đối tượng:
n Một trong các kỹ thuật được ứng dụng nhiều nhất là Thẻ
Class-Responsibility-Collaboration (CRC) card.
n
Bước 1. Phát hiện đối tượng (Object discovery).
Bước này được thực hiện ở giai đoạn phân tích
chương trình.
n Mỗi thẻ thể hiện một lớp, trên thẻ chúng ta lưu lại các
thông tin sau về các lớp:
n
n
n
1. Tên của lớp. Thông thường người ta đặt tên lớp liên quan
đến vai trò của lớp, chúng ta sẽ sử dụng lớp để làm gì.
n
Bước 2. Lắp ráp đối tượng (Object assembly).
Bước tìm kiếm các đặc điểm của đối tượng để
thêm vào các thuộc tính, các hàm thành phần
cho đối tượng
2. Trách nhiệm của lớp: lớp có thể làm gì. Thông thường các
thông tin ở đây bao gồm tên của các hàm thành phần
3. Tương tác của lớp: lớp này có thể tương tác được với
những lớp nào khác
45
46
Thiết kế đối tượng (2/2)
Lưu ý (1/2)
n Trong PT&TK hướng đối tượng người ta đã tổng kết 5
n
Một số điểm lưu ý khi phát triển các lớp
bước để thiết kế đối tượng:
n
1. Cần tạo ra lớp trước, sau đó mới nghĩ tới việc phát
triển và hoàn thiện lớp trong quá trình giải quyết bài
toán
n
n
n
Bước 3. Xây dựng hệ thống (System construction). Trong giai
đoạn này chúng ta phát triển các đối tượng, xem xét các
tương tác giữa các đối tượng để hình thành hệ thống hoạt
động.
n
2. Khi phân tích hay phát triển các lớp không nên tập
trung xác định tất cả thành viên một lớp, chúng ta sẽ
biết rõ hơn khi phát triển hệ thống (learns as you
go)
Bước 4. Mở rộng hệ thống (System extension). Khi chúng ta
thêm vào các tính năng của hệ thống, cần thêm các lớp mới,
các đối tượng mới và các tương tác giữa các đối tượng này với
các đối tượng đã có trong hệ thống.
Bước 5. Tái sử dụng đối tượng (Object reuse). Đây là một
trong những thử nghiệm quan trọng của các đối tượng và lớp
trong thiết kế phần mềm. Chúng ta cần phải sử dụng lại các
lớp và các đối tượng trong phần mềm (thông qua tính kế thừa
và tương tác giữa các đối tượng)
n
3. Việc phát hiện ra các lớp cần thiết cho chương
trình là một trong những nhiệm vụ chính của thiết kế
hệ thống, nếu chúng ta đã có những lớp này (trong
một thư viện lớp nào đó chẳng hạn) thì công việc sẽ
dễ dàng hơn
47
48
12
12/27/17
Lưu ý (2/2)
Nội dung
n
Một số điểm lưu ý khi phát triển các lớp
n
4. Khi lập trình cần tuân thủ theo các thiết kế đã
làm. Không nên băn khoăn khi không sử dụng
phương pháp lập trình truyền thống và thấy choáng
ngợp trước số lượng lớn các đối tượng.
1. Mô hình hóa
2. Tổng quan về UML
n
5. Luôn giữ nguyên tắc: mọi vấn đề cần giải quyết
theo phương án đơn giản nhất, không phức tạp hóa.
Sử dụng nguyên lý của Occam Razor: Lớp đơn giản
nhất bao giờ cũng là lớp tốt nhất, hãy bắt đầu bằng
những cái đơn giản và chúng ta sẽ kết thúc bằng
những hệ thống phức tạp
3. Phân tích thiết kế hướng đối tượng
4. Công cụ phát triển OOAD
49
50
4. Công cụ UML – OOAD
n Công cụ mã nguồn mở:
n
n
n
EclipseUML
UmlDesigner
ArgoUML...
n Công cụ thương mại:
n
n
n
n
n
Enterprise Architect
IBM Rational Software Architect
Microsoft Visio
Visual Paradigm for UML
SmartDraw...
51
13
13 trang
19260
Free
Bạn đang xem tài liệu "Bài giảng Lập trình hướng đối tượng - Bài 9: Tổng quan về UML và phân tích thiết thiết kế hướng đối tượng", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bai_giang_lap_trinh_huong_doi_tuong_bai_9_tong_quan_ve_uml_v.pdf
