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

Các chữ viết tắt trong luận văn nàyUML :Unified Modeling Language Ngôn ngữ mô hình hoá hợp nhấtOO : Object Oriented Hớng đối tợng PTTKHT : Phân tích thiết kế hệ thống HRS :Home Realty Sy

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

đề tài:

phân tích thiết kế hệ thống hớng đối tợng bằng UML

Mục Lục Trang

4 Khách thể nghiên cứu và đối tợng nghiên cứu 7

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.5 Giới thiệu các phơng pháp phát triển phần mềm 18

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) 18 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 21 Chơng 2 Khái quát về UML và mô hình hoá trực quan 25

2.1.3 Bốn nguyên tắc cơ bản của mô hình hoá trực quan 25 2.2 Ngôn ngữ mô hình hoá hợp nhất UML-Unified Modeling Language 27

Chơng 3 Những vấn đề cơ sở của mô hình Rational Rose 35

3.2 Sử dụng Rational Rose để tạo lập các biểu đồ UML 35 3.3 Kiến trúc hệ thống và khung nhìn trong Rational Rose 36

Chơng 4 Mô hình hoá trờng hợp-sử dụng (use-case Modeling) 39

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) 43

5.2.3 So sánh biểu đồ cộng tác và biểu đồ tuần tự 55

Phần III PTTKHT hớng đối tợng bằng UML áp dụng cho 62

“ hệ thống Bất động sản nhà ở”

1.2 Nghiên cứu mô hình hoá trờng hợp sử dung cho hệ thống 63

1.2.2.1 Use-case áp dụng cho sự vay mợn 64 1.2.2.2 Use-case Tìm ngời kinh doanh bất động sản 64

1.2.2.4 Use-case Duy trì ngời lập kế hoạch cá nhân 64

1.4.Các đặc tả Use-Case của hệ thống “Bất động sản nhà ở” 65

Các chữ viết tắt trong luận văn nàyUML :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)

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ọilĩ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 ứngdụ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 quantrọ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ềnthố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ứctạ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àotháng 11 năm 1997, từ đó UML đã trở thành công cụ phổ dụng và hữu hiệu cho ph ơngphá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ệcPTTK 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ợngbằ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áttriể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 anhkhô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ấtcả 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ấtlớ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ácThầy Cô giáo, các bạn Tôi xin chân thành cảm ơ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ộtphần vô cùng quan trọng Từ trớc đến nay chúng ta mới đợc làm quen với phơngphá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 xuất hiện sự không thích nghi vớithự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ụngkhô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ơngphá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ơngphá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 rakhả 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 đảmbả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ủacô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íchsang 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ệcPTTKHT “Bất động sản nhà ở” , mặc dù đây là một hệ thống cha đợc phát triểnmạnh ở Việt nam nhng nó phản ánh đợc một cách đầy đủ và chính xác những lợi íchcủ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ảnghơ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 tronglịch sử của công nghệ đối tợng

Simula Smalltalk C++ Java UML

1967 1972 cuối 1980 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ựchiện với một chơng trình hớng đối tợng về lĩnh vực thơng mại

- Cuối những năm 1980, Biame Stroustrop đã công bố ngôn ngữ C++ với quầnchú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 Ôngthấy C++ quá phức tạp và không an toàn cho công việc của mình Oak đã ra đờitrong 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ộtloạ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ậtphâ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ệctrê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ơngphá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ểmnà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ônngữ 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ápBooch, 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 EquipmentCorporation (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ảnmới nhất đợc ra đời vào tháng 2 năm 2000

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ầntrì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 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

Use- 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áclớ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 chomộ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ề

 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

(Thực hành trên Rational Rose)

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,

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ểnchuyể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ềukhiể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ểntê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ổibậ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 ợ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

t-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úcxâ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 chophép 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ảnthâ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ảotrì 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 độngcủ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ạisao 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ờinhằ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ĩnhvự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ơngpháp)

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.

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óitrừ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ậptrung 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ạithự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ìncủ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àmnổ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êucầ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à

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ệcxâ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 cuộc sống hàng ngày ta đơn giản hoá đối tợng khi suy nghĩ, đó chính là côngviệ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ắchơ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ốngphứ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ồmngôn ngữ mô hình hoá, mô hình của mô hình (metamodel) và tiến trình Phơng phápluậ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ìnhthứ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à độngcủ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ựcvấ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ĩnhvự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 Webster’s)

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ứulĩ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ảncủ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àotrả 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ácuse-case; sau đó mô tả hệ thống làm gì bằng các biểu đồ trờng hợp sử dụng (usecase diagram ) và biểu đồ hoạt động (activity diagram)

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ênngoà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ơngtá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 trungvà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ảncủ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àmviệ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ệuvớ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ụngtrong 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.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ữacác đối tợng, nó chuyên chở thông tin với mong muốn rằng hoạt động sẽ xảy rangay sau đó

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

0 n Từ không đến n các trờng hợp cá biệt1 n Từ một đến n các trờng hợp cá biệt0 1 Không hoặc một trờng hợp cá biệt5 8 Chỉ ra dãy (5,6,7 hoặc 8)

4 7,9 Chỉ ra dãy (4,5,6,7 hoặc 9)0 * 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ờnghợ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 khichú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ể

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, nhngtrong đó 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 trongmô 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ậtphẩ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ợngtrng 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ựcthể 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

 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ó ờng thay đổi theo thời gian

th-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ínhchấ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ợnggiá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ảntin (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 vicủ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âuhỏ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 đổitrạ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ànhcủ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ấpcủ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ớitrạ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àysinh, 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ínhduy 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ếuhoặ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ó íttầ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 đặctrng 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ựcthể 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ằngviệ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)

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ôngviệ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êntrong 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ợngphả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ữnghoạ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ữngtrá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 đó đợcduy 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ừutợ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ự hoặc 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 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:

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ở

Lên tầng 2

Bật đèn

Chức năng chính

Chức năng con 1 Chức năng con i Chức năng con n

Phòng thang máy

Công tác

đèn Cửa

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

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áccủ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úctĩ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ụngmộ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ầuchính của hệ thống cha đợc chú ý thích đáng, ở giai đoạn cuối mới phát hiện ranhữ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ạnhtranh 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ìnhnà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ả đợcvấ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 đề Phathiế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ạnthảo một cách tỉ mỉ Mã hoá chơng trình là cài đặt những modul đã thiết kế bằngngôn ngữ lập trình nào đó Sau khi đã mã hoá xong, pha kiểm tra bắt đầu để pháthiện ra những yêu 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

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 Lặp 3

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ẽ

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

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

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

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ểmtra đầ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ờilậ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ớidẫ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áttriể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 tayngờ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ổngquan kiến trúc của RUP

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ọnkiế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 cuối

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ệcnà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àinguyê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êucầ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 tanắ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 chitiết, 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 quyết 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ànthiệ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 chuyển giao (transition)

Chúng ta chuyển giao sản phẩm tới ngời sử dụng cuối và tập trung vào việchuấn luyện, 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à:

ở 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ụcphá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ìnhphá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ộngtrong 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 rochủ 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:

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ữngquyết định ban đầu ở mức độ thoả mãn ngời sử dụng đạt đợc trong suốt pha chuyểngiao 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áttriể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ể thihà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ộtphầ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ácyêu cầu không thể xác định hết ngay từ đầu, nó có thể đợc phát hiện và bổ sungthê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ụngcho 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âydự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âydự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ềmphù 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

 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 Khibắt đầu dự án, trong pha khảo sát khả thi (khởi tạo) Rose đợc sử dụng để phát sinhtrờ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 Tronggiai đ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 Trongpha 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ểnphầ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ànhtrê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

2.1 Mô hình hoá trực quan (Visual Modeling)

Để 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

Thông qua mô hình hoá ta sẽ giới hạn vấn đề nghiên cứu bằng cách chỉ tậptrung vào một khía cạnh của vấn đề vào một thời điểm Mô hình hoá làm tăng trithức của con ngời Mô hình hoá đã có lịch sử lâu đời trong mọi lĩnh vực kỹ nghệ

2.1.2 Lợi ích của mô hình hoá trực quan : Có 4 lợi ích chính

a Mô hình hoá trực quan nắm giữ các tiến trình công việc

Hầu hết các ứng dụng đợc cấu tạo bởi nhiều tiến trình công việc Sự phân tíchtrờng hợp sử dụng cho phép ta nắm giữ các tiến trình công việc từ quan điểm củangời sử dụng Thêm nữa, sự phân tích UC có tác dụng làm giảm bớt đợc rủi ro củakhách hàng và ngời phân tích Sự phân tích trờng hợp sử dụng cho phép ngời phântích hiểu rõ cái họ đang xây dựng, trớc khi cố gắng để xây dựng hệ thống

b Mô hình hoá trực quan là phơng tiện truyền thông

