Hệ thống bất động sản nhà ở home realty system (thực hành trên rational rose)

bộ giáo dục và đào tạo
Trờng đạI học vinh

=========*@*=========

Luận văn tốt nghiệp

Đề đề tài:
tài:

phân tích thiết kế hệ thống
hệ thống bất động sản nhà ở
hớng đốirealty system
Home tợng bằng UML
áp dụng cho hệ thống
(Thực hành trên Rational Rose)
quản lý kinh doanh bất
Ngành: tin học
động sản nhà ở
(thực hành trên Rational Rose)
Ngành: tin học

GV hớng dẫn: Thạc sĩ Phạm QuangTrình
SV thực hiên : Trần Thị Gia
GV hớng dẫn: Thạc sĩ Phạm QuangTrình
SV thực hiên : Trần Thị Gia
vinh tháng 5-2003


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Mục Lục

Lời nói đầu
Phần I. Mở đầu
1. Lý do chọn đề tài
2. Lịch sử vấn đề nghiên cứu
3. Mục đích nghiên cứu
4. Khách thể nghiên cứu và đối tợng nghiên cứu
7
5. Nhiệm vụ nghiên cứu
6. Giới hạn phạm vi nghiên cứu
7. Phơng pháp nghiên cứu
Phần II. Phân tích thiết kế hớng đối tợng bằng UML
8
(Thực hành trên Rational Rose)
Chơng 1. Giới thiệu công nghệ hớng đối tợng và PTTKHT hớng đối tợng
8
1.1. Công nghệ đối tợng (Object Tecnology-OT)
1.1.1. Công nghệ đối tợng là gì ?
1.1.2. Công nghệ đối tợng đợc sử dụng trong các lĩnh vực nào?
1.1.3. Sức mạnh của công nghệ đối tợng
8
1.2. Một số khái niệm cơ bản liên quan đến vấn đề nghiên cứu
1.3. Các nguyên tắc hớng đối tợng
1.3.1. Một đối tợng là gì ?
14
1.3.2. Sự xác định một đối tợng
1.3.3. Trạng thái của một đối tợng
15
1.3.4. Hành vi của một đối tợng
1.3.5. Các đặc tính của một đối tợng
1.3.6. Bốn nguyên tắc cơ bản của công nghệ đối tợng

1.4. Phân tích thiết kế hệ thống hớng đối tợng
1.5. Giới thiệu các phơng pháp phát triển phần mềm
1.5.1. Phơng pháp phát triển phần mềm theo mô hình thác nớc (cổ điển)
1.5.2. Phơng pháp phát triển phần mềm theo mô hình lặp và tăng dần 19
1.5.3. Phơng pháp phát triển phần mềm theo tiến trình hợp nhất Rational
Chơng 2. Khái quát về UML và mô hình hoá trực quan
2.1. Mô hình hoá trực quan (Visual Modeling)
2.1.1. Giới thiệu
2.1.2. Lợi ích của mô hình hoá trực quan
2.1.3. Bốn nguyên tắc cơ bản của mô hình hoá trực quan
2.2. Ngôn ngữ mô hình hoá hợp nhất UML-Unified Modeling Language
2.2.1. Giới thiệu UML
2.2.2. Mô hình khái niệm của UML
2.2.3. Mô hình dữ liệu
2.2.4. Kiểu dữ liệu
2.2.5. Các biểu đồ UML
2.3. Làm thế nào để đa UML vào PTTKHT
Chơng 3. Những vấn đề cơ sở của mô hình Rational Rose
3.1. Rational Rose là gì?
3.2. Sử dụng Rational Rose để tạo lập các biểu đồ UML
3.3. Kiến trúc hệ thống và khung nhìn trong Rational Rose
3.3.1. Kiến trúc hệ thống là gì?
3.3.2. Các khung nhìn trong Rational Rose
-1-

Trang
4
5
5
5

7
7
7
7

8
8
8
9
14
15
15
15
15
17
18
18
21
25
25
25
25
25
27
27
29
33
33
33
34

35
35
35
36
36
36


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Chơng 4. Mô hình hoá trờng hợp-sử dụng (use-case Modeling)
4.1. Mô hình trờng hợp sử dụng là gì?
4.2. Tác nhân và cách tìm kiếm tác nhân
4.3. Phân tích trờng hợp sử dụng
4.3.1. Use-Case là gì?
4.3.2. Tìm kiếm các Use-Case nh thế nào?
4.4. Tìm hiểu các đặc tả trờng hợp-sử dụng (Use-case Specification)
Chơng 5. Mô hình hoá tơng tác đối tợng
5.1. Đối tợng và tìm kiếm đối tợng
5.2. Biểu đồ tơng tác
5.2.1. Biểu đồ tuần tự và các thành phần của nó
5.2. 2. Biểu đồ cộng tác và các thành phần của nó
5.2.3. So sánh biểu đồ cộng tác và biểu đồ tuần tự
Chơng 6. Các biểu đồ lớp và gói
6.1. Lớp và tìm kiếm lớp
6.2. Các khuôn mẫu của lớp
6.3. Các biểu đồ lớp
6.4. Sự tổ chức các biểu đồ lớp trên các gói
6.5. Các mối quan hệ trong biểu đồ lớp
Phần III. PTTKHT hớng đối tợng bằng UML áp dụng cho
hệ thống Bất động sản nhà ở

39
39
40
41
43
49
49
49

62

62
62

I.. Phân tích

1.1.Giới thiệu, mục tiêu và các chức năng
1.2. Nghiên cứu mô hình hoá trờng hợp sử dung cho hệ thống
1.2.1.Mô tả các tác nhân ngoài (Actor )
1.2.2. Xác định các use-case
1.2.2.1. Use-case áp dụng cho sự vay mợn
1.2.2.2. Use-case Tìm ngời kinh doanh bất động sản
1.2.2.3. Use-case Liệt kê các thuộc tính
1.2.2.4. Use-case Duy trì ngời lập kế hoạch cá nhân
1.2.2.5. Use-case Duy trì sơ yếu lý lịch
1.2.2.6. Use-case Tìm kiếm một nhà ở
1.3. Biểu đồ use-case (Use-case Diagram)
1.4.Các đặc tả Use-Case của hệ thống Bất động sản nhà ở
1.5. Các biểu đồ hoạt động

50
53
55
56
56
57
59
60
60

63
63
64
64
64
64
64
64
64
65
65
69
72
72
74

ii. thiết kế

2.1. Tìm kiếm c¸c líp

2.2.C¸c sù thùc hiƯn use-case (Use-case Realization)
trong “hƯ thèng bất động sản nhà ở

83
83
83
84
84
89
89

IIi. Mô hình dữ liệu

3.1. Thực thể và các liên kết
3.2. Mô hình khái niệm
3.3. Mô hình dữ liệu
3.4. Các bảng
Iv. cài đặt

4.1. Môi trờng cài đặt
4.1.1. Môi trờng
4.1.2. Phần mền sử dụng

89
89
-2-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
4.1.3. Cài đặt

4.2. Các cửa sổ (Windows)
4.2.1. Main Window
4.2.2. Realtor Record Window
4.2.2.1. New Realtor Window
4.2.2.2. Profile of Realtor Window
4.2.3. Buyer Record Window
4.2.4. Loan Application Window
4.2.5. Lender Window
4.2.6. Lender Catalog Window
4.2.7. HomeListing Window
4.2.8. Get Information Home Window
4.2.9. Display Information Home Window
4.2.10. Planner Profile Window
4.2.11. School Information Window
4.2.12. Neighborhood Information Window
4.2.13. City Information Window
4.2.14. Realtor Catalog with home
Tóm tắt
Tài liệu tham khảo

Các chữ viết tắt trong luận văn này
UML

:Unified Modeling Language (Ngôn ngữ mô hình hoá hợp nhất)

OO

: Object Oriented (Hớng đối tợng)

PTTKHT : Phân tích thiết kế hệ thống

HRS

:Home Realty System (Hệ thống bất động sản nhà ở)

CNTT

: công nghệ thông tin

OT

: Object Technique (Công nghệ đối tợng)

UC

: Use-Case (Trờng hỵp sư dơng)

-3-

89
89
89
90
90
90
91
92
92
93
93
94

94
95
95
96
96
96
97
98


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose

lời nói đầu
Ngày nay, CNTT đà đạt đợc những thành tựu vô cùng to lớn trong mọi
lĩnh vực của đời sống, kinh tế, chính trị, xà hội,...Các bớc tiến nhảy vọt của CNTT ứng
dụng trong các hệ thống quản lý ngày càng phức tạp, đánh dấu một bớc ngoặt quan
trọng trong lịch sử phát triển của CNTT. Xu thế áp dụng phơng pháp hớng đối tợng
(phơng pháp mới) thay cho phơng pháp hớng chức năng-cấu trúc (phơng pháp truyền
thống) ngày càng đợc phổ biến trong việc xây dựng các hệ thống phần mềm lớn và phức
tạp. Do nhu cầu ứng dụng CNTT ngày càng cao, ngôn ngữ mô hình hoá hợp nhất
(Unified Modeling Language-UML) đà ra đời và hoàn thiện vào tháng 6 năm 1996, đợc tổ chức OMG (Object Management Group) công nhận là chuẩn công nghiệp vào
tháng 11 năm 1997, từ đó UML đà trở thành công cụ phổ dụng và hữu hiệu cho phơng
pháp mới này. Với điều kiện đất nớc ta ngày nay đang trên đà hội nhập CNTT, thì phơng pháp mới này cha đợc sử dụng rộng rÃi và quen thuộc với tất cả mọi ngời. Ngay cả
đối với những sinh viên khoa CNTT thực thụ khi ra trờng để bắt tay vào công việc
PTTK hệ thống hớng đối tợng vẫn còn là một sự ngỡ ngàng không tránh khỏi. Với đề
tài này, mục đích chủ yếu của tôi là giới thiệu các khái niệm cơ bản về công nghệ đối tợng và mô hình hoá hệ thống phần mềm theo phơng pháp hớng đối tợng bằng UML
(thực hành trên Rational Rose) thông qua một ví dụ cụ thể là: PTTK hớng đối tợng bằng UML áp dụng cho hệ thống bất động sản nhà ở dới góc nhìn
của một ngời phát triển hệ thống phần mềm (ngời phân tích, thiết kế, cài đặt). Mặc dù
đà rất cố gắng, song do điều kiện hạn chế tài liệu bằng tiếng việt, việc phiên dịch từ tài
liệu bằng tiếng anh không thể tránh khỏi những thiếu sót và có những ngôn từ cha sát

