CHƯƠNG 4

:

UML và mô hình hoá hướng đối tượng Chương 4: UML và mô hình hoá hướng đối tượng.................... 1

CHƯƠNG 4 : UML (UNIFIED MODELING LANGUAGE) VÀ MÔ HÌNH HOÁ HƯỚNG ĐỐI TƯỢNG (OBJECTORIENTED MODELING)..........................................................3 I Mục tiêu..................................................................................... 3 II UML là gì? .............................................................................. 3 II.1 Ba dạng của UML.............................................................. 4 II.1.1 Ngôn ngữ (Language)........................................................ 4 II.1.2 Mô hình (Model)................................................................ 7 II.1.3 Hợp nhất (Unified)............................................................. 8 II.2 Mục tiêu và phạm vi.......................................................... 8 II.3 Lịch sử phát triển............................................................. 10 II.3.1 Giai đoạn manh mún ....................................................... 10 II.3.2 Giai đoạn của sự hợp nhất ............................................... 11 II.3.3 Giai đoạn của sự chuẩn hoá ............................................ 11 II.3.4 Giai đoạn duyệt lại........................................................... 11 II.3.5 Giai đoạn của sự công nghiệp hoá................................... 12 III UML và quy trình................................................................. 12 III.1 Áp dụng cách tiếp cận theo mô hình thác nước (waterfall approach)................................................................................ 13 III.2 Áp dụng cách tiếp cận lặp (Iterative Approach)............. 14 III.2.1 Use cases.........................................................................17 III.2.2 Kiểu kiến trúc (Architecture).......................................... 17 III.2.3 Sự rủi ro (Risk)............................................................... 18 IV Mô hình hoá hướng đối tượng (Object-Oriented Modeling) 19
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải
Trang 1

CHƯƠNG 4:

UML và mô hình hoá hướng đối tượng IV.1 Xác định yêu cầu hệ thống quản lý dự án (Project Management System Requirements)...................................... 20

IV.1.1 Bộ chữ cái (Alphabets), từ (words), và câu (sentences). 22 IV.1.2 Alphabet......................................................................... 23 IV.1.3 Words............................................................................. 23 IV.1.4 Sentences........................................................................ 25 IV.2 Mô hình hướng đối tượng (Object-Oriented Paradigm) 27 IV.2.1 Concepts......................................................................... 27 IV.2.2 Các nguyên lý cơ bản (Principles)..................................35 V Phần mềm (Software)............................................................ 47 VI Tài liệu tham khảo ............................................................... 47

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải

Trang 2

CHƯƠNG 4:

UML và mô hình hoá hướng đối tượng

CHƯƠNG 4 : UML (UNIFIED MODELING LANGUAGE) VÀ MÔ HÌNH HOÁ HƯỚNG ĐỐI TƯỢNG (OBJECT-ORIENTED MODELING)
I Mục tiêu
Mục tiêu của chương này nhằm giúp bạn: • • • Tìm hiểu về ngôn ngữ mô hình hoá thống nhất (UML). Tìm hiểu mô hình hướng đối tượng Cách kết hợp phân tích hướng đối tượng với UML.

II UML là gì?
UML là một ngôn ngữ trực quan với mục tiêu sử dụng cho việc mô hình hoá và truyền đạt các ý tưởng về hệ thống thông qua việc sử dụng các lược đồ (diagrams) và các văn bản. Ví dụ, hình 4.1 truyền đạt thông tin sau: Một manager lãnh đạo một nhóm thực hiện dự án. Mỗi manager có một tên, số điện thoại, khởi đầu dự án, kết thúc dự án.
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải
Trang 3

CHƯƠNG 4:

UML và mô hình hoá hướng đối tượng Mỗi dự án có một tên (name), ngày bắt đầu (start date), và ngày kết thúc (end date). Mỗi nhóm làm việc (team) có một mô tả, đó là thông tin được quan tâm liên quan đến nhóm. Nếu bạn cảm thấy rằng hình II.1 không tạo nên ý nghĩa đầy đủ thì cũng đừng qua lo lắng, bởi chúng ta sẽ khảo sát tỉ mỉ hơn hình này và UML trong trình bày chi tiết hơn ở phần sau của chương này.

(Hình II.1)

II.1 Ba dạng của UML
Như chúng ta đã biết, UML là chữ viết tắt của Unified Modeling Language. Mỗi từ nói lên một khía cạnh quan trọng của UML. Các phần trình bày sau đây sẽ đề cập đến các khía cạnh này sẽ được đề cập sau đây với thứ tự đảo ngược.

II.1.1 Ngôn ngữ (Language)
Một ngôn ngữ cho phép chúng ta truyền đạt ý tưởng về một chủ đề. Trong phát triển hệ thống, chủ đề bao gồm các yêu cầu và hệ thống. Nếu không có một ngôn ngữ chung thì các
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải
Trang 4

để biểu trưng cho phép cộng và phép trừ. các quả cam. việc trình bày số 5 có thể được tương ứng với 5 trái táo. chúng ta thường sử dụng “ngôn ngữ đếm . ngôn ngữ đếm sử dụng 365 đối tượng Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 5 . Các phép toán cộng và trừ tương ứng với việc thêm vào hoặc lấy ra các quả táo.2) Bây giờ chúng ta xét hai ngôn ngữ này đối với việc truyền đạt số lượng xác định các ngày cho một dự án. Những người lớn chúng ta thì khác. hay một số loại khác để trình bày số lượng. thích sử dụng ngôn ngữ số học hơn.2 trình bày sự tương phản giữa ngôn ngữ đếm của trẻ con với ngôn ngữ số học trừu tượng hơn được người lớn sử dụng. Đứa trẻ có thể dựa vào số lượng các quả táo. những viên sỏi. Làm theo và biểu thị số lượng của số năm. Ngôn ngữ. Làm theo và biểu thị số lượng phức tạp hơn. và sử dụng các toán tử + và . mà tiêu biểu là số lượng lớn sủ dụng sử dụng một chuỗi các chữ số Arabic. Ví dụ. Hình II.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng thành viên của nhóm làm việc thật khó khăn khi giao tiếp và cộng tác với nhau để phát triển thành công một hệ thống. Đối với đứa trẻ.counting language" để hướng dẫn trẻ con đếm và làm các phép tính đơn giản. trong ý nghĩa rộng. (Hình II. không phải bao giờ cũng bao gồm các từ được viết. ngôn ngữ đếm sử dụng năm đối tượng trong khi ngôn ngữ số học sử dụng chuỗi “5”. 365.