Lợi ích này nằm ở hai công việc chính: Sử dụng mô hình hoá trực quan đểnắm giữ các đối tợng công việc và mối quan hệ giữa chúng; sử dụng mô hình hoátrực quan để phân tích và thiết kế ứng dụng chúng ta đang quan tâm

Ngời phân tích công việc và các chuyên gia trong vùng vấn đề xác định cácyêu cầu Sau đó những ngời phát triển kiến trúc phần mềm xây dựng hệ thống dựatrên các yêu cầu đó Họ có những vấn đề truyền thông do sự khác biệt về thuật ngữ

và việc nhận biết các kí hiệu Đây là nơi mô hình hoá trực quan tạo ra sự khác biệt

Nó nắm giữ cả thế giới công việc lẫn t liệu trong thế giới máy tính Vì thế mô hìnhhoá trực quan tạo ra một sự chuyển tiếp nhẹ nhàng giữa hai thế giới khác nhau vớiviệc lần theo dấu vết từ thế giới công việc tới thế giới máy tính

c Mô hình hoá trực quan điều khiển sự phức tạp

Một mô hình nhỏ thì không có vấn đề gì lớn về độ phức tạp Nhng, trong sựphát triển một dự án thực sự, các hệ thống chứa đựng hàng trăm và thậm chí hàngnghìn lớp Có một bức tranh với 3000 lớp đợc treo trên tờng trong một phòng là rấtkhông có ích Chúng ta cần có một con đờng để gộp các lớp đó thành các tập hợpmang ý nghĩa có ích

Mô hình hoá trực quan sử dụng các gói tin (package- một nhóm các côngviệc) để nhóm các yếu tố của mô hình thành những tập có ý nghĩa Vì thế việc chỉ ramô hình ở các mức khác nhau của sự trừu tợng thành các nhóm khác nhau của conngời là rất quan trọng

d Mô hình hoá trực quan khuyến khích tái sử dụng

Chúng ta tái sử dụng nhiều hơn cài đặt, chúng ta có thể tái sử dụng tất cả: Sựphân tích, sự thiết kế, sự cài đặt, sự thử nghiệm và sự thu thập tài liệu Điều đó làcần thiết cho việc xây dựng sơ đồ nhân tạo nguyên thuỷ Mô hình hoá trực quan chophép ta nhìn nhận một cái gì đó là sẵn có từ quan điểm tái sử dụng

2.1.3 Bốn nguyên tắc cơ bản của mô hình hoá trực quan

<1> Việc lựa chọn mô hình để tạo lập có ảnh hởng sâu sắc đến cách giải quyết vấn đề và cách hình thành các giải pháp

Các mô hình chúng ta tạo ra ảnh hởng một cách sâu sắc đến: Một vấn đề đợcbắt đầu nh thế nào? và một tình huống đợc định hình nh thế nào?

Trong phần mềm, các mô hình ta lựa chọn tác động rất lớn đến cách quan sátthế giới Các mô hình đúng sẽ làm sáng tỏ hầu hết các vấn đề phát triển phức tạpnhất, cho cái nhìn thấu đáo vấn đề cần giải quyết Các mô hình tồi sẽ làm ta lạc lối,làm cho ta tập trung vào các nhiệm vụ không thích đáng Nếu xây dựng hệ thốngtheo cách nhìn của ngời phát triển CSDL thì họ sẽ tập trung vào mô hình quan hệ

thực thể Dới con mắt của ngời phân tích cấu trúc, mô hình sẽ tập trung vào thuậttoán và luồng dữ liệu từ tiến trình này sang tiến trình khác Dới con mắt của ngờiphát triển hớng đối tợng, hệ thống sẽ có kiến trúc tập trung vào vô số lớp và các mẫuthử tơng tác giữa các đối tợng lớp Mỗi cách tiếp cận trên có thể là phù hợp cho mỗilớp ứng dụng hay thói quen phát triển hệ thống Tuy nhiên ngời ta thấy rằng cáchtiếp cận hớng đối tợng vẫn là u việt nhất cho mọi kiến trúc Mỗi cách nhìn thế giới

sẽ dẫn đến sự khác nhau về giá cả và lợi nhuận của hệ thống cần xây dựng

<2> Mô hình biểu diễn hệ thống với các mức độ chính xác khác nhau

Khi xây dựng ngôi nhà cao tầng, đôi khi ta phải đứng xa hàng trăm mét đểquan sát tổng thể; đôi khi ta lại phải quan sát kỹ lỡng hơn nhiều, đến mức từng taycửa Tơng tự với các mô hình phát triển phần mềm, đôi khi ta chỉ cần có mô hìnhnhanh, đơn giản về giao diện ngời dùng; đôi khi ta lại phải quan sát sâu hơn đếnmức các bit khi giải quyết vấn đề tắc nghẽn đờng truyền của hệ thống Trong mọi tr-ờng hợp nói trên thì các loại mô hình tốt nhất là mô hình cho phép ta lựa chọn mức

độ chi tiết khác nhau, phụ thuộc vào ai sẽ là ngời quan sát và tại sao họ lại cần quansát nó Ngời phân tích và ngời sử dụng cuối cùng muốn tập trung vào câu hỏiWhat ? Ngời phát triển sẽ tập trung trả lời câu hỏi How ? Cả hai muốn biểu diễn hệthống ở mức độ chi tiết khác nhau và vào thời gian khác nhau

<3> Mô hình tốt nhất phải là mô hình phù hợp với thế giới thực

Mô hình càng gần với cách suy nghĩ của con ngời về thế giới thực thì càng dễquản lý độ phức tạp Nếu mô hình vật lý của ngôi nhà không phù hợp với cách sửdụng của các vật liệu trên thị trờng thì giá trị của mô hình có hạn Nếu giả thiết củamô hình toán học của con tàu vũ trụ là điều kiện lý tởng và công nghệ hoàn hảo thì

sẽ loại bỏ những nguy hiểm tiềm tàng của tàu vũ trụ thật Mô hình tốt nhất là môhình kết nối rõ ràng với thế giới thực Sự kết nối yếu ở đâu bạn cần phải biết mộtcách chính xác

Mọi mô hình đều là sự đơn giản hoá thế giới thực, do vậy phải đảm bảo tiếntrình đơn giản hoá sẽ không loại đi các chi tiết quan trọng Với phần mềm, trong các

kỹ thuật phân tích cấu trúc thì mô hình phân tích và mô hình thiết kế hệ thống táchbiệt nhau Thiếu cầu nối giữa hai loại mô hình này, dẫn tới hệ thống sẽ đợc hiểu vàxây dựng khác nhau vào các thời điểm khác nhau Trong hệ thống hớng đối tợng, cókhả năng liên kết mọi quan sát tơng đối độc lập vào toàn thể Một mô hình tốt biểu

lộ một cách thực chất bất cứ lỗ hổng quyết định nào trong thiết kế

<4> Không có mô hình đơn giản nào là đầy đủ Mỗi hệ thống thờng đợc tiếp cận thông qua tập mô hình gần nh độc lập với nhau

Cụm từ “gần nh độc lập-nearly independent" mang ý nghĩa là: Các mô hình

đợc xây dựng và nghiên cứu một cách tách biệt nhng vẫn có mối quan hệ với nhau.

Thí dụ, ta có thể thiết kế hệ thống điện nớc một cách độc lập, nhng quá trình thiết kếnày phải quan tâm đến mô hình thiết kế của các tầng nhà cho phù hợp với nó Tơng

tự nh trong hệ thống phần mềm hớng đối tợng, để hiểu kiến trúc hệ thống phần mềm

ta cần nhiều quan sát (cảnh-view) hoàn thiện và ăn khớp nhau Một cảnh kiểu kiếntrúc có thể đợc định nghĩa nh là một sự mô tả đã đơn giản hoá (một điều trừu tợng)của một hệ thống từ một quan sát đặc biệt hoặc một điểm thuận lợi, việc bao bọc cácmối lên kết đặc biệt và việc bỏ sót các thực thể không xác đáng với phối cảnh này.Mỗi cảnh đều có khía cạnh kiến trúc hay hành vi riêng Tập hợp lại, các cảnh này cókhả năng biểu diễn đợc kế hoạch chi tiết của phát triển phần mềm Các hệ thốngkhông đòi hỏi phải có đầy đủ tất cả các cảnh

Các cảnh trong Rose đợc nói đến trong chơng 3

2.2 Ngôn ngữ mô hình hoá hợp nhất UML-Unified Modeling Language

UML là ngôn ngữ mô hình hoá, trớc hết nó mô tả ký pháp thống nhất, ngữ

nghĩa và các định nghĩa về metamodel (mô tả và định nghĩa chính ngôn ngữ mô

hình hoá), nó không mô tả về phơng pháp phát triển UML đợc sử dụng để hiển thị,