nghĩa, rất mong đợc sự đóng góp ý kiến chân thành của các thầy cô giáo trong và ngoài
khoa CNTT, của tất cả các bạn sinh viên để đề tài này đợc hoàn thiện hơn.
Đề tài đợc hoàn thành ngoài sự cố gắng của bản thân, còn có sự giúp đỡ rất
lớn và tận tình của Thầy giáo Phạm Quang Trình, các thầy cô giáo trong khoa CNTT
cùng tập thể lớp 40A. Tôi xin ghi nhận mọi ý kiến đóng góp quý báu của tất cả các
Thầy Cô giáo, các bạn .Tôi xin chân thành cảm ơn.

Sinh viên thực hiện

-4-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Phần I. Mở đầu
1. Lý do chọn đề tài
Ngày nay công việc phát triển hệ thống phần mềm gặp rất nhiều khó khăn. Vấn
đề không phải là ở tốc độ thực hiện chơng trình, kinh phí hay sức mạnh của hệ thống
mà là ở: Độ phức tạp (Sun Microsystems). Chúng ta - Những ngời phát triển hệ thống
cần phải làm gì để loại bỏ nó.
Để phát triển thành công một hệ thống phần thì khâu PTTKHT chiếm một phần
vô cïng quan träng. Tõ tríc ®Õn nay chóng ta míi đợc làm quen với phơng pháp
PTTKHT hớng chức năng: Pha sau chỉ bắt đầu khi pha trớc đà kết thúc. Hệ thống thì
lại luôn phải sửa đổi theo thời gian khi xt hiƯn sù kh«ng thÝch nghi víi thùc tÕ. Phát
triển hệ thống theo hớng này dễ dẫn đến các phần chính của ứng dụng không đợc
hoàn thành đúng kế hoạch, khó bảo trì, khó sửa đổi hay mở rộng hệ thống quá nhiều
làm cho chơng trình khác xa quan niệm ban đầu. Vì thế một phơng pháp mới là rất
cần thiết cho những ngời phát triển hệ thống. Đó chính là phơng pháp PTTKHT hớng
đối tợng, với u điểm nổi bật : Tính ổn định của đối tợng tạo ra khả năng dùng lại đợc,
mở rộng đợc; tính đóng kín của đối tợng tạo nên khả năng dễ sửa đổi, dễ bảo trì; tính
nhất quán trong mô hình từ phân tích, thiết kế đến lập trình đều sử dụng một cách

biểu diễn thống nhất bằng đối tợng đem đến cho chúng ta khả năng làm chủ đợc độ
phức tạp, quản lý đợc chất lợng, độ tin cậy phần mềm đợc đảm bảo ngay cả khi cấu
trúc bị tách ra hay bị tiến hoá.
UML là một công cụ PTTKHT hớng đối tợng, với những u điểm nổi bật của
công nghệ đối tợng, đặc biệt là khả năng phát sinh mà trình từ mô hình phân tích sang
các ngôn ngữ lập trình hớng đối tợng nh: Java, C++, Visual Basic,...Vì thế, UML cho
phép ta dễ dàng sửa đổi, một sự thay đổi từ mô hình sẽ kéo theo một sự thay đổi trong
mà trình và ngợc lại.
Sau một thời gian nghiên cứu, kết quả là tôi đà sử dụng UML vào việc
PTTKHT Bất động sản nhà ở , mặc dù đây là một hệ thống cha đợc phát triển mạnh
ở Việt nam nhng nó phản ánh đợc một cách đầy đủ và chính xác những lợi ích của
UML. Vì thế, sự lựa chọn này tôi cho là rất sát thực với mục đích của đề tài.
2. Lịch sử vấn đề nghiên cứu
Công nghệ đối tợng không phải là một ý tởng mới. Nó đà có cách đây khoảng
hơn 30 năm. Hình dới đây thể hiện một lịch sử ngắn gọn về các mốc chính trong lịch
sử của công nghệ đối tợng
Simula

Smalltalk

1967

1972

C++

Java

cuối 1980

UML

....

1991

1996

2000+

- Năm 1967, Simula đà đợc ra đời và trở thành ngôn ngữ đầu tiên sử dụng các
đối tợng và lớp
- Năm 1972, Alankay và những ngời khác ở XeroxPARC đà tạo ra Smalltalk,
nguồn gốc của nó xuất phát từ Simula. Năm 1980 Smalltalk lần đầu tiên đợc thực hiện
với một chơng trình hớng đối tợng về lĩnh vực thơng m¹i.
-5-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
- Cuối những năm 1980, Biame Stroustrop đà công bố ngôn ngữ C++ với quần
chúng. C++ không phải là một ngôn ngữ hoàn toàn mới, nó là sự mở rộng các khả
năng vốn có của ngôn ngữ lập trình C.
- Năm 1991, Jame Gosling đà đa ra ngôn ngữ Oak, sau này nó đợc phát triển
thành Java, là ngôn ngữ lập trình về mạng. Oak đợc tạo ra bởi nhóm phát triển của
ông ở Sun khi nhóm này đang viết phần mềm cho những ứng dụng thông tin. Ông
thấy C++ quá phức tạp và không an toàn cho công việc của mình. Oak đà ra đời trong
hoàn cảnh đấy.
- Khi các ngôn ngữ lập trình hớng đối tợng đợc sử dụng rộng rÃi thì nhu cầu có
phơng pháp phát triển phần mềm hớng đối tợng trở nên cấp bách. Vào cuối năm 1980
đầu năm 1990, có nhiều phơng pháp luận khác nhau. Ba phơng pháp phổ biến trong

nhiều phơng pháp đó là: Phơng pháp Booch do Grady Booch, OMT (Object Modeling
Technique) cđa JimRumbaugh vµ OOSE (Object Oriented Software Engineering)/
Objectory của Ivar Jacobson. Mỗi phơng pháp có kí pháp, tiến trình, công cụ hỗ trợ
riêng và có những điểm mạnh, điểm yếu riêng biệt. Booch mạnh về thiết kế, OMT và
OOSE mạnh về phân tích.
- Năm 1993, Grady xuất bản hai tập sách có nội dung chứa đựng rất nhiều kỹ
thuật phân tích tốt từ OMT và OOSE, cũng trong thời gian đó Jim đà xuất bản một
loạt các bài báo hợp thành một tuyển tập gọi là OMT-2, chứa đựng các kỹ thuật
phân tích lớn cùng với việc sử dụng các công cụ từ OOSE và các kỹ thuật thiết kế từ
Booch. Vì thế, từ đây sự hợp nhất không chính thức 3 phơng pháp này đà bắt đầu.
- Tháng 10 năm 1994, Jim đà kết nối Rational. Grady và Jim cùng làm việc trên
một sự hợp nhất chính thức ở OOPSLA vào năm 1995, 8 phiên bản của phơng pháp
hợp nhất đà đợc xuất bản.
- Ivar gộp các tiến trình không chính thức, cho đến tháng 6 năm 1996 ông đÃ
hoàn thành phơng pháp hợp nhất và đà xuất bản ra 9 phiên bản mới. Từ thời điểm
này, nhóm phát triển hớng đối tợng nói trên cho rằng nhiệm vụ của họ là tạo ra ngôn
ngữ mô hình hoá thống nhất cho cộng đồng hớng đối tợng. Do đó nhóm này đà đổi
tên công việc của họ thành Unified Modeling Language-UML (Ngôn ngữ mô hình
hoá hợp nhất). Booch, Rumbaugh và Jacobson đà đa ra nhiều phiên bản UML, trong
đó phiên bản UML 0.9 ra đời năm 1995, tháng 1 năm 1997, UML 1.0 ra đời. Phần lớn
các phiên bản UML đợc xây dựng dựa trên nền tảng của các phơng pháp Booch, OMT
và OOSE, ngoài ra UML còn bao gồm cả các khái niệm có nguồn gốc từ các phơng
pháp khác nhau nh: David Havel, Gamma Helm, Johnson-Vlissides và Fusion. UML
còn là kết quả của sự đóng góp từ các hẵng lớn nh: Digital Equipment Corporation
(DEC); Hewlett Packed (HP), Intellicorp, IBM, Microsoft, Oracle, Rational Software
Corporation, Jaskon, Object Time và Unisys,...
- Phiên bản UML 1.1 đà đợc đệ trình lên OMG (Object Management Group) để
công nhận là chuẩn công nghiệp vào tháng 6/1997 và đà đợc chấp nhận vào tháng 11
năm 1997. Phiên bản UML 1.3 đà ra đời vào năm 1999, UML 1.4 là phiên bản mới
nhất đợc ra đời vào tháng 2 năm 2000.