Constructing : bao gồm việc sử dụng sự mô tả trực quan này để xây dựng hệ thống. nó giúp cho ý tưởng cài đặt và thực tế cài đặt được nhất quán. rõ ràng. Bằng việc sử dụng các ngôn ngữ có ý nghĩa hơn. xây dựng (constructing). đầy đủ và thông suốt trong quá trình phát triển phần mềm. và tài liệu hoá các quy trình nhân tố của hệ thống. Một quy trình nhân tố hệ thống là cách tiếp cận các trọng tâm trên một hệ thống. nó được cho là có ý nghĩa hơn ngôn ngữ đếm.visualizing). biểu thị số lượng với việc sử dụng số học ngắn gọn hơn so với ngôn ngữ đếm. • • Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 6 . Để biểu thị số lượng bốn và phân nửa.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng (điều này có thể không khả thi). Bởi vì số học cho phép chúng ta dễ dàng và thực tế hơn trong việc biểu thị phạm vi số lượng rộng hơn ngôn ngữ đếm. trực quan hoá (mô hình hoá trực quan . nó nhằm giúp giải quyết các vấn đề phân tích. trong khi ngôn ngữ số học sử dụng chuỗi “365”. chúng ta có thể truyền đạt thông tin phức tạp về chủ đề phức tạp trong một kiểu ngắn gọn hơn. bao gồm các bước sản sinh và duy trì dựa trên các yêu cầu hệ thống phải đáp ứng. ngôn ngữ đếm sử dụng bốn đối tượng và một nửa của đối tượng (điều này lại cũng có thể không khả thi) và ngôn ngữ số học sử dụng chuỗi "4. Phát biểu hơi có phần hình thức. Visualizing : bao gồm việc sử dụng các lược đồ để thông qua đó truyền đạt ý tưởng mô hình (mô hình là ý tưởng và các lược đồ có vai trò trình bày ý tưởng). giống như cách mà một bản thiết kế nhà được sử dụng để xây dựng một building. Tương tự như vậy. cài đặt hệ thống một cách chính xác. thiết kế.specifying). • Specifying : bao gồm việc tạo một mô hình mô tả một hệ thống.5". UML là một ngôn ngữ dùng để cụ thể hoá (đặc tả .

Ví dụ. phân tích các yêu cầu. UML là ngôn ngữ mô hình hoá chuẩn tuy nhiên chính tự nó không là một quy trình phát triển phần mềm (Nó độc lập với ngôn ngữ lập trình và quy trình phát triển phần mềm). và vân vân được hiểu như là các phương pháp kỹ thuật. Các sưu liệu (Artifacts) là sản phẩm công việc được sản sinh và sử dụng bên trong một quy trình. Không có mô hình.CHƯƠNG 4: • UML và mô hình hoá hướng đối tượng Documenting : sử dụng các mô hình và lược đồ để tài liệu hoá lại kiến trúc của hệ thống bao gồm các hiểu biết về các yêu cầu và quy trình xuyên suốt toàn bộ hệ thống. Một quy trình áp dụng tập hợp các bước được mô tả bởi một phương pháp luận (methodology) giải quyết một vấn đề và phát triển một hệ thống thoả mãn các yêu cầu của người dùng nó.2 Mô hình (Model) Mô hình (model) có thể được hiểu như là một cách mô tả một chủ đề. thật là khó khăn để các thành viên nhóm làm việc có cách hiểu chung về các yêu cầu và cái nhìn đối với hệ thống và họ sẽ rất khó khăn khi suy Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 7 .1. Nó là sự đơn giản hoá thế giới thực. để mô hình và biểu diễn số lượng năm. bao gồm tài liệu cho sự giao tiếp giữa các nhóm làm việc trên một hệ thống và hệ thống vật lý của chính nó. Các cách khác nhau đối với việc thu thập và sử dụng các yêu cầu. trong khi ngôn ngữ số học sử dụng chuỗi "5". một đối tượng. như đã đề cập ở phần trước. II. ngôn ngữ đếm sử dụng năm đối tượng. thiết kế một hệ thống. và vân vân. trong khi một phương pháp luận nhằm vào toàn bộ quy trình phát triển xuất phát từ việc thu thập các yêu cầu cho đến khi hệ thống được tạo nên sẵn sàng đối với những người dùng nó. thiết kế. phân tích. Một phương pháp (method) chỉ nhằm vào một phần của quy trình phát triển. Mỗi loại lược đồ UML cũng được hiểu như là một phương pháp kỹ thuật mô hình hoá. Một mô hình captures một tập hợp các ý tưởng được hiểu như là sự trừu tượng hoá liên quan các đối tượng của nó. Ví dụ như: thu thập các yêu cầu.

UML cung cấp một nền tảng chuẩn trong việc phân tích thiết kế.3 Hợp nhất (Unified) Thuật ngữ unified ám chỉ đến sự kiện tổ chức Object Management Group (OMG). chúng ta sẽ sẽ bị chôn vùi bởi số lượng thông tin. chúng ta có thể hiểu được động cơ thúc đẩy đằng sau UML. chúng ta có thể quản lý tốt hơn toàn bộ các rắc rối phức tạp trong phát triển hệ thống. Với việc quản lý cẩn thận những trừu tượng hoá nào tạo nên mô hình. chúng được chi tiết như thế nào. và bổ sung giải pháp. Các mục tiêu của OMG đối với UML: • • • • Sẵn sàng để dùng (Ready to use) Có ý nghĩa (Expressive) Đơn giản (Simple) Rõ ràng. những thông tin có thể làm cản trở sự xúc tiến của chúng ta. nếu chúng ta cố gắng trình bày mọi thứ của vấn đề tất cả đồng thời. và khi nào capture chúng trong suốt quá trình phát triển. chính xác (Precise) Trang 8 Phân tích thiết kế hệ thống – GV: Trần Xuân Hải . II.2 Mục tiêu và phạm vi Với việc tìm hiểu các mục tiêu của OMG và phạm vi đối với UML. Với việc hợp nhất các kí hiệu sử dụng. Vì vậy. thật là quan trọng đối với việc tập trung nắm bắt các thông tin có liên quan đã được yêu cầu để hiểu vấn đề trong tầm kiểm soát. đồng thời loại trừ mọi thông tin không thích hợp. Khi tạo một mô hình. giải quyết vấn đề.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng xét tác động của những thay đổi xảy ra trong khi triển khai hệ thống. một tổ chức tiêu chuẩn hoá quốc tế công nhận.1. II. Điều này giúp các thành viên mới của nhóm nhanh chóng trở nên hữu ích trong việc góp phần phát triển hệ thống.

Riêng biệt nhau. nhưng gắn với nhau.Object Constraint Language (OCL).CHƯƠNG 4: • • • UML và mô hình hoá hướng đối tượng Có thể mở rộng (Extensible) Không phụ thuộc sự cài đặt (Implementationindependent) Không phụ thuộc quy trình (Process-independent) Bởi đang sẵn sàng để dùng. ví dụ như Java hay . Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 9 . phương pháp kỹ thuật mô hình hoá đối tượng của James Rumbaugh (OMT) và phương pháp công nghệ phần mềm hướng đối tượng của Ivar Jacobson (Object-Oriented Software Engineering (OOSE)) với những công nghệ thực hành tốt nhất của kỹ nghệ công nghệ và hê thống thông tin. đơn giản và rõ ràng chính xác. chúng hình thành một phương pháp luận khá đầy đủ. một ngôn ngữ phụ cho việc gắn các điều kiện mà những phần tử của một mô hình phải đáp ứng đối với mô hình để sẽ được xem xét đúng (Sẽ đề cập đến ngôn ngữ này ở bài khác). chúng chỉ là các phương pháp. Một ngôn ngữ mở rộng cho phép chúng ta định nghĩa các khái niệm mới. UML có thể nagy lập tức đựoc sử dụng để phát triển các dự án. tương tự việc đưa vào các từ mới và việc mở rộng từ vựng của một ngôn ngữ tự nhiên. có đầy đủ ý nghĩa. Một ngôn ngữ implementation-independent có thể được sử dụng không phụ thuộc bất kỳ công nghệ cài đặt nào. Một ngôn ngữ process-independent có thể được sử dụng với nhiều loại quy trình khác nhau. OMG đưa vào ngôn ngữ gọi là ngôn ngữ ràng buộc đối tượng .NET. Để làm cho các mô hình triển khai rõ ràng chính xác. Phạm vi khi tạo UML của OMG bao gồm việc kết hợp của ba ngôn ngữ mô hình hoá trong các phương pháp phát triển hệ thống nổi bật nhất – Phương pháp Booch ’93 của Grady Booch.

Với việc tìm hiểu các giai đoạn này. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 10 .1 Giai đoạn manh mún Khoảng giữa những năm 1970 và 1990. Phương pháp Object-Oriented Software Engineering (OOSE) của Ivar Jacobson nhấn mạnh việc phân tích các yêu cầu và business engineering. công nghệ phân mảnh xung quanh ba phương pháp này và một số phương pháp khác. • • Giống như phương pháp hướng đối tượng bắt đầu tiến triển xuất phát từ phương pháp cấu trúc. bạn có thể hiểu tại sao UML nổi bật lên và ngày nay nó vẫn đang tiến triển như thế nào.3.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng II. các tổ chức bắt đầu hiểu được giá trị của phần mềm đối với hoạt động của doanh nghiệp tuy nhiên chỉ có một tập hợp manh mún các phương pháp kỹ thuật cho việc sản sinh và duy trì phần mềm.3 Lịch sử phát triển Quá trình phát triển của UML bao gồm năm giai đoạn thời điểm phân biệt. ba phương pháp nổi bật lên là: • Phương pháp Booch ‘93 của Grady Booch (xuất phát từ Booch ‘91) nhấn mạnh việc thiết kế và xây dựng hệ thống phần mềm. Phương pháp Object Modeling Technique (OMT) -2 của James Rumbaugh (xuất phất từ OMT-1) nhấn mạnh việc phân tích hệ thống phần mềm. Nằm trong số đó các phương pháp và kỹ thuật nổi bật tập trung vào việc sản sinh và duy trì phần mềm một cách hiệu quả hơn (mỗi chúng có riêng của nó ngôn ngữ mô hình hoá). II. Những người đang làm việc theo một phương pháp nào đó sẽ khó mà hiểu được những sưu liệu được sản sinh với việc sử dụng một phương pháp khác.

1 được công nhận.3. Một số chương trình chuyên dụng phục vụ cho UML cũng đã được ra đời. Umbrello (Linux). công ty phần mềm Rational đã hình thành nên hiệp hội các đối tác UML (UML Partners Consortium).2 Giai đoạn của sự hợp nhất Khoảng giữa những năm 1990 và 1997. Tổ chức OMG đã chấp nhận UML1. nhóm nghiên cứu phân tích thiết kế hướng đối tượng của OMG đã đưa ra một thỉnh cầu về việc thiết lập một chuẩn định nghĩa ý nghĩa các khái niệm kỹ thuật hướng đối tượng cho các công cụ hỗ trợ phân tích và thiết kế hướng đối tượng.3 Giai đoạn của sự chuẩn hoá Vào thời điểm nửa sau của năm 1997. Khi mà các tổ chức bắt đầu thấy được các giá trị của UML. Bởi những kết quả cố gắng hợp nhất của họ. phối hợp với Grady Booch tại công ty phần mềm Rational thống nhất các phương pháp của họ.0 của UML tới tổ chức OMG như là môt trong số những đáp trả đối với đề xuất ban đầu của tổ chức này.3. như IBM Rational Rose. Cùng với một số các tổ chức khác. Argo UML. James Rumbaugh.0 được đưa ra. II. Visual Paradigm for UML. the UML 1. Tất cả các đáp trả đối với các đề xuất ban đầu được kết hợp vào trong phiên bản 1. và sau đó là Ivar Jacobson.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng II. một số phiên bản khác của UML đã được đưa ra. phiên bản UML 1. và những người cùng hợp tác này đã đệ trình phiên bản 1.4 Giai đoạn duyệt lại Sau khi UML 1.1 được đưa ra. II.1 của UML. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 11 .3. chúng được hiểu như là Bộ ba những người bạn (Three Amigos).1.

OMG đề xuất chuẩn UML với mục tiêu chuẩn hoá quốc tế như là một Publicly Available Specification (PAS) qua tổ chức quốc tế về tiêu chuẩn hoá (ISO). Nói chung. bạn có thể hiểu tốt hơn cách tiếp cận tốt nhất trong việc học UML. Các hoạt động triển khai để tạo nên một hệ thống sẵn dùng đối với những người dùng nó Có nhiều kiểu tiếp cận đối với việc áp dụng các hoạt động này để triển khai hệ thống. Với việc hiểu mối liên quan như thế nào của UML đối với quy trình và loại quy trình mà các tác giả UML hướng đến. một loại quy trình bất kỳ tham chí không có các đặc trưng này – vẫn có thể sử dụng UML. Các hoạt động kiểm thử để xác nhận rằng hệ thống thoả các yêu cầu của nó. kiểu tiếp cận theo Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 12 .3. Theo truyền thống.5 Giai đoạn của sự công nghiệp hoá Đồng thời với giai đoạn duyệt lại. III UML và quy trình Mặc dù UML độc lập với quy trình. Các hoạt động thiết kế (Design) để xác định một hệ sẽ phải làm như thế nào để thoả mãn các yêu cầu của nó.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng II. hướng kiến trúc. có tính lặp và tăng dần. Các hoạt động cài đặt để xây dựng một hệ thống. mỗi quy trình chu trình sống trong phát triển hệ thống bao gồm các loại hoạt động của chu trình sống sau: • • • • • • Các hoạt động thu thập yêu cầu nhằm nắm bắt được các yêu cầu với mục tiêu xác định rõ hệ thống sẽ phải làm gì. Các hoạt động phân tích để hiểu rõ các yêu cầu. nhưng các tác giả của nó muốn rằng một quy trình hướng use-case. Tuy nhiên.

Bên trong một cách tiếp cận như vậy. các hoạt động chu trình sống được thực thi trong sự tiếp nối đơn. cách tiếp cận lặp được dùng phổ biến hơn. các nhóm làm việc sử dụng UML với cách tiếp cận mô Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 13 . hơn cả trọng tâm hướng về hệ thống. Vì thế. Thường thì các kết quả khám phá (trong khoảng thời gian các hoạt động kiểm thử khi mà các mảng khác nhau của hệ thống được tích hợp) của các vấn đề liên quan chất lượng vẫn còn ẩn dấu trong khoảng thời gian của các hoạt động thiết kế và cài đặt. việc khám phá rằng hiệu suất của một hệ quản trị cơ sở dữ liệu cụ thể sẽ không đủ cho các ứng dụng sử dụng nó sau khi tất cả các ứng dụng đã được triển khai trình bày một vấn đề lớn. Mức độ hoàn tất đầy đủ ở đây thường khó khăn để đánh giá hay đạt được. UML có thể dễ dàng được sử dụng để truyền đạt các yêu cầu và sự mô tả của hệ thống. kiểm thử. có lẽ phát sinh 10 loại báo cáo khác nhau mỗi báo cáo xuất phát từ một yêu cầu riêng biệt. Xét một dự án bao gồm 10 yêu cầu. Tuy nhiên. Bởi vì các vấn đề như vậy được khám phá muộn trong quá trình triển khai có thể sẽ quá muộn để giải quyết chúng hay chúng có thể có thể quá tốn kém để giải quyết. . Ví dụ. Hiện nay. tất cả các yêu cầu được tiếp nhận và phân tích.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng mô hình thác nước thường được áp dụng. và triển khai theo một cách tuần tự. và toàn bộ hệ thống được thiết kế. Bên trong cách tiếp cận mô hình thác nước. tuyến tính đối với tất cả các yêu cầu. các mô hình UML cần phải hoàn tất rõ ràng tại mỗi bước. bởi vì các hoạt động được thực hiện trong một cách tiếp nối tuyến tính đơn đối với tất cả các yêu cầu. cài đặt.1 Áp dụng cách tiếp cận theo mô hình thác nước (waterfall approach) Khi áp dụng cách tiếp cận theo mô hình thác nước. III. nó lại ít rõ ràng hơn các ngôn ngữ lập trình. bởi vì trong khi UML là rõ ràng hơn ngôn ngữ tự nhiên.

bạn có thể kiểm tra và khám phá hiệu suất của một hệ quản trị cơ sở dữ liệu cụ thể và phát hiện ra rằng nó sẽ không đủ đáp ứng cho các ứng dụng sẽ sử dụng nó trước khi các ứng dụng đã được triển khai hoàn tất. R3. Điều này cho phép bạn hiểu tốt hơn các yêu cầu và từng bước phát triển một hệ thống thích hợp hơn qua việc tinh chế liên tục và gia tăng việc đạt được chi tiết hơn khi bạn thực hiện càng nhiều sự lặp lại. Qua mỗi chu kỳ hoạt động này hay một tập hợp các hoạt động này được hiểu là một hoạt động mang tính lặp. phân tích hai yêu cầu mà ta đã không phân tích trong hoạt động lặp trước R2 và R4. R7. Xét một dự án gồm có việc phát sinh 10 loại báo cáo khác nhau. III. Bên trong một cách tiếp cận lặp.2 Áp dụng cách tiếp cận lặp (Iterative Approach) Khi áp dụng phương pháp lặp. cài Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 14 . Chúng ta thu thập năm yêu cầu mới có tên từ R6. và một loạt các hoạt động lặp theo cách hành xử suy xét đúng từng bước đến các kết quả sau cùng theo mục tiêu cuối cùng của hệ thống. và theo đó tạo nên các sửa đổi thích hợp đối với các ứng dụng hay kiểm tra và khám phá việc sử dụng hệ quản trị cơ sở dữ liệu khác trước khi nó trở nên qua trễ hay quá tốn kém. và thiết kế. R8. Ví dụ. R4. R5 và phân tích ba trong năm yêu cầu này (có thể là R1. một loạy các hoạt động lặp có thể như sau: 1. 2. các tập con bất kỳ của các hoạt động chu trình sống được thực hiện ở các thời điểm khác nhau để hiểu tốt hơn các yêu cầu và dần dần phát triển hệ thống mạnh hơn. và R5). R10. Chúng ta nhận được năm yêu cầu có tên là R1.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng hình thác nước thường phải nổ lực trong sự cố gắng để xác định rõ liệu các mô hình UML của họ hoàn toàn đầy đủ hay chưa. R2. R8. R3.

một phương pháp luận được cần đến khi sử dụng UML trên những dự án thực tế.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng đặt. Một cách tiếp cận đối với sự triển khai hệ thống mang đến những lợi ích sau: • • • Chúng ta có thể quản lý sự phức tạp tốt hơn với việc xây dựng một hệ thống theo hướng tăng trưởng dần dần thay vì tất cả một lần. chúng không phải hỗn độn mà là được tổ chức và khá động bên trong ngữ cảnh của phương pháp luận. cách tiếp cận lặp chỉ là một khái niệm và UML chỉ là một ngôn ngữ. Chúng ta có thể quản lý tốt hơn việc thay đổi các yêu cầu với việc hợp nhất các thay đổi xuyên suốt quy trình và không cố gắng bắt buộc theo hướng tất cả các yêu cầu chỉ một lần. các thay đổi đối với các yêu cầu khác hày còn chưa được triển khai (có thể là R6 và R10). Chuỗi tiếp nối của sự lặp đi lặp lại này có thể có vẽ hỗn độn. nhưng chúng ta không triển khai hệ thống bởi vì chúng ta không đủ thời gian phân phối cho sự lặp đối với hoạt động đó. Chúng ta triển khai hệ thống thoả mãn năm yêu cầu đã được kiểm thử trong hoạt động lặp trước đó (R1R5) và tiếp tục làm việc dựa trên các yêu cầu khác(R6 R10). tuy nhiên. 3. và kiểm tra hệ thống đáp ứng ba yêu cầu đã được phân tích trong hoạt động lặp trước (R1. 4. và các thay đổi kỹ thuật khác đối với hệ thống. Chúng ta tiếp tục làm việc trên hệ thống tuy nhiên phải hướng sự thay đổi đến một yêu cầu đã được triển khai (có thể là R3). R3. như vậy. Chúng ta có thể cung cấp các giải pháp theo từng phần tới những người dùng xuyên suốt quy trình hơn là đợi Trang 15 Phân tích thiết kế hệ thống – GV: Trần Xuân Hải . Khi việc lặp đi lặp lại được sử dụng với một phương pháp luận. và R5) và hai yêu cầu đã được phân tích trong hoạt động lặp này (R2 và R4).

chúng ta có thể xác định mức độ đầy đủ thích hợp của các mô hình UML của chúng ta hơn là với việc sử dụng các tiếp cận theo mô hình thác nước. mà là hướng đến càng ngày càng nhiều các yêu cầu trong các hoạt động lặp liên tục.CHƯƠNG 4: • UML và mô hình hoá hướng đối tượng cho đến kết thúc quy trình. có lẽ chúng ta cần phải tốn nhiều công phu để chi tiết hoá chúng hơn nữa. Tương tự như vậy. Với cách tiếp cận động như vậy trong đó các hoạt động bên trong hoạt động lặp xảy ra song song và hệ thống được xây dựng tăng trưởng. Thậm chí dù một cách tiếp cận như vậy thường được hiểu như là lặp và tăng trưởng. trên thực tế nó là lặp. tại thời điểm mà họ nhận toàn bộ hệ thống và có thể kết luận rằng đó không là những gì họ mong chờ. một tiếp cận lặp bao gồm một chuỗi các hoạt động lặp ở nơi mà hệ thống phát triển tăng trưởng. Chúng ta có thể cố đạt cho được phản hồi từ những người dùng liên quan đến những phần đã được triển khai của hệ thống. Ví dụ. nếu chúng ta có một câu hỏi hay mối quan tâm cần hướng tới. Bởi vì cách tiếp cận như vậy phát triển hệ thống dần dần thông qua việc tinh chế liên tục và sự tăng trưởng dần dần các chi tiết. và nếu chúng ta không sẵn sàng sử dụng các mô hình UML của chúng ta để hướng đến mối quan tâm đó. chúng ta có thể tiến hành mà không tiêu phí thời gian và sự cố gắng chi tiết hoá hơn nữa các mô hình UML của chúng ta. theo đó chúng ta có thể hoàn chỉnh các thay đổi và hướng sự tiến triển của chúng ta trong việc cung cấp một hệ thống mạnh hơn phù hợp với các yêu cầu của họ. Một quy trình lặp là sự tăng trưởng bởi vì chúng ta không đơn giản là làm lại cùng những yêu cầu trong các hoật động lặp liên tục. mặc khác.. tăng trưởng và song song. các hoạt động có thể xảy ra sự hoạt động song song của các hoạt động lặp đơn lẻ khi chúng tập trung trên các phần khác nhau của hệ thống và không có sự xung đột. Vì thế. chúng ta làm như thế nào để các hoạt động Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 16 .

nhập dữ liệu.. các yêu cầu chức năng đối với hầu hết các hệ thống bao gồm các chức năng bảo mật cho phép người dùng đang nhập và ra khỏi hệ thống. và hoạch định các hoạt động lặp sau này.1 Use cases Một use case là một yêu cầu chức năng được mô tả theo góc độ của người dùng hệ thống. (Chúng ta sẽ tìm hiểu Use case kỹ hơn ở phần sau). Ví dụ. III.. Một use-case hướng quy trình là một khía cạnh mà chúng ta có thể sử dụng use cases để hoạch định và thực thi các hoạt động lặp. thiết kế và cài đặt một hệ thống nhằm đáp ứng chúng. architecture. and risk management are critical within an iterative approach. nhập và xử Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 17 . chúng ta nắm bắt và phân tích các use case.2. xử lý dữ liệu. Vì thế.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng được tổ chức và hướng tới việc thoả mãn các yêu cầu? Làm thể nào để chúng ta duy trì trọng tâm trên hệ thống và ngăn ngừa việc xây dựng một hệ thống khó bảo trì và tốn kém bởi vì nó đơn giản là một tập hợp những phần được gắn kết với nhau không với một số lược đồtổng quát? Những yêu cầu nào chúng ta hướng tới trước tiên. . Đó là. các use case là chất gắn kết tất cả các hoạt động bên trong một hoạt động lặp. kiểm thử và triển khai hệ thống.2. và những bộ phận nào của hệ thống chúng ta cài đặt trước tiên? Answering these questions is where use cases. hầu hết các hệ thống bao gồm các phần tử với mục đích điều khiển chức năng bảo mật.2 Kiểu kiến trúc (Architecture) Architecture chứa các thành tố (elements) tạo nên một hệ thống và cách mà chúng làm việc với nhau để cung cấp các chức năng của hệ thống. Ví dụ. III. Điều này cho phép chúng ta tổ chức các hoạt động và điều chỉnh tập trung vào trong tâm việc cài đặt các yêu cầu của hệ thống. phát sinh các báo cáo.

Cách tiếp cận như vậy thường được hiểu như là sự đương đầu với rủi ro (risk confronting).2. và công nghệ thay đổi. Để xác định những use cases nào nên điều khiển một hoạt động lặp và những phần nào của kiến trúc tập trung trong hoạt động lặp. Tôi sẽ đề cập chi tiết hơn vấn đề ở phần sau của chương này. các rủi ro bao gồm những điều như thiếu nguồn vốn. Mô hình hoá một hành vi của hệ thống được hiểu như là mô hình hoá hành vi (behavioral modeling). Sau đó chúng ta hướng các use case đương đầu với các rủi ro cao nhất và các thành tố của kiến trúc này. Các yếu tố cơ bản và khái niệm của mô hình hướng đối tượng sẽ được đề cập ở phần sau. Phát biểu rằng ba báo cáo (có thể là R1. III. Các loại thành tố khác nhau cấu toạ nên một kiến trúc của hệ thống. việc phát sinh dữ liệu.3 Sự rủi ro (Risk) Một rủi ro là bất kỳ sự trở ngại hay không hiểu biết có thể làm cản trở sự thành công của bạn. Vấn đề này sẽ được đề cập chi tiết hơn ở phần sau. Một lần nữa xét dự án bao gồm việc phát sinh 10 kiểu báo cáo khác nhau. và rằng bốn báo cáo (có thể là R3. cộng tác được hiểu như là các hành vi của hệ thống. và R10) yêu cầu người dùng nhập đầy đủ ý nghĩa. Các phần tử và các mối quan hệ của chúng được hiểu như là cấu trúc của hệ thống. R6. khi xây dựng. những thành viên nhóm làm việc thiếu kinh nghiệm với các trách nhiệm then chốt. R8. và vân vân.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng lý dữ liệu. chúng ta trước hết nhận dạng các rủi ro của hệ thống. Ví dụ. và R5) yêu cầu truy cập cơ sở dữ liệu quan trọng. R3. Việc mô hình hoá cấu trúc của một hệ thống được hiểu như là mô hình hoá cấu trúc (structural modeling). được xác định bởi mô hình hướng đối tượng (object-oriented paradigm). Cả hai cấu trúc và hành vi. giải quyết các rủi ro cao nhất. Những phần tử và cách chúng tương tác. Có lẻ có hai rủi ro: rủi ro không có giao diện người Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 18 . Khi phát triển một hệ thống.

và rằng R3. bởi vì nó hướng đến cả hai rủi ro. và R5 hay nhiều yêu của họ như là các ứng viên thích hợp đầu tiên. bởi vì chúng đe doạ rủi ro X1. chúng ta truyền đạt sự tri thức của chúng ta về vấn đề bằng cách sử dụng một bảng chữ cái. Nếu X2 là then chốt hơn đối với dự án của bạn. đoạn văn. R3. UML cung cấp các kỹ thuật mô hình hoá cấu trúc và hành vi có thể được sử dụng trong một quy trình dạng bậc thang (step-wise) được hướng bởi các yêu cầu. tập trung vào việc phát triển một hệ thống đúng đắn hợp lý về kiến trúc đáp ứng các yêu cầu và cho phép bạn đương đầu các rủi ro xuyên suốt quá trình phát triển hệ thống. và có khả năng xảy ra cao hơn hay có ảnh hưởng cao hơn với dự án. và có khả năng xảy ra cao hơn hay có ảnh hưởng cao hơn với dự án. và R10 hay nhiều yêu cầu của họ như là ứng viên thích hợp đầu tiên bởi vì chúng đe doạ rủi ro X2. mục. R6.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng dùng trực quan ( intuitive ) (có tên là X1) và rủi ro của việc có một hệ quản trị cơ sở dữ liệu không hiệu quả (có tên là X2). chúng ta phải nhằm vào R3 đầu tiên. Trang 19 Phân tích thiết kế hệ thống – GV: Trần Xuân Hải . và tài liệu. R6. chúng ta sẽ hướng R1. các từ. R8. trong mọi trường hợp. R8. và R5 là liên đới với rủi ro X1. R3. IV Mô hình hoá hướng đối (Object-Oriented Modeling) tượng Trong phần này chúng ta sẽ tìm hiểu mô hình hướng đối tượng và các kỹ thuật môt hình hoá của UML. Trong phần này chúng ta sẽ đề cập đến các vấn đề sau:  Các khái niệm về câu. Nếu X1 là then chốt hơn đối với dự án của bạn. và R10 có liên quan với X2. Trong khi UML là một ngôn ngữ cho việc truyền đạt ý tưởng về một hệ thống và và các yêu cầu của nó. chúng ta hiểu rằng R1. câu. Tuy nhiên. chúng ta sẽ hướng R3. Xuất phát từ các mô tả này. từ và bảng chữ cái trong UML.

Ví dụ. Kiến trúc View. Trang 20 Phân tích thiết kế hệ thống – GV: Trần Xuân Hải . và có thể được xác nhận thông qua (xác nhận tính hợp lệ). Một chuyên viên quản lý dự án lãnh đạo một nhóm thực hiện dự án làm việc kể từ lúc bắt đầu đến ngày kết thúc của dự án. được cập nhật. Cách lập tài liệu các mô hình UML. IV.1 Xác định yêu cầu hệ thống quản lý dự án (Project Management System Requirements) Một chuyên viên quản lý dự án (project manager ) sử dụng hệ thống quản lý dự án để quản lý một dự án. và Hawk. và được phát sinh suốt dự án. các yêu cầu được xác nhận thông qua bởi người dùng trong workshops. Tuy nhiên. Một số kỹ thuật mô hình hoá UML. Một hệ thống được sinh ra (hay một phần của hệ thống) là kết quả đầu ra của dự án. được sử dụng. Mỗi sản phẩm công việc có một mô tả. tên của ba dự án này là Eagle. sự xác nhận thông qua phụ thuộc loại sản phẩm công việc. Khi một dự án được tạo nên trong hệ thống quản lý dự án. Falcon. phần trăm hoàn tất. quản lý ba dự án. hệ thống quản lý dự án phải có khả năng vận dụng để kiểm soát kịch bản sau đây: • A là một chuyên viên quản lý. Một dự án sử dụng các yêu cầu như một đầu vào. chuyên viên quản lý dự án có thể khởi đầu và kết thúc muộn dự án bởi để hoàn tất nó hay hay vì một số lý do nào đó. và hệ thống sẽ được kiểm thử dựa vào các yêu cầu. Xác định các yêu cầu và hệ thống là các kết quả công việc: những gì được tạo ra.CHƯƠNG 4:     UML và mô hình hoá hướng đối tượng Các khái niệm và nguyên lý của của mô hình hướng đối tượng.

trong khi đó dự án Hawk bổ sung các yêu cầu đặc trưng theo đơn vị tổ chức. Mỗi khi thông tin yêu cầu được cung cấp. Giao diện người dùng của dự án hệ thống quản lý thực thi trên một máy tính client (máy desktop). ngoại trừ việc nó có bổ sung thêm các yêu cầu đặc trưng của đơn vị tổ chức (organization-specific). Dự án Hawk đang sử dụng nền tảng Microsoft . và sự mô tả của nhóm làm việc. và loại bỏ khỏi hệ thống một khi nó được hoàn tất. nó nhằm mục tiêu hướng tới thị trường rộng. chuyên viên quản lý dự án sử dụng một giao diện người dùng để nhập vào thông tin liên lạc của anh ta (với số lượng tối thiểu. • Khi tạo một dự án. Cơ sở dữ liệu của dự án hệ thống quản lý thực thi trên một server trung tâm. sự mô tả các yêu cầu và hệ thống. tên của dự án. ngày bắt đầu và ngày kết thúc.CHƯƠNG 4: • • • UML và mô hình hoá hướng đối tượng Tất cả các dự án dính líu đến các nhóm làm việc nặc danh hay không có tên. Vì thế. hệ thống xử lý thích đáng yêu cầu lưu trữ thông tin và xác nhận sự hoàn tất. các dự án Falcon và Hawk chia sẻ một số yêu cầu chung. tên và số điện thoại).NET để sản sinh một hệ thống tương tự dự án Falcon. có thể trở nên inactive lần nữa nếu nguồn nhân lực được lấy ra khỏi dự án. giao diện người dùng và cơ sở dữ liệu. Dự án Eagle sản sinh một hệ thống quản lý dự án. Dự án Falcon đang sử dụng nền tảng Java để sản sinh ra loại hệ thống khác. dự án hệ thống quản lý có hai phần. giống như đã được mô tả. Thoạt tiên. Đối với mục tiêu kiểm định và bảo mật. dự án là inactive. Nó trở nên active khi nguồn nhân lực được gán tới dự án. truy xuất đến Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 21 .

CHƯƠNG 4: UML và mô hình hoá hướng đối tượng một máy in. những định nghĩa các loại khái niệm mà chúng có thể được sử dụng trong ngôn ngữ và các yếu tố cơ bản của việc tại sao chúng có thể được dùng cho mục đích thực tế nào đó. từ (words). Chúng ta cũng phải biết các khái niệm và nguyên lý cơ sở của mô hình bên dưới nó. và câu (sentences) Bởi vì công nghệ xác định và bổ sung yêu cầu là phức tạp và liên tục thay đổi. nó không cung cấp tất cả chi tiết liên quan đến hệ thống quản lý dự án. IV. Một ngôn ngữ dựa trên cơ sở một mô hình. chúng ta sẽ có khả năng hiểu tốt hơn sự mô tả này. cách mà bộ chữ cái của nó được sử dụng để hình thành các từ. Các ngữ nghĩa của ngôn ngữ xác định ý nghĩa mà nó đã được truyền đạt và đã được xác định bởi các từ các câu của ngôn ngữ. Sự mô tả này cung cấp chi tiết đầy đủ. Một cú pháp của ngôn ngữ xác định các ký hiệu (ký pháp – notation) được sử dụng cho sự truyền đạt và được xác định bởi bộ chữ cái của ngôn ngữ. tuy nhiên. Với việc sử dụng UML. Cú pháp của UML bao gồm các lược đồ (diagrams). Đối với sự truyền đạt bằng cách sử dụng một ngôn ngữ.1. mà còn cho phép chúng ta quản lý các thay đổi và sự phức tạp tốt hơn khi chúng ta truyền đạt ý tưởng về một vấn đề. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 22 . chúng ta phải biết bộ chữ cái của nó. và cách mà các từ của nó được sử dụng để hình thành nên câu. chúng ta có thể có khả năng điều tra thông tin thiếu đối với phát triển hệ thống. và với việc sử dụng một quy trình.1 Bộ chữ cái (Alphabets). một quan điểm nhìn về một vấn đề. và các ngữ nghĩa của nó dựa trên mô hình hướng đối tượng. một ngôn ngữ không chỉ phải truyền truyền ý tưởng dễ dàng một vấn đề. và sử dụng cơ sở dữ liệu để lưu trữ thông tin liên quan dự án.

1. Trong UML. các từ phụ thuộc theo hai loại hay kiểu chung: Concepts Concepts được trình bày như là các hình chữ nhật hay các ký hiệu có hình dáng thuần nhất (solid-outline) được gán nhãn với một cái tên.1.2 Alphabet Một alphabet định nghĩa những phần đơn giản nhất của một ngôn ngữ: bộ chữ cái (letters). ngôn ngữ tiếng Anh có các từ khác nhau. Ví dụ. bao gồm "project. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 23 ." "team. Alphabet của UML bao gồm các mẩu ký hiệu (Các hình chữ nhật (rectangles). các ký hiệu (signs).3 Words Một từ là một nhóm các thành tố xuất phát từ alphabet của ngôn ngữ định nghĩa một đơn vị có đầy đủ ý nghĩa. concepts và relationships có thể có chuỗi ký tự khác được gắn tới chúng nhằm xác định rõ thông tin khác. và các thành tố đồ hoạ khác) và chuỗi các ký tự ." và vân vân. Ví dụ. các ký tự (characters)." "execute. đơn vị nhỏ nhất có ý nghĩa trong một ngôn ngữ là các từ của nó (words) IV. Ngoài các tên của chúng. Mối quan hệ (relationships) giữa các concepts Mối quan hệ giữa các concepts được trình bày như là các đường thẳng hướng việc kết kết các ký hiệu được gán nhãn với một cái tên." "manager. bộ chữ cái của tiếng Anh có 26 chữ cái. và bộ dấu (marks). các đường thẳng (lines)." "lead.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng IV.

Manager. Work Product Requirement Project Manager System Team (Hình 4.2 trình bày các mối quan hệ khác nhau được nhận dạng từ các yêu cầu hệ thống quản lý dự án bằng cách tập trung chú ý trên các động từ. Input Lead Output Manage Execute (Hình 4. Team.2. bao gồm Manage. Hình 4. Work Product.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng Hình 4.2) Thông thường bạn sẽ không muốn trình bày tất cả các relationships này một cách riêng biệt như trong hình 4.1) Tương tự như vậy. Lead. và System. và Output. Input. mà sẽ Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 24 . Execute.1 trình bày các concepts được nhận dạng từ các yêu cầu hệ thống quản lý dự án với việc tập trung sự chú ý trên các danh từ. bao gồm: Project. Requirement.

tiếng Anh có các quy tắc đối với việc kết hợp các từ để hình thành câu. và Execute là mối quan hệ (ở dạng động từ . chúng ở dạng (danh từ nouns). Khi bạn kết hợp các relationships với các concepts. Ngữ pháp của một ngôn ngữ xác định các quy tắc đối với việc kết hợp các từ để hình thành các câu. IV. bạn thật sự đang kết hợp các từ UML để hình thành các câu UML.3 trình bày một UML sentence với sự truyền đạt rằng một nhóm làm việc (team) sẽ thực hiện một dự án như là đã được biểu thị trong các yêu cầu hệ thống quản lý dự án.4 Sentences Một sentence là một nhóm các từ xuất phát từ các từ vựng của ngôn ngữ định nghĩa một đơn vị văn phạm có ý nghĩa đang chứa đựng một vấn đề và một sự biểu diễn về vấn đề. Team Execute Projects Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 25 .CHƯƠNG 4: UML và mô hình hoá hướng đối tượng kết hợp chúng với các concepts trình bày trong hình Hình 4. chẳng hạn câu "a manager leads a team" tuân theo các quy tắc ngữ pháp. trái lại câu "leads manager team" thì không. Các câu UML là các phân mảnh lược đồ hay các lược đồ rất đơn giản.verb) giữa hai khái niệm.1.1. Hình 4. Team và Project là các khái niệm (concepts). Ví dụ.

4 truyền đạt ý tưởng về mối quan hệ của manager với một team và một project. Ví dụ.3) Hình 4.5 truyền đạt thông tin giống như Hình 4.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng (Hình 4. mặt khác. Vị trí nhìn thấy của các khái niệm và các mối quan hệ không mang bất kỳ một ý nghĩa đặc biệt nào miễn là các ký hiệu không lồng trong bên trong một ký hiệu khác.4 trình bày một UML sentence tinh tế hơn.4 Một manager quản lý một project và lãnh đạo một team (Version 1)) Chú ý rằng hình 4. trong đó một chuyên viên quản lý quản lý một dự án và lãnh đạo một nhóm. Hình 4. tên của nó có thể có một mũi tên hình tam giác đặc biểu thị hướng đọc. chúng ta có thể truyền đạt mọi thứ chúng ta muốn bằng cách sử dụng UML. mũi tên này có ý nghĩa mô tả mối quan hệ giữa các khái niệm. tuy nhiên nó không truyền đạt rằng nhóm làm việc (team) sẽ thực thi (execute) một dự án (project).4. Một mối quan hệ thường được đọc trái sang phải và từ trên xuống dưới. như đã trình bày ở hình 4. manager manage lead teams projects (Hình 4. Giống như ngôn ngữ English.3. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 26 .

bởi vì đó là những gì mà nó có ý nghĩa đối với một manager. Chúng ta sẽ tìm hiểu làm thế nào các khái niệm (concepts ) hướng đối tượng cho phép chúng ta nhìn bao quát thế giới xung quanh chúng ta. IV. chúng ta sẽ xem xét mô hình hướng đối tượng mà các ngữ nghĩa của UML đã lấy đó làm cơ sở. và tại làm sao các nguyên lý (principles) của mô hình cho phép chúng ta quản lý sự thay đổi và độ phức tạp tốt hơn.2.5 Một manager quản lý một project và lãnh đạo một team (Version 2)) Trong hình 4.2 Mô hình hướng đối tượng (Object-Oriented Paradigm) Trong phần này chúng ta sẽ tìm hiểu làm thế nào để sử dụng các words và sentences UML đơn giản.1 Concepts Mô hình hướng đối tượng dựa trên một số concepts chính mà chúng cho phép chúng ta có cái nhìn thế giới xung Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 27 . Đây là lý do tại sao nó là quan trọng để hiểu các ngữ nghĩa của những gì mà chúng ta mô tả trong UML hơn là đơn giản cú pháp. Việc nói rằng các nhóm làm việc (teams) lãnh đạo (lead) các manager và các dự án (projects) quản lý (manage) các manager sẽ là vô nghĩa! IV.5. nếu tôi không trình bày hình mũi tên chỉ hướng kèm theo relationship. chúng ta vẫn hiểu rằng các manager quản lý các projects và lãnh đạo các nhóm làm việc.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng (Hình 4.

và một đối tượng (object) là một thể hiện (instance) của một class. Team.1. Chúng ta có thể có nhiều managers. Hình 4. tại đó các khái niệm cụ thể được hiểu như là các đối tượng (objects) và các quan hệ cụ thể cụ thể được hiểu như là các liên kết (links). và Project. managers.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng quanh chúng ta. Sau đây. Toàn bộ chuỗi này. chúng ta cũng có thể truyền đạt ý tưởng vào trong UML với việc sử dụng các sentences cụ thể bao gồm cụ thể các projects.1Classes.5 trình bày ba classes.4 và Hình 4. teams. teams. và links Các hình 4. Trong UML. một concept cụ thể được trình bày với việc sử dụng cùng ký hiệu như concept tổng quát của nó. Các khái niệm tổng quát được trình bày trong sentences được hiểu như là các classes.2. bao gồm tên được xác định. teams. và projects. Ví dụ. Một quan hệ kết hợp (association) định nghĩa một loại liên kết (link) và các đặc trưng của các liên kết của nó.5.4 và Hình 4. và vân vân cụ thể. và tên tổng quát. và project cụ thể là một thể hiện (instance) hay đối tượng (object) của class của nó. Ký hiệu được gán nhãn với một tên cụ thể theo ngay sau đó là dấu hai chấm và kế đó là tên của concept tổng quát của nó. chúng ta sẽ thảo luận về các concepts chính này. và dấu hai chấm chỉ được trình bày khi concept tổng quát được xác định.6 trình bày một class cụ thể cho mỗi ba đối tượng đã trình bày trước đây trong các Hình 4. team. Hình 4. phải được gạch dưới. và mỗi manager.3  hình 4. và các relationships tổng quát được hiểu như là các quan hệ kết hợp (associations).5 trình bày các sentences tổng quát. và vân vân. Tương tự như các ngôn ngữ tự nhiên. Cả hai tên là không bắt buộc. objects. associations. và một liên kết là Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 28 . Một class định nghĩa một loại đối tượng và các đặc trưng của các đối tượng của nó. bởi vì chúng không nhận biết các projects. managers. bao gồm Manager. IV. hai chấm.

Mô hình hướng đối tượng nhìn thế giới thực như là một tập hợp các đối tượng đơn nhất.4 và Hình 4.6.5. Si quản lý dự án Eagle và lãnh đạo một nhóm làm việc nặc danh Si:Manager Manage Lead :Teams Eagle:Projects (Hình 4. quản lý dự án Eagle và lãnh đạo một nhóm làm việc nặc danh hay không tên. Quy ước ký hiệu và tên giữa một class và các thể hiện của nó. Một quan hệ (relationship) cụ thể được trình bày như là một đường dẫn và có thể được gán nhãn với tên quan hệ (relationship) của nó được gạch dưới. có thể làm một số điều nào đó.4 và Hình 4. thường được xem như là một society của các đối tượng. được sử dụng khắp cả UML và được hiểu như là một type-instance dichotomy.6 trình bày hai liên kết cụ thể của các quan hệ kết hợp đã được trình bày trước đây trong các Hình 4. Mỗi đối tượng có một chu trình sống. Hình 4. hay một quan hệ kết hợp (association) và các thể hiện của nó. trình bày có nghĩa rằng Si.6.6) Hình 4. Hình 4. Những gì mà một đối tượng hiểu và có thể làm được hiểu Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 29 . và có thể sự liên lạc với các đối tượng khác.5.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng một thể hiện (instance) của một quan hệ kết hợp. sentence cụ thể dựa trên sentence tổng quát đã được trình bày trong các Hình 4. là một manager.

Một class định nghĩa các thuộc tính và một đối tượng có những giá trị đối với các thuộc tính này. các đối tượng là duy nhất và có các nhận dạng của chính nó. Chỉ những thuộc tính mà chúng ta muốn truyền đạt là được biểu diễn. Ví dụ.1. Ngay cả khi hai đối tượng có cùng các giá trị đối với các thuộc tính của chúng. Tương tự. Trong một lược đồ UML. bởi vì chúng truyền đạt cấu trúc của class tương tự như cách mô hình hoá cấu trúc đã được thảo luận ở phần bên trên của chương này. một class có thể được trình bày với một ngăn thứ hai liệt kê các thuộc tính này như là những chuỗi văn bản.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng như là các đặc trưng (features). một nhóm làm việc có một mô tả.7 bổ sung chi tiết Hình 4.2Attributes Một điều gì đó mà một đối tượng hiểu được gọi là một thuộc tính (attribute). và có thể liên hệ với một nhóm làm việc để lãnh đạo nhóm làm việc và để thực hiện thành công project. mỗi trong chúng được theo sau bởi ký hiệu dấu “ = ” và giá trị của nó.4 và biểu diễn rằng một manager có một tên. Các đặc trưng phụ thuộc theo hai loại hay kiểu chung là : Các thuộc tính (attributes) và các phương thức (operations). Hình 4. Figure 2-7. Các quan hệ kết hợp (Associations) và các thuộc tính được hiểu như là các đặc trưng cấu trúc. một manager được gán tên của anh ta hay cô ta. và một dự án có một tên. một đối tượng có thể được trình bày ở một ngăn thứ hai liệt kê những thuộc tính này như là các chuỗi văn bản.2. có thể bắt đầu hay kết thúc một project. những thuộc tính khác không quan trọng với chúng ta đối với việc truyền đạt dựa trên lược đồ không cần cần được biểu diễn. Classes with attributes Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 30 . IV. ngày bắt đầu và ngày kết thúc. về bản chất nó đại diện cho dữ liệu.

6 biểu diễn các đối tượng khác nhau với các giá trị cho các thuộc tính được biểu thi trong Hình 4.8. Các Classes với những thuộc tính (attributes)) Hình 4.7. (Hình 4. chúng ta khai báo các hàm (functions) hay các thủ Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 31 .CHƯƠNG 4: UML và mô hình hoá hướng đối tượng (Hình 4.7.1. khi sử dụng một ngôn ngữ lập trình. Cách mà một đối tượng xử lý đối với một operation đã định được hiểu như là phương thức (method) hay sự thực thi (implementation) của operation . Các đối tượng với những giá trị thuộc tính) IV. Ví dụ.3Operations và methods Đại loại một số điều mà một đối tượng có thể làm là gọi một operation hay đặc tả yêu cầu và thực chất tương ứng với việc xử lý.8 bổ sung chi tiết Hình 4.2.

bởi vì tất cả các đối tượng của một có cùng các operations và chia sẻ các phương thức class của chúng. Với việc biểu diễn hai operations. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 32 . Các Operations và các methods được hiểu như là các đặc trưng hành vi (behavioral features). Chú ý rằng ngăn thứ hai của Manager là rỗng. và sự định nghĩa phần thân là method. chỉ những operations mà chúng ta muốn truyền đạt trên một lược đồ nhất định mới cần được biểu diễn. Initiate Project và Terminate Project. Những operations khác mà chúng không có tầm quan trọng với chúng ta đối với việc truyền đạt trên lược đồ nhất định không cần được biểu diễn. bởi vì chúng truyền đạt các hành vi của một class giống như đối với cách mô hình hoá hành vi đã được sử dụng để truyền đạt hành vi đã thảo luận ở phần trước của chương này. Hình 4.9 trình bày rằng một manager có thể bắt đầu hay kết thúc một project. Một đối tượng (object) trong phần trình bày sẽ không có ngăn thứ ba. Tương tự. Một ngăn thuộc tính rỗng phải được biểu diễn sao cho ngăn thứ ba được sử dụng để liệt kê các operations. bởi vì ở đây tôi chỉ đề cập đến các operations của Manager. Một class có thể được biểu diễn ở ngăn thứ ba với việc liệt kê các operations này như là chuỗi văn bản. Một class định nghĩa các operations và methods áp dụng cho các đối tượng (objects) của nó. tuy nhiên có thể được mô tả bằng cách sử dụng các kữ thuật mô hình hoá UML khác. Nếu các thuộc tính không được biểu diễn. thủ tục) xác định những gì mà các hàm hay thủ tục thực hiện khi chúng được triệu gọi và được thực thi. một sự khai báo hàm là operation.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng tục (procedures) và định nghĩa phần thân của chúng (các dòng lệnh bên trong hàm. Các phương thức của một class – mà lệnh cài đặt trên thực tế của các operations – không được biểu diễn trên một class.

9 với việc sử dụng các thuộc tính và các operations cho mỗi class trên cùng lược đồ.9. Classes với các operations) Hình 4. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 33 . một operation được triệu gọi để điều khiển thỉnh cầu. Ví dụ. chúng ta không bắt đầu một project về phía một manager mà truyền đạt một thỉnh cầu tới manager để bắt đầu project.10 sự kết hợp Hình 4. (Hình 4. Mỗi khi manager nhận thỉnh cầu.7 và Hình 4.4Thông điệp (Messages) và tác nhân(stimuli) Trong mô hình hướng đối tượng.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng (Hình 4.2. và manager thực thi method tương ứng với operation. sự truyền thông từ đối tượng gởi tới đối tượng nhận được sử dụng để truyền đạt thông tin hay việc xử lý thỉnh cầu.10.1. Classes với các attributes và operations) IV.

Phát sinh sự tương tác) Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 34 . (Hình 4. và sự truyền thông hay tương tác giữa các classes qua các quan hệ kết hợp (associations) của chúng được gọi là một thông điệp (message). Sự truyền thông (Communication) hay tương tác giữa các đối tượng qua các links của chúng được gọi là một tác nhân (stimulus). và receiver được hiểu như là supplier. Một stimulus là một thể hiện (instance) của một thông điệp tương tự cách một đối tượng là một thể hiện của một class và một link là một thể hiện của một association. Hình 4. theo sau là dấu hai chấm và kế đó là tên của operation sẽ được triệu gọi. Một message hay stimulus được biểu diễn như là một mũi tên được đính kèm tới một association hay link trỏ hướng từ sender tới receiver và được gán nhãn với một con số tiếp nối theo trình tự biểu diễn trình tự mà message hay stimulus gởi. Sender được hiểu là client.11.11 biểu diễn rằng một manager gán các hoạt động (activities) và các tác vụ hay nhiệm vụ(tasks) tới một nhóm làm việc dựa trên các yêu cầu của một project (Một dự án có nhiều hoạt động và một hoạt động có nhiều tác vụ hay nhiệm vụ).CHƯƠNG 4: UML và mô hình hoá hướng đối tượng Việc gởi một thỉnh cầu và sự việc nhận một thỉnh cầu là các sự kiện (events hay occurrences).

CHƯƠNG 4: UML và mô hình hoá hướng đối tượng Hình 4.12.2. Trong phần tiếp theo sau đây chúng ta sẽ thảo luận về các nguyên lý cơ bản này.2 Các nguyên lý cơ bản (Principles) Mô hình hướng đối tượng dựa trên cơ sở nề tảng bốn nguyên lý cơ bản cho phép chúng ta quản lý sự thay đổi và sự phức tạp tốt hơn. ngoài ra loại trừ các không tin phụ hay không thích đáng. dự án Eagle. và nhóm làm việc (không xác định cụ thể).2. Các Classe và quan hệ kết hợp (association) là sự trừu tượng hoá chung hay sự trừu tượng hoá tổng (general abstractions). khi truyền đạt thông tin về các manager.2.1 Sự trừu tượng hoá (Abstractions) Các Concept và relationship được hiểu như là sự trừu tượng hoá. Chi tiết sự tương tác) IV. (Hình 4. Một sự trừu tượng hoá được cho là tốt phải định nghĩa hợp lý và bao gồm đầy đủ các thông tin cốt lõi nhằm để hiểu nó. và các đối tượng objects và các liên kết (links) là sự trừu tượng hoá cụ thể (specific abstractions). và cũng thật là không cần thiết đối với chúng ta Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 35 . thật là cần thiết với việc chúng ta cần biết tên của họ.12 biểu diễn sự tương tác cụ thể giữa Si (là một manager). Ví dụ. IV.

khi có một thay đổi đối với class có tên Manager. Ví dụ. chúng ta có thể quản lý sự thay đổi và độ phức tạp tốt hơn bằng cách giảm bớt số chỗ mà chúng ta phải quan tâm xem xét khi có một sự thay đổi xảy ra. Ví dụ. khách hàng (client) thường chỉ quan tâm đến các kết quả của operation chớ không phải method mà nhà cung cấp (supplier) sử dụng để thực hiện operation.2. như lá một nhu cầu theo dõi số năm kinh nghiệm của một manager. mà Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 36 . chúng đơn giản là cần tới class và cập nhật các thuộc tính hay các operations của nó hơn là tới một nơi lưu trữ dữ liệu để cập nhật dữ liệu của manager (hay các thuộc tính) và nơi khác để cập nhật xử lý của nó (hay các operations). do đó. IV. Khi các classes hay các objects truyền đạt thông tin. Với việc sử dụng sự trừu tượng hoá được định nghĩa tốt. một method có thể được che dấu hoàn toàn khỏi những client của nó. Với việc kết hợp các thuộc tính và các operations vào trong các đơn thể (single units). một manger thì quan tâm đến việc có nhóm làm việc thực hiện một project. Cách làm là chúng ta xem xét nhiều manager khác nhau để qua đó chúng ta có thể xác định những điểm nào là tương đồng và những điểm nào là khác nhau để từ đó phân loại chúng theo như các manager. Sự kết hợp các thuộc tính và operation tới các classes và các objects cũng được hiểu như là sự cục bộ hoá hay địa phương hoá (localization).2.2Tính đóng gói(Encapsulation) Việc kết hợp các thuộc tính (attributes) và các operations tới hình thái classes và objects và việc che dấu các methods ở đằng sau các operations được hiểu như là sự đóng gói (encapsulation).CHƯƠNG 4: UML và mô hình hoá hướng đối tượng việc biết họ sở hữu bao nhiêu có bao nhiêu vật nuôi làm kiểng. chúng ta có thể quản lý sự phức tạp tốt hơn do tập trung sự quan tâm trên những gì cốt lõi. nếu có.

khi một manager quản lý nhóm làm việc thực thi một project.3 Sự tổng quát hoá (Generalization) Hình 4. Hơn nữa. Cách làm này cho phép chúng ta quản lý sự thay đổi và sự phức tạp tốt hơn. hoặc có sự thay đổi nơi lưu trữ ngược lại. Ví dụ. IV.2. mà không làm ảnh hưởng tới các client. Việc che giấu một phương thức (method) đằng sau một operation cũng được hiểu như là việc che giấu thông tin. và có thể thay đổi các kỹ thuật mà không ảnh hưởng đến manager. các bộ getter và setter đối với ngân sách liên quan với một project có thể bị thay đổi nơi lưu trữ ngân sách trong cơ sở dữ liệu thay thế cho việc lưu trữ trong một tập tin không phải cơ sở dữ liệu. làm thế nào để thông tin về ngân sách liên quan với một project được lưu trữ có thể được che giấu đối với các khách hàng. nhóm làm việc có thể sử dụng các kỹ thuật khác nhau. thông qua các bộ get và set. Chú ý rằng Requirement và System (Hình 4. Đó là cả hai System và Requirement đều có Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 37 . Một thuộc tính cũng có thể được tạo nên và không cho phép truy cập hay ẩn đi đối với các client bởi vì nó phải được truy cập thông qua các operation.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng không quan tâm đến chi tiết phức tạp của cách nhóm làm việc thực hiện project. bởi vì chúng ta có thể sửa đổi một phương thức của một class mà không ảnh hưởng đến các client sử dụng operation được cài đặt bởi method.13 biểu diễn các classe tương ứng với các yêu cầu và hệ thống dựa trên sự xác định các yêu cầu với case study hệ thống quản lý project.13) là các là các kết quả công việc với một vài thuộc tính và operation giống nhau nhưng các method khác nhau đối với sự kiểm tra tính hợp lệ và tính duy nhất của các thuộc tính đối với classe của chúng. Ví dụ. nó lấy và thiết lập giá trị của thuộc tính. và có thể được truy xuất thông qua các operation: getter và setter.2. bởi vì nó được lưu trữ hoặc trong cơ sở dữ liệu hoặc trong một tập tin không phải cơ sở dữ liệu quan hệ.

Một sự tổng quát hoá được sử dụng giữa một class có tính tổng quát hơn và một lớp class có tính chuyên biệt hơn chứa đựng các thuộc tính. với một tam giác rỗng lớn ở cuối đường dẫn được kết nối tới class chung hơn. và có thể được kiểm tra xác nhận tính hợp lệ. tôi sẽ thảo luận Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 38 . Trong khi cả hai System và Requirement có một operation là Validate. và các method xuất phát từ các class chung hơn. (Hình 4.14 biểu diễn cách mà một sự tổng quát hoá được sử dụng để truyền đạt ý tưởng cả hai Requirement và System là sản phẩm công việc có một sự mô tả. phần trăm hoàn tất. Trong phần kế. tuy nhiên hoạt động Validate cũng xuất hiện trong class Requirement và System.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng một thuộc tính Percent Complete và một thuộc tính Description. Một sự tổng quát hoá được biểu diễn với một đường thẳng đậm có hướng từ class có tính chuyên biệt hơn. tương tự đối với các thuộc tính Description và Platform. Chúng ta có thể lợi dụng sự tổng quát hoá để nắm bắt và tái sử dụng sự tương đồng của chúng. các relationship.13) Hình 4. Chú ý rằng hoạt động (operation) Validate chuyển vào trong class có tên Work Product. và Requirement thì có một operation là Publish trong khi System có một operation là Deploy. các operation. tuy nhiên Requirement thì có một thuộc tính Media trong khi System có một thuộc tính Platform.

Ví dụ. có thể với một phương thức mặc định. (Hình 4. và các thay đổi mà chúng ta tạo nên ở một class chung hơn sẽ được truyền tới các classe riêng biệt hơn.14 biểu thị rằng hành động (operation) Validate xuất hiện trong tất cả các classe. Nó được định danh hay khai được khai báo trong lớp classe có tên Work Product .4 Tính đa hình (Polymorphism) Hình 4.2.2. Với việc sử dụng sự tổng quát hoá. chúng ta có thể quản lý sự thay đổi và sự phức tạp tốt hơn. và vân vân cần thiết trong tương lai.14) IV. chúng ta có thể sử dụng class có tên Work Product để định nghĩa các loại kết quả công việc khác như user documentation. Vì lý do đó. cần thiết cho việc các lớp Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 39 . trái lại lớp Requirement và lớp System cung cấp các phương thức của riêng chúng đối với sự xác nhận tính hợp lệ. installation và administration manuals. Chúng ta thu được khả năng tái sử dụng những đối tượng trừu tượng hoá đang tồn tại để định nghĩa các đối tượng trừu tượng hoá mới.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng tại sao hoạt động Validate trong tất cả các classe.

và cũng như thế đối với bất kỳ loại sản phẩm công việc nào khác. Đó là. phương thức Validate được cung cấp bởi lớp Requirement được triệu gọi để điều khiển (handle) các thỉnh cầu xác đinh tính hợp lệ . phương thức Validate được cung cấp bởi lớp System dược triệu gọi để điều khiển các thỉnh cầu xác định tính hợp lệ . chúng ta có thể quản lý sự thay đổi và sự phức tạp tốt hơn bởi việc sử dụng lại các hành động (operations) với các phương thức mới. chúng ta có thể thao tác các sả phẩm công việc requirement. và các loại sản phẩm công việc cụ thể khác hoàn toàn như là các loại sản phẩm công việc tổng quát. Với việc sử dụng tính đa hình (polymorphism). Đối với mỗi sản phẩm công việc requirement. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 40 . và chúng ta có thể truyền đạt các thỉnh cầu mà không phải quản lý các phương thực tế nào đã được triệu gọi. Bởi vì một sự tổng quát hoá giữa một lớp tổng quát hơn và một lớp chuyên biệt hơn cũng ngụ ý rằng các đối tượng của lớp chuyên biệt hơn chính là các đối tượng được chuyên biệt hoá của lớp tổng quát. Ví dụ. các sản phẩm công việc system. các yêu cầu và hệ thống có thể được thay thế cho các sản phẩm công việc. Các lớp này được kế thừa hoàn toàn chức năng Validate mặc định xuất phát lớp Work Product. Khả năng có nhiều phương thức cho một hành động (operation) đơn lẻ được gọi là tính đa hình (polymorphism). Việc đơn giản áp dụng hành động Validate trên một sản phẩm công việc (work product) mà không biết lớp thực sự của nó sẽ gây ra việc phương thức thích hợp sẽ được triệu gọi. bạn không phải liệt kê lại phương thức Validate. Đối với mỗi sản phẩm công việc system.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng Requirement và System liệt kê các hành động Validate của riêng chúng. về nguyên tắc các đối tượng của lớp chuyên biệt có thể được thay thế cho các đối tượng của lớp tổng quát.

hệ thống quản lý dự án có thể được sử dụng để quản lý các dự án về các ngành kinh oanh khác nhau. Cho ví dụ. các dịch vụ tài chính.2. Để hiểu một hệ thống. Các thành tố của một hệ thống và Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 41 . chúng ta tập trung sự quan tâm trên các kiến trúc của nó. cả hai được hiểu như là các thành tố domain (domain elements). Chủ đề chính liên quan đến những gì mà chúng ta truyền đạt là một hệ thống tập trung vào trong một domain. Một hệ thống là một tập hợp các thành tố được tổ chức cùng nhau nhằm một mục tiêu cụ thể. tư vấn công nghệ thông tin. tất cả các thành tố trên những hình đã biểu diễn ở phần trên là các thành tố lược đồ. ngôn ngữ English nhóm các câu (sentences) vào trong các đoạn văn (paragraphs).5 Paragraphs Một paragraph là một nhóm của các sentences liên quan tới một đối tượng chung. và mỗi ngành nghề là một domain khác nhau. Ví dụ. và vân vân. Các thành tố này được hiểu như là các thành tố hệ thống. và các relationships của chúng lag các quan hệ kết hợp (associations). Một lược đồ là một tập hợp các câu của UML. Một domain. Ví dụ.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng IV. cũng được hiểu như là một ngữ cảnh (context). Các đoạn văn UML là các lược đồ (diagrams). bao gồm chế tạo sản phẩm. Kiến trúc của một hệ thống bao gồm các thành tố cấu tạo nên hệ thống và cách mà chúng làm việc cùng nhau để cung cấp chức của năng hệ thống. Các concepts này là các lớp (classes). Các thành tố (elements) cấu tạo nên một lược đồ được hiểu như là các thành tố lược đồ. các dịch vụ chiến lược. Các thành tố chính cấu tạo nên một hệ thống được hiểu như là các thành tố kiến trúc. Việc hiểu biết một domain người dùng có ý nghĩa then chốt như là một điểm khởi đầu đối với việc phát triển một hệ thống mà người dùng sẽ tìm thấy sự hữu ích và đáng giá.2. là một phạm vi khái quát của sự quan tâm có một tập hợp các concepts và các relationships được chấp nhận.

UML cung cấp nhiều kỹ thuật mô hình hoá khác nhau để truyền đạt ý tưởng với việc sử dụng các lược đồ (diagrams). Mỗi loại lược đồ có thế mạnh đối với một số vụ việc nào đó về một Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 42 . hệ thống quản lý dự án có thể được phân rả thành như sau đây: • • • Một hệ thống con giao diện người dùng chịu trách nhiệm cung cấp một giao diện mà qua đó người dùng có thể tương tác với hệ thống. Các hệ thống con (Subsystems) có thể lại được phân rả thêm nữa thành các hệ thống con của hệ thống con (sub-subsystems) và các thành tố cơ sở. hệ thống được xem như là một hệ thống không hướng đối tượng (non-object-oriented system). được gọi là các hệ thống con (subsystems) và các thành tố cơ sở (primitive elements). hệ thống được xem như một hệ thống hướng đối tượng (object-oriented system). Một hệ thống có thể được phân rả đệ quy thành các hệ thống nhỏ hơn. Một hệ thống con có ý nghĩa thành phần dữ liệu chịu trách nhiệm đối với việc cài đặt chức năng lưu trữ dữ liệu.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng các relationships của chúng định nghĩa cấu trúc của hệ thống. Khi mà các thành tố cơ sở chỉ là các thành tố dữ liệu và các hàm (functions) hay các thủ tục (procedures). Khi đã phân rả hoàn toàn. Một hệ thống con xử lý quy tắc doanh nghiệp chịu trách nhiệm đối với việc cài đặt các chức năng theo quy tắc doanh nghiệp. một hê thống và tất cả các hệ thống con của nó bao gồm các thành tố cơ sở. và vân vân. Các thành tố cơ sở không thể phân rả được thêm nữa. và cách các thành tố tương tác và cộng tác định nghĩa hành vi (behavior) của hệ thống. Ví dụ. Khi mà các thành tố cơ sở của một hệ thống hay hệ thống con là các đối tượng.

Toàn bộ các kiến trúc view khác nhau xác định các cách khác nhau mà qua nó chúng ta có thể hiểu được một hệ thống. toàn bộ các thành tố trong những hình như đã đề cập là các thành tố view khi chúng ta sắp xếp phân loại lược đồ mà trên đó chúng xuất hiện trong một view cụ thể. bao gồm functional. và số lượng bất kỳ các lược đồ có thể được sử dụng để để truyền đạt ý tưởng về hệ thống. Ví dụ. Ví dụ. và những phần khác của hệ thống quản lý dự án. các lược đồ diagrams phụ thuộc hai loại hay kiểu khái quát chung: Cấu trúc (structural) và hành vi (behavioral). Ví dụ.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng hệ thống. Các thành tố cấu tạo nên một view được hiểu như là các thành tố view. Chúng ta sẽ tìm hiểu về các loại lược đồ này trong một chương khác của quyển tài liệu này. Ngoài ra. Ngoài ra còn có các thành tố chung hơn áp dụng cho cả hai kiểu lược đồ. tất cả các hình được biểu diễn ở phần bên trên trong chương này có thể được tổ chức vào trong các view khác nhau. Các sections của UML là các kiến trúc view. UML còn cho phép chúng ta định nghĩa các lược đồ của chính mình. Ví dụ. Trong UML.2. Một kiến trúc view là một loại lược đồ thể hiện về một tập hợp các vấn đề quan tâm riêng biệt hay nói cách khác mỗi view là một thể hiện của hệ thống được mô hình hoá. behavioral. ngôn ngữ English nhóm các đoạn văn (paragraphs) vào trong các đề mục (sections). IV. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 43 .2. structural. nếu cần thiết.6 Sections Một section trong UML là một nhóm của những paragraphs theo một vấn đề chung. chúng ta có thể định nghĩa một lược đồ dạng database schema truyền đạt ý tưởng về các table trong một cơ sở dữ liệu và các mối qua hệ (relationships) của chúng.

nó có thể được xem như một thể hiện của lược đồ lớp. và hoạt động (activity) để mô tả sự tương tác (interactions) và sự cộng tác (collaborations) của các thành tố cấu tạo nên hệ thống. trang thái (state). o Lược đồ đối tượng (Object diagram): Mô tả cấu trúc tĩnh của hệ thống tại thời điểm xác định. nó không bắt buộc tường minh mọi kiến trúc view. Kiến trúc behavioral view hay Dynamic view Tập trung sự chú ý trên hành vi của hệ thống. với việc sử dụng các lược lớp (class) và các lược đồ đối tượng để mô tả các thành tố và các mối quan hệ nào cấu tạo nên hệ thống.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng Bởi vì UML là một ngôn ngữ chứ không phải một phương pháp luận (methodology). Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 44 • . sử dụng các lược đồ use-case để mô tả những chức năng nào mà hệ thống cung cấp cho những người dùng của nó. Trong đó: o Lược đồ lớp (class diagram): Mô tả cấu trúc tĩnh của hệ thống. thể hiện các thành phần hệ thống xử lý được. cộng tác (collaboration). tuy nhiên các lược đồ UML có thể được tổ chức tổng quát xung quanh các kiến trúc view tổng quát thường được sử dụng sau đây: • Kiến trúc use-case view hay user view hay scenario view Tập trung sự quan tâm trên chức năng của một hệ thống. với việc sử dụng các lược đồ tuần tự (sequence). • Kiến trúc Structure view hay Static view hay Logical view Tập trung sự chú ý trên cấu trúc của một hệ thống.

với việc sử dụng các lược đồ thành phần (component diagrams) để mô tả cách hệ thống được thực thi.7 Documents Một document của UML là một nhóm của các sections theo một chủ đề chung.2. UML cho phép chúng ta định nghĩa các kiến trúc view của riêng mình. nó mô tả tổ chức các thành phần thực thi trong hệ thống. Ví dụ. một lược đồ tương tác (interaction diagram) có thể được sử dụng trong một use-case view để mô tả cách những người dùng tương tác với một hệ thống. chúng ta có thể định nghĩa một một kiến trúc view lưu trữ dữ liệu. Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 45 . để mô tả các table trong một database và các mối quan hệ giữa chúng. nếu cần thiết. loại lược đồ bất kỳ có thể được sử dụng trong kiến trúc view bất kỳ. Hay nói cách khác. với việc bao gồm các lược đồ non-UML bất kỳ. Mặc dù mỗi loại lược đồ được tổ chức xung quanh một kiến trúc view đơn lẻ.2. Ví dụ. Chúng ta có thể kế đó sử dụng các loại lược đồ khác để mô tả các triggers và các stored procedures trong một database. và chúng ta có thể định nghĩa một loại lược đồ mới. IV. với việc sử dụng các lược đồ triển khai (deployment diagrams) để mô tả cách hệ thống hiện có thực thi trong môi trường của nó.CHƯƠNG 4: • UML và mô hình hoá hướng đối tượng Kiến trúc component view hay implementation view Tập trung sự chú ý trên sự thực thi của một hệ thống. có lẽ được gọi là một lược đồ database schema. Hơn nữa. • Mô hình kiến trúc deployment view hay environment view Tập trung sự chú ý vào môi trường thực thi.

mọi thành tố được sử dụng trên các lược đồ trong chương này. các kiến trúc view. mà còn giúp chúng ta đánh giá sự hiểu biết của chúng ta còn hơn là phải tiêu tốn các nguồn tài Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 46 . ngôn ngữ English nhóm các sections vào trong các documents. Một model là một trình bày của một hệ thống. với việc cung cấp tất cả các tài liệu cần thiết cho việc mô tả thành tố. trái lại bất kỳ phương pháp luận nào nói chung có thể hướng vào các model trong sự kết hợp với các kiến trúc view này. và các lược đồ (diagrams) tương tự như các mối quan hệ giữa các databases. Các tài liệu UML là các mô hình (models). views. các thành tố view thì tương tự như các thành tố dữ liệu được sử dụng bên trong các view. và truy vấn dữ liệu (queries). Các mô hình (Models) và các lược đồ (diagrams) giúp chúng ta nắm bắt và truyền đạt những gì chúng ta hiểu về các yêu cầu và hệ thống xuyên suốt toàn bộ quá trình chu trình sống triển khai hệ thống. Các thành tố cấu tạo nên một model được hiểu như là các thành tố model. Chúng không chỉ cho phép chúng ta quản lý sự thay đổi và sự phức tạp. và thông tin khác. Ví dụ. Bởi vì UML là một ngôn ngữ chứ không phải là một phương pháp luận. Mối qua hệ giữa các model. toàn bộ những hình trong chương này và các tài liệu nguyên bản của chúng là một model của hệ thống quản lý dự án. Ví dụ. các hình thái một thành tố model. nó không bắt buộc tường minh mọi bước đối với việc áp dụng các model triển khai hệ thống dựa trên các yêu cầu của nó. và các thành tố lược đồ tương tự như các thành tố dữ liệu được sử dụng bên trong các truy vấn dữ liệu. các view tổ chức các tập con dữ liệu thành thông tin đầy đủ ý nghĩa. Ví dụ. Một thành tố model tương tự như một thành tố dữ liệu trong cơ sở dữ liệu.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng những tài liệu nguyên bản. Một database houses data.

Learning UML .Sinan Si Alhir 2003 (O'Reilly) July Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 47 . Các mô hình capture tất cả chi tiết nhằm vượt qua sự cách biệt lớn giữ các yêu cầu và hệ thống.CHƯƠNG 4: UML và mô hình hoá hướng đối tượng nguyên cho việc sản sinh ra một hệ thống mà nó không thể được chấp nhận hoặc không đủ đáp ứng các yêu cầu. V Phần mềm (Software)  Rational Rose hoặc Microsoft Visial VI Tài liệu tham khảo 1.

Sign up to vote on this title
UsefulNot useful