đặc tả, xây dựng và làm tài liệu các vật phẩm (artifacts) của phân tích hình thức vàthiết kế (có thể là báo cáo, biểu đồ, bản mẫu, trang web ) trong quá trình xây dựngphần mềm theo hớng đối tợng UML đợc sử dụng cho mọi tiến trình phát triển phầnmềm, xuyên suốt vòng đời phát triển và độc lập với các công nghệ cài đặt hệ thống

2.2.1 Giới thiệu UML

UML là ngôn ngữ chuẩn để viết các kế hoạch chi tiết phần mềm Nó phùhợp cho việc mô hình hoá các hệ thống nh thông tin doanh nghiệp, các ứng dụngphân tán web, các ứng dụng nhúng thời gian thực Các khung nhìn của ngôn ngữ đ-

ợc quan sát từ góc độ phát triển và triển khai hệ thống, nó không khó hiểu và dễ sửdụng UML là ngôn ngữ mô hình đợc cả con ngời và máy tính sử dụng Một ngônngữ mô hình là một ngôn ngữ mà từ vựng và các luật của nó dựa trên sự miêu tả vềmặt vật lý và quan niệm UML là ngôn ngữ mô hình hoá chuẩn cho các sơ đồ thiết

kế phần mềm UML có ký pháp (các biểu tợng sử dụng trong mô hình) và tập các

luật sử dụng của nó Các luật bao gồm cú pháp, ngữ nghĩa và pragmatic (luật hình

thành câu có nghĩa)

UML là ngôn ngữ và nó chỉ là một phần của tiến trình phát triển phần mềm,

độc lập với tiến trình Tuy nhiên UML rất phù hợp với các tiến trình hớng trờng hợp

sử dụng (Use Case), lấy kiến trúc làm trung tâm, tơng tác và tăng dần

Thông thờng ta phải xây dựng xây dựng nhiều mô hình cho một hệ thống, dovậy ngôn ngữ phải cho phép biểu diễn nhiều khung nhìn (views) khác nhau của kiếntrúc phần mềm trong suốt quá trình phát triển hệ thống phần mềm Từ vựng và quytắc ngôn ngữ UML cho ta cách thức xây dựng mô hình và đọc mô hình, nhng khôngcho biết mô hình nào cần phải đợc lập và khi nào lập chúng Nhiệm vụ đó đợc xác

định nhờ quy trình phát triển phần mềm Quy trình phát triển phần mềm sẽ giúpchúng ta đa ra quyết định hình thành vật phẩm nào, hoạt động nào và nhân viên nào

sẽ tạo ra, sử dụng và quản lý chúng Đồng thời chúng đợc sử dụng nh thế nào vàoviệc quản lý toàn bộ dự án

a UML là ngôn ngữ để hiển thị

Thực tế là có thể trực tiếp viết mã trình cho một số việc, trực tiếp mô tả thuậttoán và biểu thức bằng văn bản Tuy nhiên, việc giao tiếp giữa mô hình khái niệmvới những cái khác trong vòng đời phát triển phần mềm sẽ khó khăn khi mọi ngờikhông sử dụng chung một ngôn ngữ cho dự án

UML giúp xây dựng mô hình để dễ dàng giao tiếp Một số công việc phù hợpvới mô hình bằng văn bản, một số công việc khác lại phù hợp với mô hình hoá bằng

đồ hoạ UML là ngôn ngữ đồ hoạ Với nhiều hệ thống, mô hình trong ngôn ngữ đồhoạ dễ hiểu hơn so với ngôn ngữ lập trình Sau mỗi biểu tợng đồ hoạ của ngôn ngữUML là ngữ nghĩa Bởi vậy mô hình trong UML đảm bảo đợc : Một ngời phát triển

có thể viết một mô hình trong UML, và một ngời phát triển khác lại có thể diễn giải

đợc mô hình đó một cách không nhập nhằng

b UML là ngôn ngữ đặc tả

UML cho phép mô tả mô hình chính xác, không nhập nhằng và hoàn thiện Sự

đặc tả có nghĩa là mô tả rõ ràng những điểm mấu chốt của vấn đề UML hớng tới

đặc tả thiết kế, phân tích và quyết định cài đặt trong quá trình phát triển và triển khai

hệ thống phần mềm

c UML là ngôn ngữ để xây dựng

UML không phải là ngôn ngữ lập trình trực quan, nhng các mô hình UML cóthể kết nối trực tiếp tới các ngôn ngữ lập trình khác nhau Có nghĩa là có thể ánh xạmô hình trong UML tới các ngôn ngữ lập trình khác nh : Java, C++ , Visual

Basic, hay các bảng CSDL quan hệ, CSDL hớng đối tợng ánh xạ này cho khảnăng biến đổi thuận từ mô hình UML sang ngôn ngữ lập trình Đồng thời, cho khảnăng biến đổi ngợc lại từ cài đặt về mô hình UML; có nghĩa rằng nó cho khả nănglàm việc với văn bản hay đồ hoạ một cách nhất quán Tuy nhiên để diễn đạt tốt nhấtbằng đồ hoạ thì nên diễn đạt bởi đồ hoạ trong UML, còn để diễn đạt một cách tốtnhất bàng văn bản thì nên làm trong ngôn ngữ lập trình.

d UML là ngôn ngữ làm tài liệu

UML hớng tới làm tài liệu kiến trúc hệ thống và các chi tiết của nó UML chokhả năng biểu diễn yêu cầu, thử nghiệm, mô hình hoá các hoạt động lập kế hoạch vàquản lý sản phẩm

 UML cho biết giới hạn của hệ thống và các chức năng của nó thông qua UC vàtác nhân

 Trong UML, các UC đợc mô tả bằng biểu đồ logic

 Biểu diễn cấu trúc tĩnh của hệ thống nhờ biểu đồ lớp

 Mô hình hoá các hành vi đối tợng bằng biểu đồ chuyển trạng thái

 Phản ánh kiến trúc và cài đặt vật lý bằng biểu đồ thành phần và biểu đồ triểnkhai

 Mở rộng chức năng bằng các khuân mẫu (stereotypes)

2.2.2 Mô hình khái niệm của UML

Để hiểu đợc UML ta phải hình dung ra đợc mô hình khái niệm của ngôn ngữnày Gồm 3 vấn đề chính: các phần tử cơ bản để xây dựng mô hình, quy tắc liên kếtcác phần tử mô hình và một số cơ chế chung sử dụng cho ngôn ngữ Khi đó ta mới

có thể đọc đợc mô hình UML và tạo ra một vài mô hình cơ bản

a Các phần tử của mô hình trong UML

a1 Phần tử cấu trúc: Phần tử cấu trúc là các danh từ trong mô hình UML Chúng

là bộ phận tĩnh của mô hình để biểu diễn các thành phần khái niệm hay vật lý Cóbảy loại phần tử cấu trúc nh mô tả dới đây:

Đối tợng Một đối tợng trong UML đợc tợng trng bởi một hình chữ nhật có

tên gạch dới và đợc đăt sau dấu hai chấm Một đối tợng có thể có tên hoặc mặc định.Hình 2.1 thể hiện ký pháp đồ hoạ của đối tợng trong UML

Lớp Lớp là một tập các đối tợng cùng chung thuộc tính, thao tác, quan hệ và

ngữ nghĩa Một lớp cài đặt một hay nhiều ghép nối Hình 2.2 biểu diễn đồ hoạ lớpbằng hình chữ nhật, thông thờng chúng có tên, thuộc tính và thao tác Mọi lớp phải

có tên để nhận ra nó từ lớp khác Một tên là một xâu kí tự Một lớp có thể đ ợc chỉ rabởi việc chỉ ra duy nhất tên của nó

Giao diện Giao diện là tập hợp các thao tác làm dịch vụ của lớp hay thành

phần Giao diện mô tả hành vi thấy đợc từ ngoài của thành phần Giao diện biểudiễn toàn bộ hay một phần hành vi của lớp Giao diện định nghĩa tập đặc tả thao tácchứ không định nghĩa cài đặt của chúng Ký pháp đồ hoạ của nó đợc mô tả trên hình2.3 Giao diện thờng không đứng một mình mà đợc gắn vào lớp hay thành phần thựchiện giao diện

Hình 2.3 Tác nhân ngoài

a2 Phần tử cộng tác: Phần tử cộng tác là mô tả ngữ cảnh của tơng tác Ký pháp đồ

hoạ của nó chính là hình elip với đờng nét đứt, kèm theo tên nh trên hình 2.4 Phần

tử cộng tác thể hiện một giải pháp thi hành bên trong hệ thống, bao gồm các lớp, cácquan hệ và tơng tác giữa chúng để đạt đợc một chức năng mong đợi của UC

Hình 2.4 Cộng tác Hình 2.5 Use case

Trờng hợp sử dụng (Use case): Mô tả tập trình tự các hành động mà hệ