-6-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
3. Mục đích nghiên cứu
Việc nghiên cứu đề tài này nhằm:
ã Hiểu và mô tả các nguyên tắc cơ bản về hớng đối tợng
ã Hiểu rõ về cách tiếp cận hớng đối tợng trong việc PTTKHT phần mềm
ã Nắm đợc khái quát về UML qua việc thực hành trên môi trờng Rational Rose
ã Vận dụng UML vào việc PTTKHT Bất động sản nhà ở
ã Có đợc khả năng sử dụng công cụ UML để giải quyết các vấn đề thực tế.
4. Đối tợng nghiên cứu và khách thể nghiên cứu
4.1. Khách thể nghiên cứu
Phơng pháp PTTKHT hớng đối tợng bằng UML & Rational Rose
4.2. Đối tợng nghiên cứu
PTTKHT Bất động sản nhà ở bằng UML thực hành trên Rational Rose.
5. Nhiệm vụ nghiên cứu
ã
ã

Tìm hiểu cơ sở lý luận của vấn đề nghiên cứu.
Khảo sát quy trình hoạt động của HT Bất động sản nhà ở qua thực tế và phần
trình bày của các tài liệu liên quan.
ã Phân tích hệ thống bằng việc mô hình hoá hành vi của hệ thống qua các Use-case
và đa ra các biểu đồ hoạt động, biểu đồ trờng hợp sử dụng của hệ thống.
ã Thiết kế hệ thống là việc đa ra các biểu đồ tơng tác của hệ thống, tìm kiếm các
lớp, các đối tợng.
ã Cài đặt hệ thống bằng ngôn ngữ Visual Basic.
6. Giới hạn phạm vi nghiên cứu

Trong khuôn khổ của một luận văn tốt nghiệp, đề tài chỉ dừng lại ở việc mô tả
hệ thống phần mềm, chủ yếu nghiêng về lý luận còn việc áp dụng thành công cho
một HT phần mềm thực sự cần phải có thời gian lâu dài và sự đầu t thoả đáng về.
7. Phơng pháp nghiên cứu
Khi làm đề tài này tôi đà sử dụng kết hợp các phơng pháp sau:
7.1. Phơng pháp lý thuyết
Tổng kết các tài liệu bằng tiếng anh và tiếng việt có liên quan đến đề tài
7.2. Phơng pháp thực hành
ã Khảo sát, tìm hiểu thực tế về hệ thống cần mô hình hoá
ã Tham khảo ý kiến của những ngời có kinh nghiệm về vấn đề đang nghiên cứu
ã Thực hành những gì đọc đợc từ tài liệu trên môi trờng Rational Rose .
-7-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Phần II. Phân tích thiết kế hệ thống hớng đối tợng bằng UML
(Thực hành trên Rational Rose)
Chơng 1. Giới thiệu công nghệ đối tợng và PTTKHT hớng đối tợng
1.1.

Công nghệ đối tợng (Object Technique- OT)

1.1.1. Công nghệ đối tợng là gì ?
Công nghệ đối tợng là một tập các nguyên tắc chỉ đạo xây dựng phần mềm
cùng với các ngôn ngữ, các cơ sở dữ liệu và các công cụ khác trợ giúp những
nguyên tắc đó (Công nghệ đối tợng - Một hớng chủ đạo của ngời quản lý, Taylor,
1997).
1.1.2. Công nghệ đối tợng đợc sử dụng trong những lĩnh vực nào ?
a. Các hệ thống khách chủ và sự phát triển Web
Công nghệ đối tợng cho phép các công ty tách thông tin công việc của họ

thành các đối tợng và giúp họ chuyển giao quá trình xử lý công việc qua internet hoặc
network.
b. Các hệ thống thời gian thực (real-time system)
OT làm cho các hệ thống thời gian thực phát triển với chất lợng và sự uyển
chuyển cao hơn trớc rất nhiều.
OT đang đợc sử dụng rộng rÃi trong những ngành công nghiệp và trong các ứng
dụng phần mềm sau đây:
ã Các hệ thống chuyển mạch vòng - viễn thông, các hệ thống Radio, các hệ
thống truyền thông, các hệ thống vệ tinh nhân tạo, việc quản lý lỗi, việc điều
khiển sự kết nối và việc phát triển các giao thức mạng.
ã Các hệ thống điều khiển và làm chủ bầu khí quyển, các hệ thống điều khiển
tên lửa, các hệ thống điều khiển nơi xảy ra chiến tranh, việc quản lý nút, quản
lý lỗi và trong việc phát triển giao thức.
ã Các cơ quan điều khiển công nghiệp, các hệ thống điều khiển nhà máy, những
máy in với tốc độ xử lý đa nhiệm cao, các hệ thống tự động, sự định vị giải
thông, điều khiển vị trí máy móc,...
1.1.3. Sức mạnh của công nghệ đối tợng
Các mô hình đợc tạo ra nhờ sử dụng công nghệ đối tợng có những u điểm nổi
bật so với phơng pháp truyền thống, cu thể là:
ã OT tạo ra một mô hình PTTK đơn giản, gần gũi và dễ hiểu. UML tợng trng
cho sự hội tụ của nguyên tắc tốt nhất này trong toàn bộ lĩnh vực công nghệ đối tợng. UML là một ngôn ngữ gần gũi đợc ¸p dơng cho c¶ hƯ thèng lÉn kü s t¸c
nghiƯp (business engineering). Một ngôn ngữ đơn giản đợc dùng bởi những ngời
sử dụng, những ngời phân tích, những ngời thiết kế và những ngời cài đặt.
ã Tiện lợi cho việc tái sử dụng mà và kiểu kiến trúc: Bằng việc khớp nối các
thành phần chính và các giao diện phản ánh các thành phần đó. Một kiến trúc xây
dựng theo OT cho phép ta lý giải về việc tái sử dơng. §ång thêi, nã cịng cho phÐp
-8-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose

ta tái sử dụng trên một quy mô rộng hơn, đó là việc tái sử dụng chính bản thân
kiến trúc.
ã Các mô hình phản ánh thế giới thực một cách gần gũi: Các mô hình giúp ta mô
tả một cách chính xác hơn các thực thể trong thế giới thực, dễ hiểu và dễ bảo trì
hơn. Một mô hình hớng đối tợng nhằm vào việc phản ánh thế giới chúng ta đà trải
qua trong thực tế. Tuy nhiên, tự thân các đối tợng thờng tơng xứng với hiện tợng
trong thế giới thực. Ví dụ: Một đối tợng có thể là một hoá đơn trong hệ thống tác
nghiệp hoặc một ngời làm việc trong hệ thống trả tiền.
ã Khả năng bền vững: Một sự thay đổi nhỏ trong các yêu cầu không làm ảnh hởng
to lớn đến sự phát triển của hệ thống.
ã Thích nghi với sự thay đổi: OT giúp một cơ quan thay đổi hầu hết hệ thống của
họ nhanh tơng đơng nh tự thân các thay đổi thực tế của cơ quan.
1.2.

Một số khái niệm cơ bản liên quan đến vấn đề nghiên cứu

1.2.1. Phơng pháp (method)
Phơng pháp (hay phơng thức) là cách thức cấu trúc các suy nghĩ và hành động
của con ngời. Nó cho biết chúng ta phải làm gì, làm nh thế nào, làm khi nào và tại sao
phải làm nh vậy để hình thành hệ thống phần mềm.
1.2.2.Đối tợng (object)
Theo nghĩa thông thờng thì đối tợng là ngời, vật hay hiện tợng mà con ngời
nhằm vào trong suy nghĩ, trong hành động; là bất kỳ cái gì nhìn thấy và sờ mó đợc.
Một đối tợng có thể đợc cấu tạo từ nhiều đối tợng khác.
Theo quan điểm của lập trình hớng đối tợng thì đối tợng là biến của kiểu dữ
liệu (đợc định nghĩa bởi lớp). Đối tợng là những thực thể, khi chơng trình chạy đối tợng sử dụng bộ nhớ cho việc trình bày nội tại của mình. Quan hệ giữa đối tợng và lớp
giống nh quan hệ giữa kiểu và biến trong lập trình cấu trúc.
Trong PTTKHT hớng đối tợng thì đối tợng là sự trừu tợng cái gì đó trong lĩnh
vực vấn đề hay trong cài đặt của nó; phản ánh khả năng hệ thống lu giữ thông tin về
nó và tơng tác với nó; gói các giá trị thuộc tính và các dịch vụ (phơng thức, phơng

pháp).
1.2.3. Lớp (class)
Theo định nghĩa thông thờng lớp là nhóm của nhiều ngời hay vật có tính tợng
trng nhất định hay đặc ®iĨm chung (tõ ®iĨn Webster’s).
Theo quan ®iĨm cđa lËp tr×nh hớng đối tợng: Lớp là kiểu dữ liệu đợc định nghÜa
bëi ngêi sư dơng. Mét líp gåm cã d÷ liƯu (thuộc tính) và các phơng thức hay một số
thao tác (hành vi), cụ thể là các hàm hoặc thủ tục đợc mô tả những tính năng chung và
hành vi của nhiều đối tợng tơng tự.
Trong phơng pháp hớng đối tợng : Lớp là sự mô tả một tập hợp các đối tợng,
cái mà có cùng chung: các thuộc tính, các sự hoạt động (các phơng thức), các mối
quan hệ và các ngữ nghĩa.
-9-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Một đối tợng là một trờng hợp cụ thể của lớp.
1.2.4. Trừu tợng (abstract)
Là nguyên tắc bỏ qua những khía cạnh của chủ thể không liên quan đến mục
đích hiện tại để tập trung đầy đủ hơn vào các khía cạnh còn lại. Nh vậy có thể nói trừu
tợng là đơn giản hoá thế giới thực một cách thông minh. Trừu tợng cho khả năng khái
quát hoá và ý tởng hoá vấn đề đang xét, loại bỏ các chi tiết d thừa, chỉ tập trung vào
các điểm chính, cơ bản.
1.2.5. Sự trừu tợng hoá (abstraction)
Là các đặc trng bản chất của một thực thể để phân biệt nó với tất cả các loại
thực thể khác. Vì vậy nó cung cấp những đờng biên có liên liên quan đến góc nhìn
của ngời quan sát.
1.2.6. Mô hình (model)
Theo Grady Booch, một mô hình cung cấp kế hoạch chi tiết của hệ thống, nó
giúp ta lập các dự định trớc khi xây dựng hệ thống. Mọi hệ thống có thể đợc mô tả từ
các khía cạnh khác nhau nhờ sử dụng các mô hình khác nhau và mỗi mô hình do đó là