thống sẽ thực hiện để đạt đợc kết quả cho tác nhân nào đó Tác nhân là những gì bênngoài tơng tác với hệ thống Tập hợp các UC của hệ thống sẽ hình thành các trờnghợp mà hệ thống đợc sử dụng Sử dụng UC để cấu trúc các phần tử có hành vi trongmô hình Nó đợc thực hiện hoá bởi phần tử cộng tác Hình 2.5 là ký pháp đồ hoạcủa UC

Lớp tích cực (active class) Lớp tích cực là lớp có đối tợng làm chủ một hay

nhiều tiến trình hay luồng Lớp tích cực đợc xem nh lớp thông thờng nhng đối tợngcủa nó biểu diễn các thành phần có hành vi đang tơng tranh với các thành phầnkhác Ký pháp đồ hoạ của nó tơng tự lớp thông thờng nhng có đờng biên tô đậm.Thông thờng, chúng cũng có tên, thuộc tính, thao tác

Thành phần (component) Thành phần biểu diễn vật lý mã nguồn, các tệp

nhị phân trong quá trình phát triển hệ thống Ký pháp đồ hoạ đợc biểu diễn trên hình2.6

Nút (node) Nút là thể hiện thành phần vật lý, tồn tại khi chơng trình chạy và

biểu diễn các tài nguyên tính toán Có thể đặt lập các thành phần trên nút và chuyển

từ nút này sang nút khác Nút có thể là máy tính, thiết bị cứng Ký pháp đồ hoạ đ ợcbiểu diễn trên hình 2.7

Hình 2.6 Thành phần Hình 2.7 Nút

Tên Use case

Myfile.cpp

Máy chủActor name

a3 Phần tử hành vi: Phần tử hành vi là bộ phận động của mô hình UML Chúng là

các động từ của mô hình, biểu diễn hành vi theo thời gian và không gian Có hai loạichính là tơng tác và trạng thái

Tơng tác Tơng tác là hành vi bao gồm tập các thông điệp trao đổi giữa các

đối tợng trong ngữ cảnh cụ thể để thực hiện mục đích cụ thể Hành vi của nhóm đốitợng hay của mỗi thao tác có thể đợc chỉ ra bằng tơng tác Biểu diễn đồ hoạ củathông điệp đợc thể hiện trên hình 2.8, bao gồm mũi tên và tên thao tác của nó

Hiển thị

Hình 2.8 Thông điệp Hình 2.9 Trạng thái

Máy trạng thái Máy trạng thái là hành vi chỉ ra trật tự các trạng thái mà đối

tợng hay tơng tác sẽ đi qua để đáp ứng sự kiện Hành vi của lớp hay cộng tác của lớp

có thể đợc xác định bằng máy trạng thái Máy trạng thái kích hoạt nhiều phần tử,bao gồm trạng thái, chuyển tiếp (từ trạng thái này đến trạng thái khác), sự kiện vàcác hoạt động (đáp ứng sự kiện) Ký pháp đồ hoạ của trạng thái đợc thể hiện trênhình 2.8, nó chứa tên và trạng thái con nếu có

a4 Phần tử nhóm: Phần tử nhóm là bộ phận tổ chức của mô hình UML Chỉ có

một phần tử thuộc nhóm này có tên là gói (package) Gói là cơ chế đa năng để tổ

chức các phần tử vào nhóm Các phần tử cấu trúc , hành vi và ngay cả phần tử nhóm

có thể cho vào gói Sử dụng gói trong hai việc: một gói có thể tổ chức mô hình dới

sự phát triển; nó có thể là một đơn vi của việc quản lý cấu hình Một gói tin là mộtcơ cấu quan trọng cho việc phân phối vùng Không có các gói tin, ta có thể kết thúcvới một mô hình rộng và to Các mô hình có thể chứa đựng hàng trăm thậm chí hàngnghìn các thành phần mô hình Số thành phần có thể nhanh chóng trở nên tràn ngập.Gói nhóm các thành phần mô hình thành những sự lựa chọn để duy trì và đọc môhình một cách dễ dàng Các gói giúp ta điều khiển các thành phần hợp thành hệthống có liên quan ở các mức khác nhau qua thời gian

Không giống thành phần (component), phần tử nhóm hoàn toàn là khái niệm,

có nghĩa rằng chúng chỉ tồn tại vào thời điểm phát triển hệ thống chứ không tồn tạivào thời gian chạy chơng trình Ký pháp đồ hoạ nh hình 2.10 Gói giúp ta quan sát

hệ thống ở mức tổng quát hơn

a5 Phần tử chú thích (annotational): Phần tử chú thích là bộ phận chú giải của

mô hình UML Đó là lời giải thích áp dụng để mô tả các phần tử khác trong môhình Ký pháp đồ hoạ ở hình 2.10

Hình 2.10 Nhóm và lời ghi chú

b Các quan hệ trong UML

Có bốn loại quan hệ trong UML, bao gồm: quan hệ phụ thuộc, kết hợp, kháiquát hoá và thực hiện hoá Chúng là các khối cơ sở để xây dựng mọi quan hệ trongmô hình UML Hình 2.11 minh hoạ ký pháp và ý nghĩa của các loại quan hệ

Chờ

Tên nhóm Day la loi chu thich

Tụ hợp (aggregation).là dạng đặc biệt của kết hợp,

nó biểu diễn quan hệ cấu truc giữa toàn thể và bộ phận

Hợp thành (composition).Là dạng đặc biệt của taụ

hợp,trong đó nếu nh đối tợng toàn thể bị huỷ bỏ thì

các đối tợng bộ phận cũng bị huỷ bỏ theo

Dependency (phụ thuộc):

Là quan hệ ngữ nghĩa giữa hai phần tử trong đó thay

đổi phần tử độc lập sẽ tác động đến ngữ nghĩa của phần tử phụ thuộc

Generalization (khái quát hoá):

Là quan hệ đặc biệt hóa mà trong đó đối tợng cụ thể

sẽ kế thừa các thuộc tính và phơng pháp của đối tợng tổng quát.

Realization (thực hiện hoá):

Là quan hệ ngữ nghĩa giữa giao diện và lớp (hay thành phần) hiện thực lớp; giữa UC và hợp tác hiện thực UC

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

ẹaõy laứ moỏi quan heọ (0,n)-(1,1) coự nghúa laứ giửừa 0 vaứ n ủoỏi tửụùng cuỷa thửùc theồ beõn traựi tửụng ửựng vụựi 1 ủoõi tửụùng duy nhaỏt cuỷa thửùc theồ beõn phaỷi.

ẹaõy laứ moỏi quan heọ (n,n)-(0,1) coự nghúa laứ n ủoỏi tửụùng cuỷa thửùc theồ beõn traựi tửụng ửựng voựi 0 hay 1 ủoỏi tửụùng cuỷa thửùc theồ beõn phaỷi.

Đây là mối quan hệ 1-1

2.2.4 Kiểu dữ liệu

Kiểu dữ liệu không phải là phần tử mô hình trong UML Kiểu dữ liệu cơ sở là

kiểu dữ liệu không có cấu trúc UML có các kiểu dữ liệu sau:

 Boolean: là kiểu đếm với hai giá trị True và False

 Biểu thức: là xâu ký tự có cú pháp

 Multiplicity: Là tập không rỗng của các số nguyên dơng và kí tự (*) để biểu

thị tính nhiều vô hạn

 Tên (name): Là xâu kí tự cho khả năng đặc tả phần tử

 Số nguyên (integer): Là kiểu cơ bản và là phần tử của tập vô hạn các số

nguyên âm và dơng

 Xâu (string): Là trật tự các ký tự đợc sử dụng làm tên

 Thời gian (time): Xâu ký tự biểu diễn giá trị tuyệt đối hay khoảng tơng đối

 Không lý giải (uninterpreted):Là cái gì đó mà ý nghĩa của nó phụ thuộc vào

lĩnh vực

2.2.5 Các biểu đồ UML

Biểu đồ là biểu diễn đồ hoạ bao gồm tổ hợp vô số các phần tử của mô hình

nh đã nêu ở trên Vẽ biểu đồ để biểu diễn hệ thống đang xây dựng dới các góc độquan sát khác nhau UML đã đợc lựa chọn nh là một công nghệ chuẩn, là nền tảng

độc lập, xác định một ngôn ngữ đồ hoạ cho các mô hình hiện tại và xác định ngữnghĩa cho mỗi thành phần đồ hoạ Để xây dựng một mô hình trực quan của một hệthống, nhiều biểu đồ khác nhau cần đợc sử dụng để thể hiện các cảnh khác nhau của

hệ thống UML cho khả năng xây dựng các kiểu biểu đồ trực quan để biểu diễn cáckhía cạnh khác nhau của hệ thống, bao gồm các biểu đồ sau đây:

 Biểu đồ trờng hợp sử dụng (use case diagram): Minh hoạ các sự tơng tác của

ngời sử dụng với hệ thống

 Biểu đồ tơng tác (interaction diagram) gồm biểu đồ trình tự (sequence

diagram) và biểu đồ cộng tác (collaboration diagram): Minh hoạ hành vi của

hệ thống

 Biểu đồ lớp (class diagram): Minh hoạ kiến trúc của hệ thống

 Biểu đồ trạng thái (state transiton diagram): Minh hoạ hành vi của hệ thống

 Biểu đồ thành phần (component diagram): Minh hoạ cấu trúc vật lý của phần

mềm

 Biểu đồ triển khai (deployment diagram): Chỉ ra sự sắp xếp của phần mềm tới các cấu hình của phần cứng

 Biểu đồ đối tợng (object diagram): Minh hoạ sự tơng tác giữa các đối tợng

 Biểu đồ hoạt động (activity diagram): Minh hoạ luồng các sự kiện

2.3 Laứm theỏ naứo ủeồ ửựng duùng UML vaứo ủeà taứi

Duứng caực tieõu chuaồn cuỷa vieọc phaõn tớch vaứ thieỏt keỏ theo hửụựng ủoỏi tửụùng(caực tieõu chuaồn naứy cuừng ủửụùc ủửa ra trong caực saựch noựi veà UML) - vaứ duứng heọthoỏng kyự hieọu cuỷa UML ủeồ dieón giaỷi - ủeồ thửùc hieọn nhửừng ủieàu sau:

 Xaực ủũnh caực actor cuỷa heọ thoỏng : Actor laứ ngửụứi hay heọ thoỏng khaực coự tửụng

taực vụựi heọ thoỏng cuỷa chuựng ta

 Xaực ủũnh caực use case : use case laứ taứi lieọu moõ taỷ veà moọt chuoói caực sửù kieọn

cuỷa moọt actor Ngoaứi ra, xaực ủũnh theõm use case naứo tửụng ửựng vụựi actor naứo.Use case chớnh laứ moõ taỷ cuỷa moọt quaự trỡnh

Lửụùc ủoà use case (Use case diagram) ủửụùc duứng ủeồ dieón taỷ caực use casecuỷa heọ thoỏng vaứ moỏi quan heọ giửừa caực use case vaứ caực actor

 Xác định các đối tượng của hệ thống, mối liên kết và các thuộc tính của

chúng Mô hình khái niệm (Conceptual Model) dùng để diễn tả điều này

 Xác định các message được gửi đi giữa các đối tượng Lược đồ tương tác

(Interaction diagram) dùng để diễn tả điều này

 Xác định mối liên kết giữa các đối tượng (hay các lớp) và các phương thức

của mỗi lớp như khi được hiện thực Class diagram dùng để diễn tả điều này

Define use case conceptual Define

model

Define collaboration diagrams

Define design class diagrams

Chơng 3 Những cơ sở của rational rose 3.1 Rational Rose là gì?

Rational Rose là phần mềm công cụ mạnh hỗ trợ phân tích, thiết kế hệ thốngphần mềm theo hớng đối tợng Nó giúp ta mô hình hoá hệ thống trớc khi viết mãtrình, nó đảm bảo tính đúng đắn, hợp lý của kiến trúc hệ thống từ khi khởi đầu dự

án Mô hình Rose là bức tranh hệ thống, nó bao gồm toàn bộ biểu đồ UML, tácnhân, trờng hợp sử dụng, đối tợng, lớp, thành phần và các nút triển khai trong hệthống Nó mô tả chi tiết hệ thống bao gồm cái gì và chúng làm việc ra sao để ng ờiphát triển hệ thống có thể sử dụng mô hình nh kế hoạch chi tiết cho việc xây dựng

hệ thống

Khác hẳn với phong cách lập trình truyền thống, Rose đem đến cho ta mộtphong cách phát triển hệ thống khác Đó là: Sau khi xác định yêu cầu, các thiết kếphải đợc làm tài liệu chi tiết Mọi ngời tham gia phát triển cùng trao đổi quyết địnhthiết kế trớc khi viết mã trình Do vậy dự án không còn phải lo lắng khi ai đó rời bỏ

dự án Ngoài ngời phát triển hệ thống quan tâm đến mô hình, mọi thành viên kháccủa dự án đều có thể thu nhận thông tin cần thiết từ mô hình:

 Khách hàng và ngời phát triển hệ thống sử dụng các biểu đồ UC để có cái nhìnbao quát về hệ thống và thống nhất với nhau về phạm vi dự án

 Quản lý dự án sử dụng biểu đồ UC và tài liệu để chia nhỏ dự án thành các dự

án nhỏ hơn có thể quản lý đợc

 Thông qua tài liệu UC, phân tích viên, khách hàng lấy đợc các chức năng hệthống sẽ cung cấp

 Thông qua tài liệu UC, ngời làm tài liệu kỹ thuật có thể bắt đầu viết hớng dẫn

sử dụng và kế hoạch huấn luyện sử dụng

 Các phân tích viên và ngời phát triển, thông qua các biểu đồ trình tự và cácbiểu đồ cộng tác, thấy đợc logic của hệ thống, các đối tợng trong hệ thống vàcác thông điệp giữa các đối tợng

 Đội ngũ kiểm tra chất lợng thông qua tài liệu UC và các biểu đồ tơng tác thuthập thông tin để viết mô tả kiểm tra hệ thống

 Ngời phát triển sử dụng biểu đồ lớp, biểu đồ biến đổi trạng thái để có cái nhìnchi tiết về các phần hệ thống và mối quan hệ giữa chúng

 Đội ngũ triển khai sử dụng các biểu đồ thành phần và các biểu đồ triển khaithấy đợc các tệp khả thực (.exe), các tệp th viện động (.DLL-Dynamic LinkingLibrary) nào và các thành phần khác cần đợc tạo lập, các thành phần này đợctriển khai trên mạng nh thế nào?

 Toàn bộ đội ngũ sử dụng mô hình để đảm bảo các yêu cầu có thể chuyển sangmã trình và ngợc lại, mã trình có thể trở lại yêu cầu của hệ thống

3.2 Sử dụng Rational Rose để tao lập các biểu đồ UML

Sử dụng Rose, ta có thể tạo lập một số hoặc tất cả các biểu đồ để làm phơngtiện cho các tiến trình phát triển của chúng ta Cách thức tạo lập các biểu đồ trongRose tôi không đề cập trong luận văn này, mà chỉ thể hiện nó bằng những biểu đồ đ-

ợc xây dựng cho hệ thống “Bất động sản nhà ở”

3.3 Kiến trúc hệ thống và các khung nhìn trong Rational Rose

3.3.1 Kiến trúc hệ thống là gì ?

Kiến trúc là trừu tợng hoá các khía cạnh quan trọng của hệ thống Kiến trúc làmột phần của thiết kế, nó đa ra những quyết định về việc: Hệ thống sẽ xây dựng nhthế nào? Lựa chọn các phần tử cấu trúc và giao diện cho hệ thống; hành vi củachúng thể hiện trong hợp tác các phần tử; tổ hợp các phần tử cấu trúc và hành vi.Nhng kiến trúc không phải là toàn bộ sự thiết kế, nó chỉ dừng lại ở sự trừu tợng nhất

và các thành phần chủ yếu của hệ thống Một kiến trúc của hệ thống phần mềm môtả tầm cỡ, sức mạnh của hệ thống, thu thập các UC quan trọng nhất và các yêu cầuứng dụng Kiến trúc hệ thống là vật phẩm quan trọng nhất, đợc sử dụng để quản lýcác điểm nhìn khác nhau về hệ thống.

Kiến trúc phần mềm không chỉ liên quan đến cấu trúc, hành vi mà cả chứcnăng, tính sử dụng lại, dễ hiểu, ràng buộc công nghệ

Kiến trúc hệ thống phần mềm đợc mô tả bằng các khung nhìn Các khungnhìn ánh xạ vào tổ chức và cấu trúc hệ thống, mỗi khung nhìn tập trung vào khíacạnh cụ thể của hệ thống

3.3.2 Các khung nhìn trong Rational Rose

Mô hình đợc xây dựng nhờ sử dụng các khung nhìn và các biểu đồ khác nhau

để miêu tả các phối cảnh khác nhau và các khối xây dựng của một hệ thống Mộtkhung nhìn kiểu kiến trúc là một sự mô tả đơn giản (sự trừu tợng hoá) của một hệthông từ một phối cảnh đặc biệt hoặc một vi trí thuận lợi Các khung nhìn là các lát

cắt mỏng (slice) của mô hình Các biểu đồ UML thể hiện ý nghĩa của các khung

nhìn Trong Rational Rose có thể xây dựng các khung nhìn sau đây:

a Khung nhìn trờng hợp sử dụng (Use case view)