một sự trừu tợng gần gũi về mặt ngữ nghĩa của hệ thống. Một mô hình có thể có cấu
trúc, lµm nỉi bËt sù tỉ chøc cđa hƯ thèng, mét mô hình có thể có hành vi làm nổi bât
sự vận động của hệ thống .
Mô hình giúp ta khẳng định tính đúng đắn của pha thiết kế phù hợp với yêu
cầu, hệ thống vẫn giữ vững khi yêu cầu ngời dùng thay đổi.
Vậy mô hình là hình ảnh thực tại của hệ thống đợc viết dới một hình thức mà
ta hiểu đợc nh: văn bản, đồ thị, phơng trình,....
Mô hình là một bức tranh (hay là một sự mô tả) của vấn đề đang đợc cố gắng
giải quyết hay biểu diễn.
Mô hình chỉ lựa chọn một số khía cạnh cã ý nghÜa cho viƯc thùc hiƯn c«ng
viƯc cơ thĨ nào đó, chứ không phải tất cả mọi khía cạnh đều đợc đa vào mô hình.
1.2.7. Mô hình hoá (modeling)
Mô hình hoá là đơn giản hoá thế giới phức tạp, thu gom không gian rộng
lớn, rút ngắn thời gian vào trong mô hình, giúp con ngời có cái nhìn trực quan,
giải mà những gì cuộc sống đặt ra.
Mô hình hoá là việc phân tích và thiết kế hệ thống bằng việc sử dụng các mô
hình.
Mô hình hoá còn có thể là mô tả chính giải pháp, chẳng hạn nh: Công việc xây
dựng một ngôi nhà không đơn giản là mua nguyên vật liệu đầy đủ mà phải lập kế
hoạch chi tiết và thiết kế trớc, công việc đó chính là mô hình hoá.
Phơng pháp hớng đối tợng xem một phần của thế giới thực nh các đối tợng.
Máy điện thoại, xe ô tô, con ngời,... là các đối tợng. Các đối tợng này lại bao gồm
nhiều đối tợng khác nh con ngời có tay, chân, mắt,..; ô tô có bánh xe, tay l¸i,... Trong

-10-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
cuộc sống hàng ngày ta đơn giản hoá đối tợng khi suy nghĩ, đó chính là công việc mô
hình hoá.

Lý do cơ bản để mô hình hoá hệ thống là: Xây dựng mô hình để hiểu sâu sắc
hơn về hệ thống đang đợc xây dựng. Chúng ta xây dựng mô hình cho các hệ thống
phức tạp vì chúng ta không thể hiểu nó một cách tổng thể nh vốn có đợc.
1.2.8. Phơng pháp luận (methodology)
Mô tả cách thức suy nghĩ về phần mềm và phát triển phần mềm. Nó bao gồm
ngôn ngữ mô hình hoá, mô hình của mô hình (metamodel) và tiến trình. Phơng pháp
luận khác với phơng pháp, phơng pháp luận là nghiên cứu phơng pháp, mô tả hình
thức các phần tử mô hình, cú pháp, ngữ nghĩa của các ký pháp trong mô hình.
1.2.9. Lĩnh vực vấn đề (domain problem)
Mục tiêu của tiếp cận hớng đối tợng là mô hình hoá các đặc tính tĩnh và động
của môi trờng, nơi xác định yêu cầu phần mềm. Môi trờng này đợc gọi là lĩnh vực vấn
đề. Vấn đề là câu hỏi đợc đặt ra để xem xét giải quyết. Lĩnh vực là không gian (vùng)
của các hoạt động hoặc ảnh hởng. Nó là vùng tác nghiệp ( Bussiness domain) hoặc
kinh nghiệm của con ngời trong đó phần mềm đợc sử dụng. Vậy lĩnh vực vấn đề là
vùng ta đang cố gắng xem xét để xây dựng hệ thống phần mềm. Ví dụ nh: lĩnh vực tài
chính, giáo dục, công nghiệp,...
1.2.10. Phân tích (analysis)
Thông thờng phân tích là tách, chia tổng thể thành các phần nhỏ để tìm ra đặc
tính, chức năng, quan hệ,... của chúng (từ điển Websters).
Khái niệm phân tích trong tiếp cận hớng đối tợng là thực hiện nghiên cứu lĩnh
vực vấn đề, dẫn tới đặc tả hành vi quan sát từ ngoài và các thông báo nhất quán, hoàn
chỉnh, khả thi của những cái cần thiết cho hệ thống .
Phân tích là một phần của tiến trình phát triển phần mềm, mục đích căn bản của
phân tích là thành lập một mô hình của lĩnh vực vấn đề. Phân tích tập trung vào trả lời
câu hỏi làm cái gì ? . Thiết kế tập trung vào trả lời câu hỏi làm nh thế nào ?
Phân tích hệ thống là mô tả các đối tợng của hệ thống ở mức logic.
Vídụ : Phân tích hệ thống bất động sản nhà ở là tìm ra các actor và các usecase; sau đó mô tả hệ thống làm gì bằng các biểu đồ trờng hợp sử dụng (use case
diagram ) và biểu đồ hoạt động (activity diagram).
1.2.11. Lớp phân tích (Analysis Class)
Lớp phân tích điều khiển các yêu cầu chủ yếu về mặt chức năng và mô hình các

đối tợng từ lĩnh vực vấn đề.
1.2.12. Thiết kế (design)
Thông thờng thiết kế là kỹ thuật lập tài liệu toàn bộ, gồm có bản tính toán, bản
vẽ,... để có thể theo đó mà xây dựng công trình, sản xuất thiết bị, làm sản phẩm,...

-11-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Trong tiếp cận hớng đối tợng: Thiết kế là thực hiện đặc tả các hành vi bên
ngoài, bổ sung chi tiết nếu cần thiết để cài đặt hệ thống trên máy tính, bao gồm tơng
tác ngời-máy, quản lý nhiệm vụ, quản lý dữ liệu. Thiết kế hớng đối tợng tập trung vào
xác định đối tợng phần mềm logic sẽ đợc cài đặt bằng ngôn ngữ hớng đối tợng.
Thiết kế là một phần của tiến trình phát triển phần mềm, mục đích căn bản của
thiết kế là xác định hệ thống đợc thực hiện nh thế nào. Trong suốt quá trình thiết kế sự
quyết định của chiến lợc và chiến thuật đợc tạo ra để đáp ứng các yêu cầu về chức
năng và chất lợng của một hệ thống.
Nh vậy thiết kế hệ thống là nhận thức và mô tả hƯ thèng ë møc vËt lý
VÝ dơ: ThiÕt kÕ hƯ thống bất động sản nhà ở là: Tạo ra các lợc đồ tơng tác để
phản ánh hệ thống thực hiện nh thế nào?
1.2.13. Mô hình thiết kế (Design Model)
Là một mô hình đối tợng đợc mô tả bằng các sự thực hiện UC, nó nh là một sự
trừu tợng hoá của mô hình thực hiện và mà nguồn của nó.

1.2.14. Lập trình hớng đối tợng (Object Oriented Programming- OOP)
Một chơng trình hớng đối tợng đợc thiết kế xoay quanh các dữ liệu mà ta làm
việc trên đó hơn là theo bản thân chức năng của chơng trình. Chúng liên kết dữ liệu
với các thao tác, gán một số các hành động cụ thể với một loại đối tợng nào đó và đặt
các giả thiết của mình trên các liên hệ đó, các khái niệm trừu tợng để sử dụng trong
các chơng trình máy tính.