Khung nhìn này đứng trớc mọi khung nhìn khác bởi vì nó chỉ rõ cái mà hệthống nên làm (hình 3.1) Nó bao gồm các biểu đồ trờng hợp sử dụng, một luồngcác sự kiện của trờng hợp sử dụng và các tài liệu bổ sung Nó cũng có thể bao gồmcác biểu đồ hoạt động, biểu đồ tơng tác và gói

Khung nhìn UC đợc hình thành từ giai đoạn phân tích yêu cầu và đợc sử dụng

để điều khiển và thúc đẩy phần việc còn lại của thiết kế Nó mô tả hành vi của hệthống theo cách nhìn của khách hàng, phân tích viên và kỹ s kiểm tra, thử nghiệm

Khung nhìn UC tập trung vào cái mà hệ thống phải làm ở mức cao nhất của

b Khung nhìn logic hay khung nhìn thiết kế (logical/disign view)

Khung nhìn logic biểu diễn tổ chức của các lớp có ý nghĩa nhất và các quan

hệ của chúng với nhau Nó tập trung vào việc hệ thống cài đặt hành vi trong UC nhthế nào, tức là nó trợ giúp các yêu cầu về chức năng của hệ thống Nó bao gồm cáclớp, biểu đồ lớp, biểu đồ đối tợng (khía cạnh tĩnh của khung nhìn), biểu đồ tơng tác,biểu đồ trạng thái (khía cạnh động của khung nhìn) và các gói Hầu hết mọi ngờitrong hệ thống đều quan tâm đến khung nhìn logic

Design view (logic view) Implementation view

Use case view

Lớp phân tích có thể xuất hiện cả trong các biểu đồ tơng tác của khung nhìn

UC Một khi đã nhận ra các lớp phân tích thì đội ngũ phát triển phần mềm chuyểnchúng sang lớp thiết kế Đó là những lớp phụ thuộc ngôn ngữ

Khung nhìn logic tập trung vào cấu trúc logic của hệ thống Trong khung nhìnnày ta sẽ nhận ra bộ phận của hệ thống, khảo sát thông tin và hành vi, khảo sát quan

hệ giữa các bộ phận

c Khung nhìn cài đặt/ thành phần (implementation/ component view)

Khung nhìn thành phần ghi địa chỉ xuất phát của sự điều khiển các sản phẩmphần mềm, sự tái sử dụng, các hợp đồng nhỏ và các thành phần trợ giúp; mô tả sự tổchức của các modul phần mềm tĩnh (mã nguồn, các tệp dữ liệu, các thành phần, khảnăng thực hiện, ) trong phạm vi của các gói, sự phân tầng và cấu hình điều khiển.Bao gồm: thành phần, biểu đồ thành phần và gói

Ngời quan tâm đến khung nhìn thành phần là ngời có trách nhiệm quản lý mãtrình, dịch chơng trình và triển khai ứng dụng Một vài thành phần là th viện, một sốkhác là mã trình khả thực(.exe) và th viện(.dll)

d Khung nhìn triển khai (deployment view)

Khung nhìn này tập trung phân bổ vật lý các tài nguyên và phân bổ nhiệm vụcác tài nguyên Khung nhìn triển khai liên quan đến triển khai vật lý của hệ thống,khác với kiến trúc logic Khung nhìn triển khai bao gồm tiến trình (luồng thực hiệntrong vùng nhớ riêng), bộ xử lý và thiết bị

Khung nhìn triển khai chỉ ra các tiến trình và thiết bị trên mạng và các kết nốivật lý giữa chúng Biểu đồ triển khai cũng hiẻn thị tiến trình và chỉ ra tiến trình nàochạy trên máy nào

e Khung nhìn tiến trình (process view)

Khung nhìn tiến trình biểu diễn phân tách các luồng thực hiện chơng trình.Ghi địa chỉ của sự thi hành, khả năng chạy và số lợng một lệnh đa vào tiến trình của

hệ thống Bao gồm: tiến trình-process, luồng-thread, nhiệm vụ-task, đồng bộ giữacác luồng, phân bổ các đối tợng và lớp cho các luồng thực hiện khác nhau Nó tậptrung vào các nhiệm vụ tơng tranh tơng tác với nhau nh thế nào trong các hệ thống

đa nhiệm

f Cần có bao nhiêu khung nhìn?

Không phải tất cả các hệ thống đều đòi hỏi đầy đủ các khung nhìn mô tả trên

Hệ thống trên máy riêng lẻ có thể bỏ khung nhìn triển khai, nếu hệ đơn xử lý có thể

bỏ khung nhìn tiến trình, nếu chơng trình nhỏ thì có thể bỏ khung nhìn cài đặt

Về mặt kiến trúc phần mềm thì cần tới tất cả các khung nhìn; về mặt phântích hệ thống thì khung nhìn tiến trình là quan trọng nhất; đối với ngời thiết kế thìkhung nhìn logic/ thiết kế là quan trọng nhất; đối với ngời sử dụng cuối thì khungnhìn trờng hợp sử dụng là quan trọng nhất

Phụ thuộc vào bản chất của hệ thống mà mỗi mô hình có tầm quan trọng khácnhau Ví dụ, với mô hình quản lý nhiều dữ liệu thì các mô hình quan sát thiết kế tĩnh

sẽ quan trọng hơn Nếu hệ thống phải có nhiều giao diện ngời sử dụng thì các cảnhtrờng hợp sử dụng tĩnh và động đều rất quan trọng Hệ thống thời gian thực coi trọngcảnh tiến trình động, hệ thống phân tán (các ứng dụng Web) coi mô hình triển khai

và cài đặt quan trọng nhất

Chơng 4 Mô hình hoá trờng hợp sử dụng

Phân tích và thiết kế bao gồm mô hình hoá vấn đề và giải pháp từ cácgóc nhìn khác nhau Phân tích chính là mô hình hoá hành vi của hệ thống trên cáctrờng hợp sử dụng (hành vi của hệ thống là cách thức một hệ thống hoạt động và táihoạt động, nó có thể nhìn thấy đợc từ quan sát bên ngoài và có thể kiểm tra đợc hoạt

động của hệ thống; các trờng hợp sử dụng là cơ cấu về việc nắm giữ hành vi đã yêucầu cho hệ thống nhng không chỉ ra hành vi hệ thống đợc thực hiện nh thế nào) Vìvậy, trong pha phân tích ta thờng quan tâm đến ba loại mô hình, đó là: mô hình tr-ờng hợp sử dụng, mô hình lĩnh vực, mô hình giao diện Mô hình trờng hợp sử dụngmô tả hệ thống sẽ đợc sử dụng nh thế nào Mô hình lĩnh vực sẽ mở rộng mô hình tr-ờng hợp sử dụng bằng cách đặt hệ thống vào trong ngữ cảnh Mô hình giao diện ng-

ời sử dụng mô tả ngời sử dụng tơng tác với hệ thống nh thế nào

Chơng này sẽ mô tả cách phân tích, tìm kiếm trờng hợp sử dụng (UC), tácnhân (actor) và quan hệ giữa chúng UC là những gì bên trong hệ thống còn tác nhân

là những gì bên ngoài hệ thống

4.1 Mô hình trờng hợp sử dụng ( U se-case Model) là gì ?

Mô hình trờng hợp sử dụng là sự thể hiện

Các chức năng (hay các UC) đã xác địnhcủa U se-case Model

hệ thống và môi trờng của nó Hình bên

miêu tả một mô hình trờng hợp sử dụng.

use case

Trờng hợp sử dụng có một tập các tính chất

Các tính chất đó đợc t liệu hoá trong

Actor name

-

-

Mô hình trờng hợp sử dụng làm nền tảng cơ sở cho mọi hoạt động phân tích,thiết kế và kiểm thử các hành động của hệ thống Nếu cái gì đó không nằm trong môhình trờng hợp sử dụng thì không nên nằm trong hệ thống của chúng ta Thực chất,

hệ thống ta đang xây dựng nên bám theo mô hình trờng hợp sử dụng

Mô hình trờng hợp sử dụng đợc tạo ra trong khung nhìn trờng hợp sử dụngcủa Rose và có thể bao gồm những thành phần sau: Các biểu đồ trờng hợp sử dụng,luồng các sự kiện trờng hợp sử dụng, thông tin bổ sung và các biểu đồ hoạt động

Mô hình trờng hợp sử dụng đợc tạo ra bằng việc sử dụng các vật phẩm

(artifacts) đợc phát triển bởi kiến trúc phần mềm và ngời phát triển hệ thống trong

sự phối hợp với khách hàng Một vật phẩm là thông tin đợc đa ra (produced), đợc

sửa lại (modified), hoặc đợc sử dụng (used) bởi một tiến trình Nó xác định mộtvùng của các trách nhiệm và là chủ đề cho phiên bản điều khiển Một vật phẩm có

thể là một mô hình, một thành phần mô hình hoặc một tài liệu

Lợi ích của mô hình trờng hợp sử dụng là ở chỗ:

 Mô hình đợc sử dụng để làm phơng tiện truyền thông giữa những ngời sử dụngcuối và các chuyên gia trong vùng vấn đề

 Mô hình đợc sử dụng để xác định: Ai tơng tác với hệ thống và hệ thống nên làmgì

 Mô hình đợc sử dụng để kiểm tra lại: Tất cả các yêu cầu đang nắm giữ, giúpnhóm phát triển hiểu rõ các yêu cầu Hình 4.1 minh hoạ lợi ích đã nói trên

Hình 4.1 UC và tiến trình phát triển

Có nhiều cách để mô hình hoá hành vi của một hệ thống, mỗi cách có thểphục vụ một mục đích khác nhau Tuy nhiên, vai trò quan trọng của mô hình trờnghợp sử dụng là truyền đạt hành vi của hệ thống với khách hàng hoặc ngời sử dụngcuối Vì vậy, mô hình phải dễ hiểu

Các thành phần chính trong mô hình hoá trờng hợp sử dụng gồm: tác nhân(actor), trờng hợp sử dụng (use case), mối liên kết

4.2 Tác nhân và cách tìm kiếm tác nhân

4.2.1 Tác nhân (actor) là gì?

Để hiểu một cách đầy đủ mục đích của hệ thống chúng ta phải biết hệ thốngliên quan đến những ai Các kiểu ngời sử dụng khác nhau đợc tợng trng nh là cácactor

Tác nhân là một thực thể (có thể là một ngời hoặc một hệ thống hay thiết

bị phần cứng khác), là tất cả những gì bên ngoài cần tơng tác với hệ thống của chúng ta Tơng tác là sự trao đổi thông tin Tác nhân tợng trng cho các vai trò một

ngời sử dụng của hệ thống có thể làm Tác nhân có thể là một ngời lấy thông tincũng có thể là một ngời nhận thông tin một cách bị động

Sự khác nhau giữa một actor với một ngời sử dụng hệ thống cụ thể là ở chỗ:Một actor tợng trng cho một lớp những ngời sử dụng hơn là một ngời sử dụng thực

sự Ví dụ: Trong hệ thống “bất động sản nhà ở” thì ngời mua tơng lai là tác nhân,

nhng Anh A, Chị B không phải là tác nhân

Nhiều ngời sử dụng có thể cùng làm một vai trò Trong một số trờng hợp mộtngời duy nhất cũng đợc mô hình hoá nh vai trò của một actor; một ngời sử dụngcũng có thể hoạt động nh là nhiều actor Tức là, cùng một ngời có thể mang nhữngvai trò khác nhau Ví dụ: Thầy Lê Hoài Nam là một giáo s đại học, nhng vẫn có thể

là một sinh viên khi ông đăng kí vào một khoá học nào đó Vì thế Thầy Lê Hoàinam làm hai vai trò một là giáo s và một là sinh viên trong hệ thống “Đăng kí khoáhọc”

4.2.2 Tìm kiếm các tác nhân nh thế nào?

Hãy nghĩ về những cá nhân sẽ sử dụng hệ thống, rồi nghĩ cách phân loại nh

thế nào? Sau đây là những câu hỏi có ích trong việc xác định các tác nhân:

 Ai sẽ cung cấp, sử dụng hoặc di chuyển thông tin?

 Những ngời sử dụng, ngời mà thi hành các chức năng chính của hệ thống

 Những ngời sử dụng thi hành chức năng thứ hai của hệ thống

 Phần cứng bên ngoài mà hệ thống sử dụng

 Các hệ thống khác tơng tác với hệ thống

4.3 Phân tích trờng hợp sử dụng (Use Case-UC)

4.3.1 UC là gì?

Theo đúng nguyên văn: “A use case can be defined as: a sequence of

actions a system performs that yields an observable result of value to a particular actor” (Rational University, Principle of Object Technology)

Một trờng hợp sử dụng là một chuỗi các hành động hệ thống thực hiện, nómang lại một kết quả của giá trị có thể quan sát đợc tới một tác nhân cụ thể

Theo Ivar Jacobson, UC mô tả ai đó sử dụng hệ thống nh thế nào, mô tả tơng

tác giữa ngời sử dụng với hệ thống phần mềm để thực hiện các thao tác giải quyếtcông việc cụ thể nào đó

UC không cho biết hệ thống làm việc bên trong nh thế nào Nó không phải làthiết kế, cũng không phải là kế hoạch cài đặt, nó là một phần của vấn đề giải quyết.Tiến trình của hệ thống đợc chia nhỏ thành các UC để có thể nhận ra từng bộ phậncủa nó một cách rõ ràng và để nhiều ngời có thể cùng xử lý

UC là nền tảng của hệ thống Việc tìm ra đầy đủ các UC đảm bảo rằng hệthống xây dựng sẽ đáp ứng mọi nhu cầu của ngời sử dụng Mỗi UC là tập hành

động Mỗi hành động là cái gì đó mà hệ thống phải làm, nó là hạt nhân đợc hệ thốngthực hiện hoàn toàn hay không đợc thực hiện phần nào

4.3.2 Tìm kiếm các UC nh thế nào?

Việc xác định và hiểu rõ các yêu cầu hệ thống là rất khó khăn vì khối lợngthông tin liên quan đến hệ thống là rất lớn Khái niệm UC đợc đa ra để tập trung vàobiểu thị các yêu cầu từ phía ngời ứng dụng, xuất phát từ quan điểm là hệ thống đợcxây dựng trớc hết là để phục vụ ngời sử dụng nó.

Trong phơng pháp hớng đối tợng, câu hỏi đặt ra khi bắt đầu thực hiện dự ánthờng là: Tìm kiếm UC nh thế nào? Khách hàng là ngời hiểu rõ hệ thống sẽ thựchiện nh thế nào Vì thế cách tốt nhất để tìm kiếm các UC là phỏng vấn ngời sử dụng

và các tài liệu của họ Việc phỏng vấn ngời sử dụng phải bằng khái niệm, ngôn từcủa lĩnh vực vấn đề và của chính ngời sử dụng Việc phân tích vai trò của cácchuyên gia lĩnh vực là rất quan trọng bởi họ có nhiều kinh nghiệm trong việc thiết

kế các sản phẩm tơng tự, họ có thể giúp ta hiểu chi tiết về ngời sử dụng Thực tế,không phải ngời sử dụng nào cũng có khả năng mô tả rõ ràng cách mà họ muốn sửdụng hệ thống Những cái họ biết thờng nhiều hơn cái họ đang diễn giải Chính UC

và các biểu đồ UC là công cụ tốt nhất để giúp ngời sử dụng nói về hệ thống từ gócnhìn của họ

Thờng thì tiến trình tìm kiếm UC bắt đầu sau khi tìm kiếm tác nhân Các câutrả lời cho những câu hỏi sau đây sẽ giúp ta tìm ra các UC:

 Với mỗi tác nhân, hãy xác định các công việc hệ thống sẽ liên quan đến, tứctác nhân yêu cầu hệ thống thực hiện chức năng nào ?

 Tác nhân cần đợc thông báo về các sự cố xảy ra trong hệ thống hay không?

 Tác nhân sẽ cần thông báo cho hệ thống về những thay đổi bên ngoài, đột ngộtkhông?

 Thông tin phải đợc sửa đổi và tạo ra trong hệ thống là gì ?

 Hệ thống cần các thông tin vào/ra nào ? vào/ra đi đến đâu hay từ đâu?

Các câu trả lời cho các câu hỏi đó tợng trng cho các luồng các sự kiện mà ta

sẽ nói đến ở phần tiếp theo

Việc xác định các UC là công việc lặp đi lặp lại Các UC đầu tiên là nguyênthuỷ, và chúng ta sẽ phải thay đổi chúng cho đến khi chúng ổn định Nếu sự nhìnnhận hoặc các yêu cầu của hệ thống bị thiếu hụt hoặc nếu phân tích hệ thống bị méo

mó, chức năng của hệ thống sẽ không rõ ràng Vì thế chúng ta phải thờng xuyên sửa

đổi các UC đã tìm đợc Thêm nữa, đợc chuẩn bị để thêm, dịch chuyển, kết hợp vàphân chia các trờng hợp sử dụng trớc khi đi đến một phiên bản cuối cùng Chúng ta

sẽ hiểu tốt các UC khi đã mô tả chúng một cách chi tiết

Cách tôt nhất để tìm các UC là quan tâm đến cái mà mỗi actor yêu cầu hệthống Bởi hệ thống chỉ tồn tại cho những ngời sử dụng nó và nên dựa trên cơ sở cácnhu cầu của ngơì sử dụng

Sau khi tìm UC thì phải gán tên cho chúng Đặt tên UC theo khái niệm tácnghiệp (không sử dụng khái niệm kỹ thuật, chuyên môn) Sử dụng động từ, câungắn UC độc lập với cài đặt (độc lập với ngôn ngữ lập trình), nó có thể đợc mô tảbằng ngôn ngữ lập trình Java, C++, Visual Basic, văn bản trên giấy hay bằng công cụphần mềm nào đó (Rational Rose)