1.2.15. Tác nhân ngoài (actor)
Là ngời hoặc vật hoặc tác nghiệp hay hệ thống khác ở bên ngoài tơng tác với hệ
thống hoặc tác nghiệp của chúng ta.
1.2.16. Kiến trúc (architecture)
Là thành phần ở mức cao nhất cđa mét hƯ thèng trong m«i trêng cđa nã. KiÕn
tróc của một hệ thống phần mềm (vào đúng lúc quy định) là sự tổ chức của nó hoặc là
cấu trúc của các thành phần quan trọng đang tơng tác qua các giao diện, các thành
phần đó đang đợc tạo ra một cách liên tục từ các thành phần và các giao diƯn nhá h¬n.
-12-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
1.2.17. Bản tin (massage)
Bản tin hay còn gọi là thông điệp là một đặc tả của một sự truyền thông giữa
các đối tợng, nó chuyên chở thông tin với mong muốn rằng hoạt động sẽ xảy ra ngay
sau đó.
1.2.18. Multiplicity (số lợng liên kết)
Multiplicity tính nhiều của quan hệ cho biết bao nhiêu hiện thực (trờng hợp
cá biệt) của líp cã quan hƯ víi mét hiƯn thùc cđa líp khác. Khái niệm bao nhiêu đợc gọi là multiplicity của một vai trò của kết hợp.
Class1
<<entity>>
Professor

class2
0..1

instructor

0..*

<<entity>>
CourseOffering

Multiplicity
Hình trên: Mỗi một giáo s đại học có thể có nhiều khoá học đề nghị dạy. Mỗi
khoá học có thể có một hoặc không có giáo s nào nh là ngời giới thiệu.
Multiplicity phải đợc xác định trên hai đầu mút của sự liên kết. Multiplicity đợc chỉ ra bởi một biểu thức. Biểu thức là một dÃy số nguyên.
Tính nhiều

ý nghĩa

n
1
0..n
1..n
0..1
5..8
4..7,9
0..*

n trờng hợp cá biệt
Chỉ một trờng hợp cá biệt
Từ không đến n các trờng hợp cá biệt
Từ một đến n các trờng hợp cá biệt
Không hoặc một trờng hợp cá biệt
Chỉ ra d·y (5,6,7 hc 8)
ChØ ra d·y (4,5,6,7 hc 9)
ChØ ra dÃy từ không đến nhiều

Multiplicity trả lời cho hai câu hỏi: Sự liên kết có tính chất bắt buộc hay tuỳ

chọn? Số lớn nhất và bé nhất của các trờng hợp cá biệt có thể liên kết với một trờng
hợp là gì? Nó có thể đợc liên kết tới các trờng hợp cá biệt khác không? Nhiều khi
chúng ta không biết đợc số lớn nhất của các trờng hợp cá biệt, khi đó ta phải sử dụng
* để chỉ ra rằng con số này không biết đợc cụ thể.
1.2.19. Tính chất (property)
Là một giá trị đà đợc xác định tên biểu thị một đặc tính của một thành phần.
1.2.20. Thuộc tính (attribute)
Một thuộc tính là một đặc tính đợc đặt tên, có một kiểu xác định, các kiểu chủ
yếu là: nguyªn, logic, thùc, liƯt kª...

-13-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Một cách nói đơn giản, thuộc tính mô tả đối tợng. Mỗi đối tợng đều có một bộ
thuộc tính mô tả nó. Mặc dù một đối tợng có một bộ thuộc tính khác nhau, nhng trong
đó vẫn có một số thuộc tính thông dụng cho hầu hết các điều khiĨn.
1.2.21. Sù thùc hiƯn trêng hỵp sư dung (use- case realization)
Một sự thực hiện UC mô tả cách thức một UC cụ thể đợc thực hiện bên trong
mô hình thiết kế, trong nhóm của các đối tợng cộng tác. Mô hình thiết kế bao gồm:
các biểu đồ tuần tự, các biểu đồ cộng tác, các biểu đồ lớp. Mô hình trờng hợp sử dụng
bao gồm các UC và các actor.
Use-case Model

Design Model

Use Case

Use-case Realization

ứng với mỗi một UC trong mô hình UC, có một sự thực hiện UC trong mô hình
thiết kế và độc lập với UC.
Với mỗi một sự thực hiện UC có thể có một hoặc nhiều hơn các biểu đồ lớp.
Các lớp này gọi là View of Participating Class (VOPC). Mỗi một sự thực hiện UC
có thể có một hoặc nhiều hơn các biểu đồ tơng tác chỉ rõ việc phân chia các đối tợng
và các tơng tác của chúng. Nhìn thấy các biểu đồ tuần tự và cộng tác cho một sự mô
tả các biểu đồ đó.
1.2.22. Vật phẩm (artifact)
Vật phẩm là các tài liệu, các mô hình hoặc các thành phần mô hình sử dụng để
nắm giữ và vận chuyển thông tin của dự án. Các vật phẩm có thể gồm cả vật phẩm
đầu vào và vật phảm đầu ra phụ thuộc vào sự hoạt động.
1.3. Các nguyên tắc hớng đối tợng (oriented object-OO)
1.3.1. Một đối tợng là gì ?
Một cách thông thờng một đối tợng tợng trng cho một thực thể hoặc về mặt vật
lý, hoặc về mặt quan niệm, hoặc về mặt phần mềm.
Ví dụ:
ã Thực thể vật lý : Một xe tải, một ngời, một tên lửa,...
ã Thực thể quan niệm: Một quá trình phản ứng hoá học, các thuật giải,...
ã Thực thể phần mềm: Danh sách liên kết,stack,...
Các đối tợng cho phép ngời phát triển phần mềm biểu diễn các quan niệm thế
giới thực trong bản thiết kế phần mềm của hä. Quan niƯm thÕ giíi thùc cã thĨ tỵng trng cho mét thùc thĨ vËt lý, mét quan niƯm thËm chí có thể tợng trng cho các thực thể
phần mềm.
1.3.2. Sự xác định một đối tợng
Một đối tợng có hai thành phần chính: Các thuộc tính và các phơng thức.
ã Các thuộc tính tợng trng cho trạng thái của đối tỵng.
-14-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
ã Các phơng thức tợng trng cho hành vi của đối tợng.

1.3.3. Trạng thái của đối tợng
Là một trong các điều kiện để một đối tợng có thể tồn tại bên trong và nó thờng
thay đổi theo thời gian.
Trạng thái của một đối tợng thờng đợc cài đặt bởi một tập các tính chất
(Properties) đợc gọi là các thuộc tính (attributes) cùng với các giá trị của các tính chất
và các liên kết của đối tợng có thể có với các đối tợng khác.
Ví dụ: Nếu giáo s A thay đổi từ đơng chức tới về hu, trạng thái của đối tợng
giáo s A sẽ thay đổi.
1.3.4. Hành vi của một đối tợng
Chỉ rõ một đối tợng kích hoạt và tác động trở lại nh thế nào với yêu cầu từ các
đối tợng khác. Hành vi thấy đợc của một đối tợng đợc mô hình hoá bởi tập các bản tin
(message) trả lời các hoạt động của đối tợng có thể thực hiện. Hành vi đối tợng đợc tợng trng bởi những hoạt động mà hệ thống có thể thực hiện. Tập các hành vi của đối
tợng chính là phơng thức hoạt động của lớp. Phơng thức trong một lớp mô tả cái mà
lớp đó phải làm. Phơng thức có thể là một lệnh hoặc một câu hỏi. Một câu hỏi không
làm thay đổi trạng thái của đối tợng chỉ có câu lệnh mới có thể thay đổi trạng thái của
đối tợng. Kết quả của phơng thức phụ thuộc vào trạng thái hiện hành của đối tợng.
Thờng thì nh vậy, nhng không phải lúc nào cũng thế. Mức độ khẩn cấp của một phơng
thức trên một đối tợng làm thay đổi dữ liệu hay trạng thái của đối tợng.
1.3.5. Đặc trng của một đối tợng
Mỗi đối tợng có một đặc trng riêng biệt, ngay cả khi trạng thái giống hệt với
trạng thái của đối tợng khác.
Trong thế giới thực hai ngời có thể có cùng các đặc tính giống nhau: tên, ngày
sinh, sự mô tả công tác,...Tuy nhiên, họ vẫn là hai cá nhân riêng biệt với một cá tính
duy nhất. Thành phần giống nhau nắm giữ tính đúng đắn cho đối tợng.
1.3.6.Các nguyên tắc cơ bản của hớng đối tợng (OO)
Gồm 4 nguyên tắc cơ bản: Sự trừu tợng hoá, sự đóng kín, sự đơn thể hoá và hệ
thống cấp bậc (hay còn gọi là tính kế thừa).
a. Sự trừu tợng hoá (abstraction)
Bất cứ một mô hình nào cũng bao gồm các khía cạnh quan trọng, thiết yếu
hoặc riêng biệt về một cái gì đó, trong khi lại che dấu hoặc lờ đi những chi tiết có ít