Sau khi xác định xong UC cho hệ thống thì cần phải kiểm tra xem liệu chúng

đã đợc phát hiện hết cha, bằng cách trả lời các câu hỏi sau:

 Mỗi yêu cầu chức năng có ở trong ít nhất một UC ? Nếu yêu cầu chức năngkhông có ở UC nào thì nó sẽ không đợc cài đặt sau này

 Đã xem xét mọi tác nhân tơng tác với hệ thống cha ?

 Tác nhân cung cấp cho hệ thống thông tin nào?

 Đã nhận biết mọi hệ thống bên ngoài mà hệ thống này tơng tác cha?

 Thông tin nào hệ thống bên ngoài nhận và gửi cho hệ thống này?

4.4 Tìm hiểu các đặc tả tờng hợp - sử dụng (Use-case Specifications)

Các đặc tả trờng hợp - sử dụng bao gồm:

- Tên

- Sự mô tả ngắn gọn

- Luồng các sự kiện (Flows of Events)

- Các mối quan hệ

- Các biểu đồ hoạt động và trạng thái

- Các biểu đồ trờng hợp- sử dụng

- Các yêu cầu cụ thể

- Các điều kiện trớc (pre-conditions)

- Các điều kiện sau (post-conditions)

- Các biểu đồ khác

4.4.1 Sự mô tả ngắn gọn

Mô tả mục đích và vai trò của của một trờng hợp sử dụng trong một vài dòng

4.4.2 Luồng các sự kiện

Là những mô tả theo đúng nguyên văn của cái mà hệ thống phải làm Mục

đích của luồng sự kiện là làm tài liệu luồng logic thông qua các UC Tài liệu luồng

sự kiện mô tả chi tiết ngời sử dụng sẽ làm gì và hệ thống sẽ làm gì Mỗi UC cónhiều luồng sự kiện: luồng chính và luồng phụ (các biến thể thông thờng, các trờnghợp lẻ, các luồng chấp nhận việc điều khiển các tình huống lỗi), không thể thể hiệnmọi chi tiết của UC trong một luồng sự kiện

Một luồng sự kiện của trờng hợp sử dụng:

- Chứa đựng thông tin quan trọng nhất để mô hình hoá trờng hợp sử dụng

- Nó sẽ mô tả luồng của trờng hợp sử dụng một cách rõ ràng đầy đủ mà mộtngời nằm ngoài hệ thống cũng có thể hiểu đợc

- Luồng sự kiện làm xuất hiện cái mà hệ thống phải làm nhng không thiết kế

hệ thống làm nh thế nào để thực hiện hành vi đã yêu cầu

- Nó là hớng chỉ đạo nội dung của một trờng hợp sử dụng

- Không mô tả chi tiết về giao diện ngời sử dụng trừ khi nó cần thiết để hiểu

đ-ợc hành vi của hệ thống

- Mô tả luồng sự kiện dọc theo trờng hợp sử dụng và cái gì không xảy ra trong

UC hoặc ở bên ngoài hệ thống

- Tránh dùng thuật ngữ mơ hồ nh: “ ví dụ nh ”, “ vân vân ”, và “ thông tin ”

- Miêu tả luồng sự kiện Tất cả các câu hỏi “ What ” nên đợc trả lời Nhớ rằngnhững ngời thiết kế kiểm tra sẽ sử dụng văn bản này để xác định rõ các trờnghợp kiểm tra

Kịch bản (scenario) chỉ ra luồng sự kiện trong một thể hiện (instance) cụ thể

của UC Nó là trình tự hành động cụ thể mô tả hành vi Kịch bản đi xuyên suốt UCtheo nhánh chính, nhánh phụ hoặc nhánh đặc biệt của đờng đi Kịch bản là một thểhiện của UC, tơng tự đối tợng là thể hiện của lớp, nó cho biết cách sử dụng hệ thống.Khách hàng hiểu hệ thống phức tạp thông qua tập kịch bản mô tả hành vi của nó Sốkịch bản nhiều bằng những sự cần thiết để hiểu hệ thống đang phát triển

4.4.3 Các mối quan hệ (relationships)

Các mối quan hệ là các liên kết giao tiếp (communicate associations) Gồm

có quan hệ sử dụng và quan hệ mở rộng là các quan hệ tham gia trong biểu đồ trờnghợp sử dụng Các mối liên kết có thể tồn tại giữa một actor và một UC và giữa các

UC với nhau Nó cũng có thể tồn tại giữa các lớp và các giao diện Trong UML mộtmối liên kết có ký pháp là một đờng thẳng có mũi tên hoặc không có mũi tên Cómũi tên thể hiện mối quan hệ một chiều, không có mũi tên thể hiện mối quan hệ haichiều

Quan hệ giao tiếp (communicate).Trong UML, quan hệ giao tiếp đợc thể

hiện bằng mũi tên Ví dụ hình 4.4.a miêu tả tác nhân ngời kinh doanh bất động sản

có quan hệ với hệ thống để chạy chức năng duy trì các dự án cá nhân và chức năngliệt kê tính chất Trong UML, quan hệ giao tiếp đợc vẽ bằng mũi tên và có từ

Maintain personal planner

Hình 4.4.a Quan hệ giao tiếp

Quan hệ sử dụng (Use Relationship): Quan hệ sử dụng đợc gọi là quan hệ

gộp (include) Quan hệ sử dụng cho phép một UC sử dụng chức năng của UC khác.

Quan hệ này thờng đợc dùng để mô hình hoá một số chức năng sử dụng lại, dùngchung hai hay nhiều UC Thí dụ, hình 4.4.b trong hệ thống máy rút tiền tự động, hai

UC rút tiền và gửi tiền vào ngân hàng cần xác nhận khách hàng và số căn c ớc cánhân trớc khi thực hiện giao dịch Do vậy chức năng xác nhận này có thể đặt trongmột UC riêng, gọi là xác nhận khách hàng, vào bất kỳ thời điểm nào, UC cần xácnhận khách hàng thì phải dùng UC này

Quan hệ mở rông (extends) Quan hệ mở rộng cho phép UC mở rộng tuỳ ý

chức năng do UC khác cung cấp Nó chỉ ra rằng một điều kiện nào đó một UC đợc

mở rộng bằng UC khác( mở rộng là khả năng gộp vài hành vi của UC tổng quát hơn

để sử dụng lại) Nó tơng tự nh quan hệ uses ở chỗ cả hai quan hệ đều tách phần chứcnăng chung ra một UC mới, đó là UC trừu tợng Trong UML, quan hệ mở rộng đợc

vẽ bằng mũi tên và có từ <<extends>>

Hình 4.4.c mô tả UC rút tiền đôi khi sử dụng chức năng trong UC rút tiền nhanh.Chie và chỉ khi khách hàng chọn thuộc tính rút tiền nhanh dành cho rút số tiềnkhông lớn thì UC này mới chạy

<<extends>>

rút tiền rút nhanh

Hình 4.4.c Quan hệ mở rộng

Quan hệ tổng quát hoá tác nhân: Quan hệ tổng quát hoá tác nhân đợc sử

dụng để chỉ ra một vài tác nhân có một số cái chung Thí dụ hệ thống có hai loạikhách hàng, khách hàng cá nhân và khách hàng tập thể Biểu đồ trên hình 4.4.d môtả hai loại khách hàng này khách hàng cá nhân và khách hàng tập thể là tác nhân cụthể Ta có thể định nghĩa loại tác nhân tổng quát (khách hàng) và đặc biệt hoá chúngnhờ quan hệ tổng quát hoá Tác nhân khách hàng là tác nhân trừu tợng Ta có thểtiếp tục chia nhỏ, thí dụ khách hàng tập thể thành các công ty t nhân và tổ chứcchính phủ để xây dựng hệ thống tổng quát hoá

Hình 4.4.d Quan hệ tổng quát hoá tác nhân

4.4.4 Biểu đồ hoạt động (Activity Diagram) và các thành phần của nó

Một biểu đồ hoạt động trong mô hình UC đợc sử dụng để nắm giữ các hoạt

động trong một UC Nó cần thiết trong một biểu đồ luồng, nó chỉ ra luồng điềukhiển từ hoạt động này tới hoạt động khác

Luồng công việc (workflow) của một trờng hợp sử dụng mô tả những cái cầnthiết phải làm bằng việc hệ thống cung cấp giá trị phục vụ actor đang tìm kiếm Biểu

đồ hoạt động bao gồm một chuỗi các hoạt động cùng nhau, đa ra một điều gì đó vềactor Luồng công việc gồm một luồng chính và nhiều luồng phụ khác Cấu trúc củaluồng công việc đợc mô tả bằng đồ thị với sự trợ giúp của biểu đồ hoạt động