tầm quan trọng nhất, các chi tiết vô hình nhất hoặc tiêu khiển nhất. Vì thế kết quả của
những sự phân biệt đợc chuyển đổi nh là để nhấn mạnh sự chung chung nhất.
Sự trừu tợng cho phép ta quản lý sự phức tạp bằng việc tập trung vào các đặc
trng bản chất của một thực thể, các đặc trng này phân biệt nó với tất cả các loại thực
thể khác.
Hớng đối tợng cho phép chúng ta mô hình hoá hệ thèng cđa chóng ta b»ng
viƯc sư dơng c¸c sù trõu tợng từ lĩnh vực vấn đề (ví dụ: các lớp và các đối tợng).
-15-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Ví dụ về sự trừu tợng hoá:
ã Sinh viên là những ngời đà ghi tên vào danh sách lớp học ở trờng đại học
ã Giảng viên là những ngời dạy các lớp học ở trờng đại học.
b. Sự đóng kín (encapsulation)
Tính đóng kín còn gọi là che dấu thông tin. Nguyên tắc này dựa trên nền tảng
là mỗi thành phần của chơng trình đợc bao bọc hay che dấu đi các quyết định thiết kế
đơn lẻ. Giao diện tới mỗi modul đợc hình thành sao cho ít nhìn thấy các công việc bên
trong.
Đóng kín là sự định vị vật lý của các đặc điểm (các tính chất và hành vi) bên
trong một sự trừu tợng, đóng kín là giấu ®i sù thùc hiƯn cđa chóng.
§iĨm then chèt ®Ĩ ®ãng kín là giao diện quản lý đối tợng. Giao diện đối tợng
phải đảm bảo rằng tất cả sự liên lạc với đối tợng phải xuyên suốt một tập các hoạt
động đà xác định trớc. Dữ liệu bên trong đối tợng chỉ có thể truy nhập bởi những hoạt
động của đối tợng đó. Đối tợng khác không thể truy nhập vào bên trong đối tợng và
không thể thay đổi các giá trị thuộc tính của nó.
c. Sự đơn thể hoá- chia nhỏ (modularity)
Sự đơn thể hoá là việc phân rà cái gì đó phức tạp thành những mẫu quản lý đợc
hay còn gọi là sự phân rà về mặt vật lý và logic của những sự vật (ví dụ: Những trách
nhiệm và phần mềm ) thành những nhóm nhỏ, đơn giản (ví dụ : Các yêu cầu, các lớp,

từng phần riêng) nhằm tăng dần mục đích đạt tới của công nghệ phần mềm.
Sự đơn thể hoá là cách quản lý độ phức tạp và bẻ gÃy cái gì đó rộng lớn và phức
tạp thành những tập nhỏ hơn, những mẫu quản lý tốt hơn. Các mẫu này sau đó có thể
độc lập phát triển, các sự tơng tác giữa chúng đợc hiểu một cách rõ ràng.
Trong UML các gói tin (package) trợ giúp việc đơn thể hoá.
Thông thờng hệ thống đang phát triển là quá phức tạp để hiểu đợc. Để hiểu hệ
thống tốt hơn, hệ thống phải đợc bẻ gÃy thành các khối nhỏ hơn, mỗi khối đó đợc duy
trì một cách độc lập. Sự phân tích hệ thống theo cách này đợc gọi là sự đơn thể hoá.
Nguyên tắc nµy rÊt tèt cho viƯc hiĨu mét hƯ thèng phøc tạp.
Ví dụ: hệ thống đăng kí khoá học: bản thân hệ thống là quá lớn và quá trừu
tợng để hiểu đợc hết các chi tiết. Vì thế, nhóm phát triển bẻ gÃy hệ thống thành 3 hệ
thống đơn thể, mỗi hệ thống độc lập với các hệ thống khác: Hệ thống ghi hoá đơn, hệ
thống nhập khoá học, hệ thống quản lý sinh viên.
d. Hệ thống cấp bậc hay tính kÕ thõa (hierarchy)
BÊt cø mét sù s¾p xÕp hay mét thứ tự nào của những sự trừu tợng bên trong một
cây cấu trúc cũng đều có các loại phân cấp lớp sau đây: phân cấp lớp theo tập hợp,
phân cấp líp theo néi dung, ph©n cÊp líp theo tÝnh kÕ thừa, phân cấp lớp theo từng
phần, phân cấp lớp theo sự đặc biệt hoá, phân cấp lớp theo kiểu.
Phân cấp líp tỉ chøc trong mét thø tù hc mét sù sắp xếp đặc biệt, ví dụ: sự
phức tạp, trách nhiệm,... Sự tổ chức này phụ thuộc vào góc nhìn (phối cảch). Việc sử
dụng một phân cấp lớp để mô tả những sự khác nhau hoặc sự đa dạng của một kh¸i
-16-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
niệm đặc biệt nhằm làm cho những sự trừu tợng dính kết hơn, mô tả đợc nhiều hơn và
một sự định vị trách nhiệm đợc tốt hơn.
Trong bất cứ mét hƯ thèng nµo cịng cã thĨ cã nhiỊu sù phân cấp trừu tợng. Ví
dụ một ứng dụng về lĩnh vực tài chính có thể có nhiều kiểu khách hàng và nhiều kiểu
tính toán khác nhau).

Sự phân cấp lớp không phải là một biểu đồ tổ chức cũng không phải là một sự
phân biệt về chức năng. Sự phân cấp lớp là một sự tổ chức về nguyên tắc phân loại.
Sử dụng sự phân cấp lớp làm cho chúng ta dễ dàng tổ chức sự giống nhau và khác
nhau.
Ví dụ: Thực vật học tổ chức các thực vật thành các loài; Hoá học tổ chức các
nguyên tử trong bảng tuần hoàn các nguyên tố hoá học của Mendelep.
1.4. Công việc PTTKHT
Công việc PTTKHT tiến hành trên bốn phơng diện sau: chức năng, dữ liệu,
động thái (trạng thái hoạt động) và kiến trúc.
+> Theo phơng pháp hớng chức năng: Công việc PTTKHT lấy chức năng làm
trục chính và tiến trình phân tích đợc thực hiện từ trên xuống dới có cấu trúc, nh đợc
minh họa ở hình sau đây:
Chức năng chính

Chức năng con 1

Chức năng con i

.. .. ..

Chức năng con n

......

.....

Hình 1.4.a. Tiếp cận mô hình hớng chức năng
+> Theo phơng pháp hớng đối tợng: Dữ liệu, chức năng, động thái đợc hợp
nhất, gắn kết lại trong khái niệm đối tợng, sử dụng mô hình các lớp làm trục chính,
mô hình này tạo thành cái nền trên đó diễn tả mọi hoạt động của đối tợng. Trong phơng pháp này chú ý thích đáng tới động thái .

Ví dụ: Trong mô hình ở (hình 1.4) dới đây: cửa, phòng thang máy, đèn, công
tác: là các đối tợng; các đối tợng này quan hệ với đối tợng của hệ thống thang máy
Mở
Phòng thang máy
Cửa
Lên tầng 2
đèn

Bật đèn

Công tác

Hình 1.4. Tiếp cận mô hình hớng đối tợng
-17-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Quan điểm hớng đối tợng hình thành trên cơ së tiÕp cËn hÖ thèng, nã coi hÖ
thèng nh thùc thể đợc tổ chức từ các thành phần mà chỉ đợc xác định khi nó thừa nhận
và có quan hệ với các thành phần khác. Phơng pháp này không chỉ dựa trên cơ sở hệ
thống làm cái gì mà còn dựa trên việc tích hợp hệ thống là cái gì và hệ thống làm
gì
Theo cách này thì chức năng của hệ thống đợc biểu diễn thông qua cộng tác
của các đối tợng; việc thay đổi, tiến hoá chức năng sẽ không ảnh hởng đến cấu trúc
tĩnh phần mềm. Sức mạnh của tiếp cận hớng đối tợng là việc tách (chia) và nhập
(thống nhất) đợc thực hiện nhờ những khả năng nổi bật sau :
+ > Tính ổn định của đối tợng tạo ra khả năng dùng lại đợc, mở rộng đợc
+ > Tính đóng kín của đối tợng tạo nên khả năng dễ sửa đổi, dễ bảo trì
+ > Tính nhất quán trong mô hình từ phân tích, thiết kế, lập trình đều sử dụng
một biểu diễn thống nhất bằng đối tợng

1.5. Giới thiệu các phơng pháp mô hình hoá hệ thống phần mềm
Khi bắt tay vào công việc phát triển phần mềm, lúc đầu ta có thể không biết về
mọi thứ. Một sự thiết kế ban đầu sẽ gần nh không đợc hoàn thiện, các yêu cầu chính
của hệ thống cha đợc chú ý thích đáng, ở giai đoạn cuối mới phát hiện ra những thiếu
sót trong quá trình thiết kế. Đó là tai hại có thể dẫn đến phải huỷ bỏ dự án. Trong khi
đó thời gian và tiỊn chi phÝ cho viƯc thùc hiƯn mét thiÕt kÕ có lỗi là không thể nào lấy
lại đợc. Với sự phức tạp của hệ thống đang đợc xây dựng, không có tiến trình hoặc phơng pháp luận nào sẽ đảm bảo rằng một sự thiết kế ban đầu là hoàn toàn đúng đắn bởi
tất cả các yêu cầu không đợc biết từ đầu, các yêu cầu đó có thể đợc biết một cách
nhập nhằng hoặc có một số lỗi đơn giản. Một số yêu cầu lúc đầu đúng đắn sau đó lại
trở nên lạc hậu vì lĩnh vực vấn đề hoặc tình trạng cạnh tranh luôn thay đổi trong
suốt quá trình phát triển.
Với thực tế nh vậy, phát triển phần mềm có thể đợc thực hiện bằng nhiều on đờng khác nhau. Các dự án có thể tuân theo các tiến trình phát triển sau đây:
1.5.1. Phơng pháp phát triển phần mềm theo mô hình thác nớc
Phơng pháp này đợc Royce mô tả năm 1970 ( hình 1.5.1). Trong mô hình này,
phát triển phần mềm là dÃy các pha liên tiếp từ phân tích yêu cầu, thiết kế hệ thống,
phát triển hệ thống đến thử nghiệm và triển khai hệ thống. Pha sau chỉ bắt đầu khi pha
trớc đà hoàn thành.
Theo phơng pháp này để xây dựng đợc hệ thống phần mềm ta phải mô tả đợc
vấn đề và xác định đợc các yêu cầu của khách hàng bằng cách trả lời các câu hỏi:
Vấn đề của hệ thống là gì ? và hệ thống cần làm gì? Pha phân tích của tiến trình tập
trung vào việc điều tra vấn đề thay vì việc phải tìm ra giải pháp cho vấn đề. Pha thiết
kế nhằm xác định kiến trúc của hệ thống, pha này tập trung vào những nhiệm vụ nh
cài đặt chơng trình ở đâu, cần phần cứng nào?.. Các tài lệu thiết kế đợc soạn thảo một
cách tỉ mỉ . Mà hoá chơng trình là cài đặt những modul đà thiết kế bằng ngôn ngữ lập
trình nào đó. Sau khi đà mà hoá xong, pha kiểm tra bắt đầu để phát hiện ra những yêu

-18-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose

cầu cha đủ chi tiết, giải thích nhầm lẫn,...Nh vậy mọi rủi ro chỉ đợc phát hiện khi đÃ
tốn rất nhiều thời gian và công sức.
+> Ưu điểm: Không phức tạp bởi vì nó đa ra một giải pháp có thể đơn giản.
+> Nhợc điểm: Một thiết kế ban đầu sẽ chắc chắn bị thếu sót bởi sự để tâm đến
các yêu cầu chính của nó là cha thoả đáng. Hơn nữa, sau khi thiết kế sẽ tìm ra các kết
quả có khuynh hớng dẫn tới sự huỷ bỏ dự án và/hoặc vợt qua rủi ro. Kiểu thác nớc gần
nh hớng tới sự che dấu những rủi ro thực sự của dự án cho đến khi nó quá chậm trễ để
làm bất cứ một cái gì khắc phục đợc những rủi ro đó nữa. Điều đó dễ dẫn tới một phần
mềm muộn màng, vợt quá ngân sách, dễ vỡ và đắt đỏ phải bảo trì 90% về thời gian.
Phân tích các yêu cầu
Thiết kế
Viết chơng trình
Tích hợp hệ thống con
Thử nghiệm hệ thống
Hình 1.5.1. Tiến trình thác nớc
1.5.2. Phơng pháp phát triển phần mềm theo mô hình lặp và tăng dần
Theo phơng pháp này: Bắt đầu dự án, xác định các yêu cầu của hệ thống thông
qua việc thảo luận với ngời sử dụng hệ thống và khảo sát hoạt động hệ thống. Dù cố
gắng đến mấy, thì ngời phát triển hệ thống cũng không thể xác định hết tất cả các yêu
cầu của hệ thống ngay từ đầu đợc. Tiếp theo là pha thiết kế, pha này tập trung vào
những nhiệm vụ đặt chơng trình ở đâu, cần phần cứng nào,... Trong khi thực hiện
công việc này, ta có thể tìm ra một số yêu cầu mới của hệ thống. Do đó, ta quay trở lại
ngời sử dụng để trao đổi, tức là ta phải quay trở lại pha phân tích. Sau đó tiếp tục lặp
lại quá trình trên: phân tích -> thiết kế -> mà hoá chơng trình, khi mà hoá chơng trình,
ta phát hiện ra một vài quyết định khi thiết kế không thể cài đặt đợc. Vậy ta phải trở
lại pha thiết kế xem xét lại các nhiệm vụ. Sau khi mà hoá xong đến tích hợp, đến đây
gặp phải khó khăn phát hiện ra những đơn vị mà hoá cha đúng phải quay lại pha mÃ
hoá để kiểm tra lại. Sau khi tích hợp, pha kiểm tra bắt đầu. Trong khi kiểm tra lại
nhận thấy một số yêu cầu cha đủ chi tiết, vậy ta phải quay lại pha phân tích để xem
xét yêu cầu và lặp lại quá trình trên. Sau mỗi lần lặp ta có một hệ thống hoàn chỉnh và

phân phát cho ngời sử dụng.
Lặp 1

Lặp 2

Phân tích các yêu cầu

Phân tích các yêu cầu

Thiết kế
Viết chơng trình

Lặp 3 ...

Thiết kế
Viết chơng trình
-19-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose

Tích hợp hệ thống con
Thử nghiệm hệ thống

Tích hợp hệ thống con
Thử nghiệm hệ thống

Hình 1.5.2.1. Tiến trình lặp và tăng dần
Với mỗi quá trình tái lập, các bớc trong tiến trình thác nớc đợc áp dụng một
cách lặp đi lặp lại . Một sự tăng dần là một tập con các chức năng của hệ thống đợc

lựa chọn và đợc phát triển, sau đó đến sự tăng dần khác,...ở lần lặp đầu tiên những rủi
ro cao nhất đợc u tiên.
+> Ưu điểm: Các rủi ro nghiêm trọng đợc giải quyết trớc khi tiến hành các đầu t
lớn cho sự phát triển. Sự tổng hợp và kiểm tra liên tục đảm bảo rằng: ở mọi sự tái lập,
tất cả các pha ăn khớp với nhau một cách chặt chẽ.
Với một phơng pháp phát triển lặp và tăng dần, hầu hết hệ thống đà đợc kiểm
tra đầy đủ rồi và có thể hoạt động đợc.
Một phơng pháp phát triển lặp và tăng dần: phân tích viên, ngời thiết kế, ngời
lập trình,... hợp tác làm việc để hiểu biết sâu sắc hệ thống, chia sẻ các ý tởng mới dẫn
tới xây dựng đợc hệ thống mạnh, phức tạp hơn (Hình 1.5.2.2).
+> Nhợc điểm: Ngời sử dụng có thể phàn nàn về sản phẩm làm ra không hoàn toàn
nh cái họ mong đợi. Nguyên nhân có thể là: Vấn đề tác nghiệp (Bussiness Problem)
thay đổi quá nhanh, ngời sử dụng không truyền đạt hết cái họ muốn, đội ngũ dự án
không tuân thủ tiến trình,...
Xác PT,TK,lập trình
định
Các Môi trờng Triển
yêu
Quản lý
khai
cầu
hoạch định
sự đánh giá
Hình 1.5.2.2. Mô hình lặp và tăng dần
1.5.3. Tiến trình hợp nhất Rational (RUP-Rational Unified Process )
RUP là một tiến trình công nghệ phần mềm cung cấp một cách tiếp cận có
khuôn khổ để phân bổ các nhiệm vụ và các trách nhiệm bên trong một tổ chức phát
triển. Mục đích của nó là đảm bảo sản phẩm phần mềm đạt chất lợng cao đến tay ngời
sử dụng cuối theo đúng ngân sách và thời hạn đà định trớc. Hình 1.5.3 là tổng quan
kiến trúc của RUP .

-20-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Hình 1.5.3. Sơ đồ các pha phát triển phần mềm

Chú thích: work flows: luồng công việc

Business modeling: mô hình hoá công việc (lập kế hoạch)
Requrements: công việc tìm các yêu cầu
Analysis & Design: phân tích và thiết kế
Implementation: cài đặt
Test: kiểm thử
Deployment: triển khai
Configuration&change Management:Quản lý thay đổi và cấu hình

Project Management: quản lý dự án
Environment: môi trờng phát triển
Elaboration: pha chi tiết
Inception:pha khảo sát tính khả thi
Construction: pha xây dựng;
Transition: pha chuyển giao
Initial: khởi tạo; Elab#1: lặp lần một

a. Cấu trúc tiến trình (các pha của chu kỳ sống): RUP gồm có 4 pha:
ã Pha khởi đầu (inception): xác định phạm vi của dự án.
ã Pha chi tiết (elaboration): lập kế hoạch cho dự án, chỉ rõ các đặc trng, lựa chọn
kiến trúc cơ sở.
ã Pha xây dựng (construction): xây dựng sản phẩm

ã Pha chuyển giao (transition): chuyển giao s¶n phÈm tíi ngêi sư dơng ci
a1> Pha khëi đầu (inception)
Pha này xây dựng phạm vi của dự án gồm cái gì và không gồm cái gì. Việc này
đợc thực hiện bằng cách nhận định tất cả các tác nhân ngoài và các trờng hợp sử dụng
và bằng cách phác thảo hầu hết các use-case cần thiết (chiếm 20% trong toàn bộ mô
hình). Một kế hoạch công việc đợc phát triển để xác định rõ nguồn tài nguyên nào nên
đợc đa vào dự án. Pha này còn đợc gọi là pha thăm dò rủi ro.
a2> Pha chi tiết (elaboration)
Tập trung vào hai việc: phân tích các yêu cầu (đạt đợc 80% trong tổng số yêu
cầu) và thành lập một cơ sở kiến trúc (mô hình hoá lĩnh vực vấn đề). Nếu chúng ta
nắm bắt tốt các yêu cầu và kiến trúc, chúng ta có thể loại trừ đợc nhiều rđi ro vµ sÏ cã
mét ý tëng tèt vỊ toµn bộ công việc phải làm. ở giai đoạn cuối cùng cña pha chi tiÕt,

-21-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
chúng ta có thể định lợng giá thành trong pha chi tiết. Pha này còn gọi là giai đoạn
giải qut rđi ro.
a3> Pha x©y dùng (construction)
Chóng ta x©y dùng sản phảm trong nhiều sự tái lập. Pha này kết thúc khi hoàn
thiện phần mềm và đợc kiểm nghiệm với điều kiện phần mềm phải đồng bộ với mô
hình. Pha này chiếm thời gian và công sức nhiều nhất. Đây còn gọi là pha quản lý rủi
ro đà điều khiển.
a4> Pha chun giao (transition)
Chóng ta chun giao s¶n phÈm tíi ngêi sư dơng ci vµ tËp trung vµo viƯc
hn lun, cài đặt, hỗ trợ kỹ thuật và bảo trì
Nh vậy, tổng số thời gian trải qua trong mỗi pha là khác nhau. Một dự án có thể
hoàn thành với nhiều sự không hiểu rõ về kỹ thuật và các yêu cầu không rõ ràng. Pha
chi tiết có thể gồm 3->5 lần lặp. Một dự án đơn giản, các yêu cầu đợc hiểu rõ từ đầu

và kiến trúc đơn giản thì pha chi tiết chỉ gồm một lần lặp đơn giản.
b. Các ranh giới giữa các pha
Danh giới đánh dấu các mèc chÝnh trong chu kú sèng cđa dù ¸n, cơ thể là:
Khởi tạo

Chi tiết

Xây dựng

Chuyển giao

Mục tiêu Kiến trúc Khả năng chứa đựng Nhận biết
Chu kỳ sống chu kỳ sống hoạt động ban đầu
sản phẩm
ở mỗi mốc chính, chúng ta nhìn lại dự án và quyết định đâu là nơi ®Ĩ tiÕp tơc
ph¸t triĨn dù ¸n nh ®· lËp trong kế hoạch, hoặc để sửa đổi nó. Những tiêu chuẩn đợc
sử dụng để tạo ra sự quyết định này ở mỗi pha là khác nhau.
+> Các tiêu chuẩn định lợng cho pha khởi tạo gồm:
Kinh phí làm phần mềm là bao nhiêu? Tính khả thi của dự án nh thế nào? Ngời
quản lý (khách hàng) hỏi bao lâu thì có phần mềm? Những rủi ro và tiến trình phát
triển, độ sâu và chiều rộng của mỗi khuôn mẫu kiến trúc, những sự mở rộng trong
thực tế tơng phản với sự mở rộng trong kế hoạch
+> Các tiêu chuẩn định lợng chung cho pha chi tiÕt bao gåm:
Sù bỊn v÷ng cđa sản phẩm và kiến trúc; sự giải quyết các thành phần rủi ro chủ
yếu; kế hoạch tơng ứng và các sự đánh giá lý giải cho sự hoàn thành dự án, kế hoạch
của dự án; mức độ mở rộng có thể chấp nhận đợc.
+> Các tiêu chuẩn định lợng cho pha xây dựng gồm:
Sự bền vững và khả năng hoàn thiện của sản phẩm, nh là: Nó đà sẵn sàng phát
triển cha? sự sẵn sàng của những ngời giữ tiền đặt cợc (stakeholders) về sự chuyển
giao, mức mở rộng có thể chấp nhận đợc.

+> Các tiêu chuẩn định lợng trong pha chuyÓn giao:
-22-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
Chúng ta quyết định đâu là nơi thực hiện sản phẩm. Chúng ta dựa trên những
quyết định ban đầu ở mức độ thoả mÃn ngời sử dụng đạt đợc trong suốt pha chuyển
giao. Thờng thì mốc này xảy ra đồng thời với sự phát triển lặp của các chu kỳ phát
triển khác.
c. Các sự tái lập (lặp) và các pha
Một sự tái lập là một sự thực hiện tuần tự các hoạt động dựa trên kế hoạch đÃ
thành lập và các tiêu chuẩn đánh giá. Trong mỗi pha, có một dÃy các sự tái lập. Số lần
lặp cho mỗi pha là đa dạng. Mỗi sự lặp ghi lại kết quả trong sự cài đặt có thể thi hành
đợc. Đoạn cuối của một lần lặp, chúng ta nắm bắt các kết quả về mặt kỹ thuật và sửa
đổi các kế hoạch tơng lai nh là sự thiết yếu.
d. Phân bố hoạt động trong các pha phát triển phần mềm hớng đối tợng
Hình 1.5.3 cho ta thấy:
ã Kế hoạch thực hiện trong các pha phát triển, ngoại trừ pha chuyển giao
ã Công việc phân tích và thiết kế đợc thực hiện chủ yếu trong pha chi tiết, một phần
của nó đợc thực hiện trong pha khảo sát khả thi và pha xây dựng
ã Việc xác định các yêu cầu phần lớn đợc thực hiện ở pha khảo sát khả thi, các yêu
cầu không thể xác định hết ngay từ đầu, nó có thể đợc phát hiện và bổ sung thêm
ở các pha còn lại, đặc biệt là ở pha chi tiết
ã Quản lý thay đổi và cấu hình lu trữ toàn bộ lịch sử dự án
ã Thử nghiệm và kiểm tra chất lợng trải dài trong suốt toàn bộ các pha và áp dụng
cho mọi bản mẫu chơng trình
ã Việc triển khai bắt đầu từ pha chi tiết và đợc thực hiện chủ yếu trong pha xây
dựng kéo dài cho đến khi chuyển giao sản phẩm
ã Việc cài đặt đợc bắt đầu từ pha khởi tạo thực hiện trong suốt pha chi tiết và xây
dựng, kéo dài một ít đến pha chuyển giao

Nội dung của các hoạt động trong luồng công việc nh sau:
ã Lập kế hoạch: bao gồm các hoạt động thí điểm dự án, kế hoạch phát triển, quản
lý các tài nguyên dự án
ã Xác định yêu cầu: Xác định các công việc của hệ thống, các yêu cầu để hệ thống
hoạt động tốt
ã Phân tích và thiết kế: bao gồm phát triển mô hình đối tợng và mô hình ngời sử
dụng, đặc tả tổng thể về dự án, mô tả các tiêu chí đánh giá
ã Cài đặt: nhóm phát triển viết mà trình cơ sở, thiết kế tổng quan về ứng dụng và
xây dựng cơ chế chung
ã Thử nghiệm và đánh giá: Bao gồm các hoạt động chứng minh rằng phần mềm
phù hợp với mục tiêu ban đầu và các tiêu chuẩn đánh giá
ã Quản lý thay đổi: Lu trữ trạng thái kết quả của các giai đoạn ph¸t triĨn
-23-


PTTKHT bất động sản nhà ỏ bằng UML thực hành trên RationalRose
ã Quản lý dự án: Quản lý mọi hoạt động của từng thành viên tham gia phát triển dự
án
Chính bản thân ngôn ngữ mô hình hoá trực quan UML không định nghĩa
tiến trình phát triển phần mềm, nhng UML và phần mềm công cụ Rational Rose đợc
sử dụng hiệu quả trong một số công đoạn của tiến trình phát triển phần mềm. Khi bắt
đầu dự án, trong pha khảo sát khả thi (khởi tạo) Rose đợc sử dụng để phát sinh trờng
hợp sử dụng. Trong pha chi tiết, Rose đợc sử dụng để xây dựng biểu đồ trình tự và
biểu đồ cộng tác, chỉ ra các đối tợng tơng tác với nhau nh thế nào. Biểu đồ lớp đợc
xây dựng trong Rose để thấy sự phụ thuộc vào nhau của các đối tợng. Trong giai đoạn
đầu của pha xây dựng, biểu đồ thành phần đợc hình thành nhờ Rose để chỉ ra sự phụ
thuộc giữa các thành phần trong hệ thống và cho ta khả năng phát sinh mà trình cơ
bản. Trong suốt pha xây dựng, Rose cho khả năng chuyển đổi ngợc mà trình thành mô
hình để tích hợp mọi sự thay đổi trong quá trình phát triển. Trong pha chuyển giao,
Rose đợc sử dụng để cập nhật các mô hình đợc tạo lập ra cho dự án.

Nh vậy, tiến trình phát triển phần mềm có ý nghĩa vô cùng quan trọng.
Con đờng mô hình hoá hệ thống bằng UML đều tuân thủ theo các pha phát triển phần
mềm hớng đối tợng. Điều này sẽ đợc minh hoạ một cách rõ ràng sau khi đề cập đến
UML và công việc mô hình hoá hệ thống phần mềm bằng UML thực hành trên
Rational Rose và sau khi áp dụng cho hệ thống bất động sản nhà ở, ở đấy sẽ thể
hiện toàn bộ kết quả nghiên cứu của đề tài này.

Chơng 2. Khái quát về UML và mô hình hoá trực quan
2.1. Mô hình hoá trực quan (Visual Modeling)
2.1.1. Giới thiệu
Mô hình hoá trực quan là mô hình chứa đựng những phần cơ bản của hệ thống
nhờ việc sử dụng các kí hiệu đồ hoạ chuẩn
Mô hình hoá trực quan liên quan đến hai vấn đề: Các tiến trình công việc và các
hệ thống máy tính. Mô hình nắm bắt tầm quan trọng của những công việc trong thế
giới thực và sắp xếp những công việc đó vào các hệ thống máy tính, đây chính là quá
trình mô hình hoá
Để mô hình hoá hệ thống chúng ta cần có một phơng pháp. Phơng pháp này là
một mô hình hoá trực quan thiết lập ra một bản kế hoạch cho hệ thống mà chúng ta
muốn xây dựng, phơng pháp này sử dụng một ngôn ngữ chuẩn mà tất cả mọi ngời đều
hiểu đợc. Đó chính là ngôn ngữ UML

-24-