Tài liệu UML và ứng dụng dể xây dựng mô hình cho hệ thống tín dụng

ĐẠI HỌC QUỐC GIA HÀ NỘI KHOA CÔNG NGHỆ MAI THỊ THANH HƯỜNG UML VÀ ÚNG DỤNG ĐỂ XÂY DỤNG MÔ HÌNH CHO HỆ THỐNG TÍN DỤNG LUẬN VĂN THẠC s ĩ KHOA HỌC • • • 0A> H ÇC C.UOC G f>- Î". TRŨKGTÀM ■ S’HGÎÎ-'- Y- tẸ. H À N Ộ I, N Ă M 2001 ft í Hư' sụ ĐẠI HỌC QUỐC GIA HÀ NỘI KHOA CÔNG NGHỆ MAI THỊ THANH HƯỜNG UML YÀ ÚNG DỤNG ĐỂ XÂY DựNG MÔ HÌNH CHO HỆ THỐNG TÍN DỤNG CH U YÊN N G À N H : CÔNG NGH Ệ THÔNG TIN M Ả SỐ: LUẬN VĂN THẠC s ĩ KHOA HỌC • « NGƯỜI HƯỚNG D AN KHOA HỌ C: PGS N G U Y Ẻ N HÀ NỘI, N Á M 2001 a Quốc T O Ả N MỤC LỤC CHƯƠNG 1 TỔNG QUAN VỀ ƯML...................................................................... 3 1.1 Mục đích của việc xây dựng mồ hình cho hệ thống.......................................... 3 1.2 Lịch sử phát triển của U M L ..................................................................................5 1.3 Mục liêu của U M L................................................................................................. 7 1.4 ứ n g dụng của U M L...............................................................................................7 1.5 Các thảnh phần của UML...................................................................................... 8 1.5.1 Các phần tử mô hình...............................................................................................8 1.5.2 Các biểu đồ..............................................................................................................9 1.5.3 Các view ................................................................................................................ 13 1.5.4 Các cơ chế chung của U M L................................................................................16 CHƯƠNG 2 PHÂN TÍCH, THIÊT KẾ HƯỚNG ĐÔÍ TƯỢNG s ử DỤNG UML ............................................................................................................ !............................................. 19 2.1 Phân tích Use case................................................................................................22 2.1.1 Actor.......................................................................................................................22 2.1.2 Xác định các Actor...............................................................................................23 2.1.3 Use case................................................................................................................. 24 2.1.4 Các mối quan hệ................................................................................................... 30 2.1.5 Biếu đồ Use c a se ...................................................................................................31 2.2 Tim lớ p .................................................................................................................. 34 2.2.1 Đối tượng............................................................................................................... 34 2.2.2 L ớ p .......r................................................................................................................ 34 2.2.3 Các quan h ệ ...........................................................................................................38 2.2.4 Gói......................................................................................................................... 42 2.2.5 Biểu đồ đối tượng.................................................................................................44 2.3 Phàn tích sự tương tác giữa các đối tượng.........................................................45 2.3.1 Kịch b ản ................................................................................................................ 45 2.3.2 Biểu đồ trình tự..................................................................................................... 47 2.3.3 Biểu đồ hợp tác..................................................................................................... 49 2.4 Them vào các thuộc tính và phương thức cho lớp........................................... 50 2.4.1 Thuộc tín h .............................................................................................................50 2.4.2 Phương thức........................................................................................................... 51 2.5 Xác định ứng xử của đối tượng.......................................................................... 52 2.5.1 Biểu đồ trạng th á i................................................................................................. 52 2.5.2 Biêu đồ hoạt động................................................................................................. 55 2.6 Xác định kiến trúc của hệ thống.........................................................................57 2.6.1 Thành phần (xem [3]).......................................................................................... 57 2.6.2 Biểu đồ thành phần...............................................................................................57 2.6.3 Biêu đồ triển k h ai.................................................................................................58 CHƯƠNG 3 - ÚNG DỤNG ƯML ĐỂ XÂY DựNG MÔHÌNH CHO HỆ THỐNG TÍN D Ụ N G .......................................................................................................................... 59 3 .1 Phát biểu bài toán.................................................................................................59 3.2 Mô tá nghiệp vụ.................................................................................................... 59 - 2 - 3.3 Mỏ tả quy trình kỹ thuật...................................................................................... 60 3.4 Yêu cầu.................................................................................................................. 60 3.5 Phân tích Use case................................................................................................ 61 3.5.1 Các Actor của hệ thống........................................................................................61 3.5.2 Danh sách Use case:.............................................................................................62 3.5.3 Mô tả các Use case...............................................................................................66 3.5.4 Các biểu đồ Use case............................................................................................71 3.6 Biểu đồ lớ p ............................................................................................................ 74 3.6.1 Các lớp thực thể (Entity Class)...........................................................................74 3.6.2 Các lớp biên (Boundary Classes)........................................................................83 3.6.3 Các lớp điều khiển (Control Classes).............................................................102 3.7 Sự tương tác giữa các đối tượng..................................................................... 103 3.7.1 Kịch b ả n .......7........................ '.......................................................................... 103 3.7.2 BỈểu đồ trình tự..................................................................................................104 3.7.3 Biểu đổ hợp tác..................................................................................................105 3.8 Biêu đồ triển k h a i............................................................................................. 106 KẾT LUẬN...................................................................................................................... 107 LỜI NÓI ĐẦU Trong những nãm gần đây, thuật ngữ UML đã dần trở nên quen thuộc đối với những người làm tin học nói chung và những người làm phần mềm nói riêng. Vậy UML là gì. nó được sử dụng để làm gì, cách thức sử dụng nó như thế nào? Luận văn “ UML và ứng dụng để xây dựng mô hình cho hệ thống tín dụng” sẽ trả lời cho các câu hỏi đó. Luận văn này gồm 3 phần. Phần I giới thiệu tổng quan về ƯML, sự ra đời, phát triển và các thành phần của ƯML. UML là một ngổn ngữ mô hình hoá thống nhất, nó tổng hợp được ưu điểm trong các phương pháp của 3 nhà sáng lập (Grady Booch, James Rumbaugh và Ivar Jacobson) và hạn chế khuyết điểm trong các phương pháp đó. UML được sử dụng đê mổ hình cho rất nhiều hệ thống, không nhất thiết phái là các hệ thống phần mềm. Phần II xây dựng quy trình cho việc phân tích thiết kế hệ thống sử dụng ƯML. Quy trình này bao gồm các bước như sau: Bước 1: Cách xác định các Actor, các use case, mối quan hệ giữa các use case từ đó xây dựng được biểu đồ use case. Bước 2: Cách xác định các lớp, các đối tượng, mối quan hệ giữa các lớp hay giữa các đối tượngbiểu đổ lớp và biểu đồ đối tượng. Bước 3: Cách xác định các kịch bản từ use case, từ đó xây dựng biểu đồ trình tự và biểu đồ hợp tác. Bước 4: Thêm vào các thuộc tính và phương thức cho các lớp Bước 5: Cách xác định các ứng xử của mỗi đối tượng thông qua biểu đồ trạng thái và biêu đồ hoạt động. Một số gợi ý để có thể xây dựng biểu đồ trạng thái từ biểu đồ trình tự. Bước 6: Xác định kiến trúc của hệ thống bẳng cách xác định các thành phần của hệ thống, xây dựng các biểu đồ thành phần và biểu đồ triển khai. Đối vói mỗi bước trong quy trình trên, luận văn đều đưa ra các ví dụ minh hoạ cụ thế. Phần III của luận văn tập trung vào việc sử dụng UML để mô hình hệ thống tín dụng. Tín dụng là một hoạt động rất quan trọng trong ngành Ngân Hàng, quản lý các hồ sơ và hợp đổng tín dụng là việc iàm không thế thiếu của các cán bộ tín dụng. Việc mô hình hệ thống tín dụng giúp các cán bộ tín dụng nói riêng và các cán bộ Ngân Hàng nói chung trong việc quản lý các hổ sơ. hợp đồng tín dụng một cách chính xác và hiệu quả. Phần III bắt đầu bàng việc tìm hiểu quy trình nghiệp vụ tín dạne. các yêu cầu mà hệ thống cần phải đáp ứng. Trên cơ sở các yêu cầu đó xây dựng nên một mô hình, việc xây dựng mô hình này áp dụng các lý thuyết đã được nêu ở phần II. Đầu tiên là xác định các Actor của hệ thống, sau đó liệt kê các use case có thể có dựa trên các yêu cầu đã được xác định trong phần trên. Việc xác định các lớp thực thể, các lớp biên và các lớp điểu khiển dựa vào các Actor và các use case đã tìm được. Việc mô tả chi tiết các use case giúp tìm kiếm các kịch bản và từ các kịch bản này các biểu đồ trình tự và biểu đồ hợp tác được xây dựng. Từ đó ta có thê hình dung được hệ thống theo cả hai mặt tĩnh và động. Phần này sử dụng công cụ Rational Rose để vẽ các lớp, các Actor cũng như các biểu đồ. Thông qua phần này, ta có thế hiểu được cách thức sử dụng UML đê’ giải quyết một bài toán trong thực tế. Trong quá trình làm chắc chắn không thể tránh khỏi những sai sót, em rất mong nhộn được sự góp ý của các thầy cô. Em cũng xin gửi lời cảm ơn chân thành đến PGS Nguyền Quốc Toản, người đã giúp đỡ em rất nhiều để em có thể hoàn thành luận vãn này. Hà Nội ngày 14 tháng 11 năm 2001 Mai Thị Thanh Hường CHƯƠNG 1 1.1 TỔNG QUAN VỀ UML Mục đích của việc xây dựng mò hình cho hệ thống Mô hình hóa là một cách xem xét bài toán thông qua việc sử dụng các mỏ hình. Mó hình sẽ giúp con người hiểu rõ bài toán, và thông qua mô hình việc trao đổi thống tin giữa những người liên quan như khách hàng, chuyên gia, người phân tích, người thiết kế trở nên thuận tiện hơn. Mô hình giúp cho việc xác định các yêu cầu tốt hơn, thiết kế rõ ràng hơn và khả năng bảo trì hệ thống cao hơn. Mô hình là sự trừu tượng hóa, mô tả mặt bản chất của một vấn đề hoặc một cấu trúc phức tạp bằng cách loại bò những chi tiết không quan trọng, khiến cho bài toán trở nên dễ hiểu và dễ nắm bắt hơn. Người ta đã sử dụng mô hình hoá để giải quyết các vấn đề của cuộc sống đời thường. Chẳng hạn trước khi sản xuất một chiếc ô tố, ta phải có bản thiết kế của chiếc ô tô đó, hình dáng của nó ra sao, màu sắc như thế nào? Việc phát triển các hệ thống phần mềm cũng tương tự như vậy. Để xây dựng một hệ thống phức tạp, những người phát triển phải trừu tượng hóa những View khác nhau của hệ thống, xây dựng các mô hình bằng cách sử dụng các kí hiệu, kiểm tra xem các mô hình đã thoả mãn các yêu cầu của hệ thống chưa và dần dần thêm vào các chi tiết để có thể chuyển đổi từ mô hình sang một cài đặt cụ thể. Một câu hỏi đặt ra là tại sao chúng ta phải xây dựng mô hình của hệ thống, đặc biệt là những hệ thống phức tạp? Bởi vì chúng ta không thể hình dung, không thể hiểu trọn vẹn một lúc toàn bộ hệ thống đó. Ví dụ như khi thêu một bông hoa chúng ta có thể thêu ngay, nhưng khi thêu một bức tranh ta phải có một bức tranh mẫu trên giấy. Trong việc sản xuất phần mềm cũng tương tự như vậy. Hệ thống càng phức tạp thì việc xây dựng mô hình càng quan trọng. Xây dựng mô hình cho phép người thiết kế thấy được bức tranh tổng quan của hệ thống, thấy được các thành phần của hệ thống tương tác với nhau như thế nào, hình dung được hệ thống từ nhiều View khác nhau. Ngày nav việc xây dựng các ứng dụng không còn là vấn đề, mà vấn đé là ớ chỗ xây dựng được các ứne dụng có chất lượng cao, đáp ứng đầy đủ các yêu cầu của khách hàng, đúng thời hạn và với chi phí hợp lý. Một tổ chức phát triển phần mềm thành công là tổ chức xây dựng được các phần mém thoả mãn được những yêu cầu trên. Mỏ hình hóa là phần trung tâm trong các cống việc để dẫn tới một phần mềm lốt. Người ta xây dựng mô hình để trao đổi, bàn bạc về cấu trúc và ứng xử (behavior) mong muốn của hệ thống. Người ta xây dựng mô hình để trực quan hóa và kiểm soát kiến trúc của hệ thống. Mô hình có thể mô tả các cấu trúc, nhấn mạnh về mặt tổ chức của hệ thống hoặc nó có thể mô tả các hành vi, tập trung vào mặt động của hệ thống. Việc xây dựng mô hình giúp chúng ta hiểu rõ hơn về hệ thống mà mình đang xây dựng, tạo ra cơ hội đê đơn giản hóa và tái sử dụng. Xâv dựng mô hình cũng giúp chúng ta Irong việc kiểm soát rủi ro. Việc xây dựng mô hình giúp chúng ta đạt được 4 mục đích sau: • Mô hình giúp chúng ta trực quan hóa hệ thống như là nó vốn có hay theo cách mà chúng ta muốn nó sẽ như vậy. • Mồ hình cho phép chúng ta chỉ rõ cấu trúc và ứng xử của hệ thống • Mô hình cho một khuôn mẫu đế hướng dẫn chúng ta trong quá trình xây dựng hệ thống. • Mô hình đưa ra các dẫn chứng bằng tài liệu về các quyết định mà chúng ta đã đưa ra trong quá trình thiết kế hệ thống. Bằng việc mô hình hoá, tại một thời điểm chúng ta chỉ tập trung nghiên cứu một khía cạnh nào đó của bài toán. Điều này cũng giống như việc chia một bài toán lớn thành các bài toán nhỏ mà ta có thê’ giải quyết được. Mỏ hình hóa là việc đơn gián hóa thực tế, loại bót những điểm không cần thiết, nhưng ta vẫn phải đảm bảo rầng mình không bỏ sót một chi tiết quan trọng nào. Tùy thuộc vào vêu cầu của từng bài toán, tuv vào đặc điểm của từng hệ thống, mỗi mô hình có thể tập trung vào những View khác nhau của hệ thống. - 1.2 5 - Lịch sử phát triển của UML Khái niệm đối tượng ra đời kéo theo sự ra đời của các phương pháp hướng đối tượng. Thập niên 90 đã xuất hiện một số phương pháp hướng đôí tượng chủ yếu sau (xem [2]): > Grady Booch: định nghĩa các khái niệm mà trong đó hệ thống được phân tích thành 1 số các view, mổi view được mỏ tả bằng một số biểu đồ mô hình. Phương pháp này có một khuyết điểm là có một số các ký hiệu khó sử dụng, khó vẽ. > OMT (Object Modeling Techique): do James Rumbaugh (trước làm ở General Electric) đưa ra. Nó là một tiến trình mạnh để kiểm nghiệm dựa trên việc đặc tả các yêu cầu. Được mô tả bởi một số các mô hình như mô hình đối tượng, mô hình động, mô hình chức năng, mô hình Use-case. > OOSE (Object - Oriented Software Engineering) /Objectory: do Ivar Jacobson đưa ra. OOSE là một phương pháp hướng đối tượng, phương pháp Objectory được sử dụng để xây dựng các hệ thống như hệ thống viễn thông cho Ericson, hệ thống kế toán cho công ty WallStreat. Cả hai phương pháp đéu dựa trên các Use-case mô tả các yêu cầu đầu tiên của hệ thống như là được các Actor ngoài nhìn thấy. Sau đó Use-case được thi hành trong tất cả các pha khi phát triển, tất cả các cách để kiềm nghiệm hệ thống khi nó được (lùng đê kiểm thử hệ thống. > Fusion do Hewlett-Packard đưa ra. > Coad/Yourdon (OOA/OOD). Các phương pháp trên, mỗi phương pháp lại có những điểm mạnh và điểm yếu riêng. Vấn đề là làm sao để có được một phương pháp tích hợp được những ưu điểm của mọi phương pháp trên và hạn chế những khuyết điểm của chúng. Ngoài việc tích hợp các ưu điểm, hạn chế các khuyết điểm, phương pháp mới này còn phải thống nhất được các ký hiệu của các phương pháp. Bởi vì cùng một ký hiệu nhưng dùng trong các phương pháp khác nhau lại có thể mang V nghĩa khác nhau. Vì vậy việc thống nhất được cách dùng các ký hiệu cũng là điều rất quan trọng. Grady Booch, James Rumbaugh và War Jacobson bắt đầu với UML khi họ làm việc cùng nhau tại công ly phần mềm Rational (Grady Booch và James Rumbaugh bắt đầu trước từ năm 1994 và đến 1995 thì Ivar Jacobsson mới gia nhập nhóm này). Mục tiêu của họ là tạo ra một phương pháp mới, phương pháp thống nhất dựa trên các phương pháp của Booch, Rumbaugh và Jacobson. Dựa vào việc hợp nhất các kv hiệu sử dụng trong khi phân tích, thiết kế của các phương pháp đó, UML đưa ra một nền tảng chuẩn cho việc phân tích, thiết kế. Tháng 7-1997 phiên bản 1.0 được còng bố và coi là chuẩn của tổ chức OMG (Object Management Group). Vé cơ bản ƯML dựa trên Booch của Booch, OM T của James Rumbaugh và OOSE của Ivar Jacobson nhưng họ cũng kết hợp một vài ý tưởng cuả các phương pháp khác như State Charts của David Hareỉ và chuyển nó thành State Diagram trong UML hay sử dụng thao tác đánh dấu trong chú thích của Fusion trong biểu đồ hợp tác (collaboration diagram). UML (Unified Modeling Laguage) được dùng để mô hình cho các hệ thống hay dùng trong những giai đoạn khác nhau của phát triển hệ thống từ đặc tả đến kiểm thử hệ thống cuối cùng. - 7 - Hình 1.1 R um haugh numbering 1.3 Mục tiêu của UML ■ Mô hình các hệ thống (không chỉ các hệ thống phần mềm), sử dụng các khái niệm hướng đối tượng ■ Tạo ra một ngôn ngữ mô hình có thể sử dụng được bởi cả người và máy. 1.4 ứ n g dụng của UML ƯML có ứng dụng rất rộng rãi, không chỉ trong các hệ thống phần mềm mà còn ở nhiều lĩnh vực khác như các hệ thống kỹ thuật hay các hệ thống kinh doanh, nghiệp vụ. Một số hệ thống mà ƯML có thể mô tả là: ■ Hệ thông tin: lưu trữ, tìm kiếm, biến đổi và trình bày thông tin cho người dùng. Phái giải quyết một số lượng lớn dữ liệu với mối quan hệ phức tạp thường được cất giữ trong CSDL quan hệ hav CSDL đối tượng. ■ Hộ thống kỹ thuật: giải quyết các hệ thống viễn thông, quân sự hoặc các tiến trình công nghiệp. ■ Hệ thống thời gian thực chìm (built in): được thực hiện thông qua lập trình mức thấp và đòi hỏi sự hỗ trợ thời gian thực * Hệ phân bố: được phân bố trên một số máy tính còn dữ liệu được truyền từ máy nọ sang maý kia. Hệ này đòi hỏi truyền thông đồng bộ, được xây dựng dựa trên các hệ hướng đối tượng như CORBA, COM/DCOM, JavaBean ■ Phần mềm hệ thống: hệ điều hành, CSDL ■ Hệ thống nghiệp vụ: mô tả các mục tiêu các nguồn tài nguvên (con người, máy tính), các quy tắc (luật, chiến lược kinh doanh) và công việc thực tại trong nghiệp vụ 1.5 Các thành phần của UML UML có 3 thành phần chính đó là các phần tử mô hình, các biểu đồ và các view. Phẩn tử mô hình là những khái niệm mà người la sử dụng trong các biểu đồ, hiểu hiện cho các khái niệm đối tượng nói chung. Nó được dùng trong nhiều biểu đồ khác nhau nhưng có cùng ký hiệu về ngữ nghĩa. View được tạo nên từ các biểu đồ. Mỗi view cung cấp cho ta một cái nhìn về một khía cạnh nào đó của hệ thống. Tập hợp các view cho ta một cái nhìn toàn cảnh về hệ thống. 1.5.1 Các phần tử mô hình Các khái niệm dùng trong các biểu đồ gọi là các phần tử mô hình. Một phần tứ mô hình được định nghĩa với ngữ nghĩa, 1 định nghĩa hình thức cho phần tử đó hay V nghĩa đích xác của điều nó biếu diễn. Một phần tử mô hình có một phần tử view tương írng là một thể hiện đồ hoạ của phần tử đó hay ký hiệu đồ hoạ được dùng để thể hiện phần tử trong các biểu đồ. Một phần tử có thể có mặt trong một vài loại biểu đồ khác nhau nhưng có một luật để xác định phần tử nào có thể có mặt trong biểu đổ nào. Một vài ví dụ về các phần tử mô hình là class, object, State, node, package, component. Class Object attributes attributes oprations oprations - 9 - / / Ọ Node u<;o rasp intprfarp / ~ n ................... Package Component Note T Hình 1.2 - các phần tử Các mối quan hệ cũng là các phần tử mô hình và được sử dụng để kết nối các phần tử mô hình với nhau. Một vài kiêu quan hệ khác nhau là: •S Association: Kết nối các phần tử và liên kết các thực thể. s Generalization: còn gọi là sự kế thừa, nghĩa là một phần tử có thể là trường hợp riêng của một phần tử khác, còn gọi là quan hệ chung - riêng. s Dependency: một phần tử phụ thuộc một phần tử khác theo một cách nào đó. s Aggregation: là một dạng của quan hệ association mà trong đó một phần tử chứa một hay nhiều phần tử khác, còn gọi là quan hệ toàn thể - bộ phận. association --------------------^ aggregation dependency (a form^of association) generalization > Hình 1.3 - Các liên kết 1.5.2 Các biểu đồ Biểu đổ (diagram) là các đồ thị mô tả các nội dung chứa trong view. UML có 9 loại hiểu đồ khác nhau. Phần lớn các biểu đổ được thể hiện như một đổ thị gồm các đinh (các sự vật) và các cung (các quan hệ). ([6]) UML có 9 loại biếu đồ chia thành 2 nhóm khác nhau. Nhóm thứ nhất gồm 4 loại hiểu đổ là biểu đồ lớp (class diagram), biểu đồ đối tượng (object diagram), biểu đổ thành phần (component diagram) và biểu đổ triển khai (deployment diagram). Nhóm này mô tả các phần tĩnh của hệ thống và được gọi là các biểu đổ cấu trúc - 10 - (stmctural diagrams) hay biểu đồ tĩnh. Nhóm thứ hai gồm các biếu đồ: biểu đồ Usecase (Use-case diagram), biểu đồ trình tự (sequence diagram), biểu đồ hợp tác (collaboration diagram), biểu đồ trạng thái (state diagram) và biểu đồ hoạt động (activity diagram). Các biếu đồ này mô tả phần động của hệ thống và được gọi là các biểu đồ cư xử (behavioral diagrams) hay biểu đồ động (dynamic diagrams). 1.5.2.1 Các biểu đồ câu trúc (structural diagrams) Bốn loại biểu đồ cấu trúc của UML cho phép ta hình dung, chỉ ra, xây đựng và làm tài liệu các khía cạnh tĩnh của hệ thống. Có thể coi các khía cạnh tĩnh của hệ thống như một sự thể hiện tương đối phần khung cố định. Giống như các mặt tĩnh của một ngôi nhà bao gồm các vật và cách sắp xếp như các bức tường, các cửa sổ, các ống dẫn và các lỗ Ihông, các mặt tĩnh của hệ thống phần mềm bao gồm các lớp, các giao diện, các sự hợp tác, các thành phần và các nút. Các biểu đồ cấu trúc của UML được tổ chức dựa trên các nhóm sự vật chính như sau: biểu đồ lớp dùng các lớp, các giao diện và các sự hợp tác, biểu đồ đối tượng dùng các đối tượng, biểu đồ thành phần dùng các thành phần còn biểu đồ triển khai dùng các nút. 1.5.2.1.1 Biểu đó lớp (class diagram) Biêu đồ lớp: chỉ ra tập hợp các lớp, các giao diện, các sự hợp tác và các mối quan hệ của chúng. Người ta sử dụng các biểu đồ lớp để minh hoạ thiết kế tĩnh của hệ thống. Các lớp biểu diễn cho các sự vật được xử lý bên trong hệ thống. Các lớp có thể có quan hệ với nhau theo một số cách sau: s Liên kết (lớp nọ nối với lớp kia) s Phụ thuộc ( 1 lớp này phụ thuộc hay dùng lớp kia) S Đặc biệt hoá (lớp này ỉà một phần tử đặc biệt của lớp kia) s Đóng gói (nhiều lớp gộp lại) Một hệ thống có nhiều biểu đổ lớp và ngược lại một biểu đồ lớp có thể có mặt ở nhiều hệ thống. 1.5.2.1.2 Biêu đó đỏi tượng (object diagram) - 11 - Biểu đồ đối tượng chỉ ra tập hợp các đối lượng và các mối quan hệ của chúng. Người ta sử dụng biểu đồ đối tượng để minh hoạ các cấu trúc dữ liệu, các thực thế của các lớp trong biểu đồ lớp. Có thê coi biểu đồ đối tượng là một biến thể cùa biểu đồ lớp, nó dùng các ký hiệu hầu hết giông biếu đổ lớp. Biểu đồ đối tượng chí ra một số thể nghiệm đối tượng của một lớp. 1.5.2.1.3 Biểu dó thành phần (component diagram) Biểu đồ thành phần chỉ ra tập hợp các thành phần và các mối quan hệ của chúng. Người ta sử dụng biểu đồ thành phần để minh hoạ sự Ihực thi tĩnh của hệ thống. Các biểu đồ thành phần được liên kết với các biểu đổ lớp khi thành phần đó ánh xạ đến một hoặc nhiều lớp. giao diện hay các sự hợp tác. Thành phần (component) có chứa thông tin về lớp logic mà nó cài đặt, và do vậy tạo ra một ánh xạ từ logical view sang component view. Biểu đồ thành phần được đùng trong công việc lập trình thực tế. 1.5.2.1.4 Biểu đồ triển khai (deployment diagram) Biểu đồ triển khai chỉ ra tập hợp các nút và các mối quan hệ của chúng. Người ta sử dụng các biểu đồ triển khai để minh hoạ phần triển khai tĩnh của kiến trúc (chỉ ra các máy tính và các thiết bị thực tế và các liên kết của chúng với nhau). Các biểu đồ triển khai được liên kết với biểu đổ thành phần khi mà nút đó bao gồm một hoặc nhiều thành phần. Bên trong mỗi nút các thành phần Ihực hiện được và các đối tượng được cấp phát để chỉ ra các đơn vị phần mềm nào thực hiện ở những nút nào. 1.5.2.2 C ác biểu đồ cư xử hay biểu đồ động (behavioral diagrams) Nãm loại biểu đồ cư xử do UML cung cấp được sử dụng để hình dung, xác định, xây dựng và làm tài liệu về các khía cạnh động của hệ thống. Ta có thể coi các khía cạnh động của hệ thống thê hiện cho các phần có thể thay đổi đó là luồng các thông báo và sự di chuyển vật lý của các thành phần trong mạng. Trong đó biểu đồ use-case thiết lập các cư xử của hệ thống, biểu đồ trình tự tập trung vào trình tự thời gian của các thông báo, biểu đổ hợp tác tập trung vào tổ chức về mặt cấu trúc của - 12 - các đối tượng truyền nhận thông báo, biểu đồ trạng thái tập trung vào sự thay đổi trạng thái của hệ thống tác động bởi các sự kiện còn biểu đổ hoạt động tập trung vào mô tả các sự cư xử có nhiều tiến trình song song. 1.5.2.2.1 Biêu đồ Use-case (Use-case diagram) (xem [4]) Biếu đổ Use-case chi ra 1 số Actor và mối nối của chúng với các trường hợp sử dụng (Use-case) mà hệ thống cung cấp. Nó mô tả về mặt chức năng mà hệ thống cung cấp, được mô tả bằng lời hoặc bằng biểu đồ Ưse-case. Đồng thời nó định nghĩa các yêu cầu chức năng cuả hệ thống. Các Actor ngoài không nhất thiết phải là con người mà có thể là các hình vẽ trong ban thân Ưse-casc diagram. Actor ngoài cũng có thổ là một hệ thống ngoài cần lấv thông tin từ hệ thống hiện thời. Biểu đồ Use-case là một công cụ cần thiết trong việc nắm bắt các yêu cầu, lên kế hoạch và kiểm soát dự án lặp lại. 1.5.2.2.2 Biểu đồ trình tự (sequence diagram) Biểu đồ trình tự chỉ ra sự hợp tác động giữa một số đối tượng. Tầm quan trọng của biểu đồ này là chỉ ra trình tự các thông báo được gửi đi giữa các đôí tượng, chỉ ra lương tác giữa các đối lượng. 1.5.2.2.3 Biểu đổ trạng thái (state diagram) Biểu đồ trạng thái chỉ ra tất cả các trạng thái có thể có mà các đối tượng của lớp có thể nhận được và những biến cố nào gây nên việc thay đổi trạng thái. Một biến cố có thê là một thông báo do đối lượng khác truyền đến hoặc là một điều kiện nào đó đã được hoàn thành. Việc thay đổi trạng thái được gọi là một phép chuyển. Một chuyển cũng có thể có một hành động được nối với nó để xác định ra cái gì cần được thực hiện sau. Loại biểu đồ nàv không được vẽ cho tất cả các lớp mà chỉ vẽ cho những lớp có 1 số trạng thái đã được xác định rõ và hành vi của lớp ấy bị ảnh hưởng, bị thay đổi bởi các trạng thái khác nhau. 1.5.2.2.4 Biểu đó hoạt động (activity diagram) Biểu đổ hoạt động chi’ ra luồng tuần tự các hoạt động, về cơ bản được dùng để mô tả cho các hoạt động được thực hiện trong một thao tác nhưng nó cũng có thể Á - 13 - dưực dùng để mô tả cho các luồng hoạt động khác như Use-case hay interact. Biểu đồ nàv bao gồm các trạng thái hành động, có chứa một đặc tả về hoạt động cần được thực hiện. Một Irạng thái hành động sẽ từ bỏ trạng thái dó khi hành động được thực hiện xong. Các quvết định và các điều kiện cũng như việc thực hiện song song các trạng thái hành động cũng có thể được biểu thị trong biểu đồ này. Nó kết hợp các ý tưởng từ rriột vài kỹ thuật như biểu đồ sự kiện (event diagram) của Jim Odell, kỹ thuật mô hình trạng thái SDL, workflow modeling và mạng Petri. Các biểu đồ này đặc biệt hữu dụng khi kết hợp với workflow và trong việc mô tả sự cư xử mà sự cư xử đó có nhiều tiến trình song song. Biểu đồ hành động là một biến thể của biểu đồ trạng thái trong trường hợp các trạng thái là các trạng thái hành động. 1.5.2.2.5 Biểu đổ hợp tác (collaboration diagram) Biểu đồ hợp tác chỉ ra sự hợp tác động, nó giống như biểu đồ trình tự nhưng Ihường là sự lựa chọn để biểu thị sự hợp tác hoặc như một biểu đồ tuần tự. Nó là một cách khác đê thể hiện một tình huống có thể xảy ra trong hệ thống nhưng tập trung vào việc thê hiện việc trao đổi qua lại các thông báo giữa các đối tượng chứ không quan tâm đến thứ tự của các thông báo đó. Qua biểu đổ này ta sẽ nhanh chóng biết được giữa 2 đối tượng cụ thê nào đó có trao đổi những thông báo gì cho nhau. 1.5.3 Các view View chí ra các mặt khác nhau của hệ thống như đã được mô hình. View không phái là đổ thị nhưng nó là một đôí tượng trừu tượng bao gồm một số các biểu đổ. Chỉ bàng việc định nghĩa một số các view, mỗi cái chỉ ra 1 khía cạnh đặc biệt của hệ thống, ta có một bức tranh hoàn chỉnh về hệ thống cần xây dựng. View gắn các ngôn ngữ mô tả với các phương pháp, các tiến trình. UML có 5 loại view là Usecase view, logical view, component view, concurrency view và deployment view. - 14 - Hình 1.4 1.5.3.1 Use-case view Use-case view chỉ ra chức năng của hệ thống như được Actor ngoài cảm nhận thấy. Nó không chỉ ra cách cấu trúc của hệ thống mà dùng là cơ sở đê' làm hợp lệnh kiểm chứng cuối cùng để xem hệ thống có đáp ứng được yêu cầu đề ra hay không. Người dùng thông qua view này để kiểm tra xem các yêu cầu của mình có được đáp ứng đầy đủ không, có cần thay đổi gì trong các chức năng của hệ thống hay không? Thông thường view này được dành cho khách hàng, người thiết kế, lập trình và kiểm thử. Biểu đồ dùng cho view này là biểu đổ Use Case. 1.5.3.2 Logical view Logical view mô tả cách mà chức năng của hệ thống được cung cấp. Nó xác định cả tính bền vững và tính tương tranh cũng như các giao diện và cấu trúc bên trong lớp. Ngược với Use-case view, logical view xem xét bên trong hệ thống. Nó mỏ tả cách thức, chức năng được thiết kế bên trong hệ thống dưới dạng cấu trúc tĩnh - 15 - (các lớp, các đối tượng và các mối quan hệ) và các sự hợp tác động xuất hiện khi các đối tượng gửi thông báo cho nhau để cung cấp các chức năng đã được đưa ra. Cấu trúc tĩnh được mô tả trong các biểu đồ lớp và đối tượng. Mô hình động được mô tả trong các biểu đồ trạng thái (state diagram), biểu dồ tuần tự (sequence diagram), hiểu đổ hợp tác (collaboration diagram), biêu đồ hoạt động (activity diagram). View này chủ vếu dùng cho người thiết kế và ngưưì phát triến. 1.5.3.3 Component view Component view chi ra việc tổ chức các thành phần của chương trình. Nó mô lá các modul cài đặt và sự phụ thuộc lẫn nhau cho các modul đó, bao gồm biểu đồ thành phần (component diagram). View này chủ yếu dùng cho người phát triển. Các thông tin thêm về sự quản trị như các báo cáo về sự tiến bộ của công việc cũng có thể được thêm vào. 1.5.3.4 Concurrency view Concurrency view chỉ ra tính chất tương tranh trong hệ thống đề cập đến các vấn đề liên quan đến truyền thông và đồng bộ hoá thường có ở trong các hệ thống tương tranh. Nó chia các hệ thống tương tranh thành các tiến trình và các bộ xử lý, cho phép người ta sử dụng tài nguyên một cách hiệu quả, thực hiện song song và giải quyết các vấn đề không đổng bộ. Giải quyết việc truyền thông và đồng bộ hoá giữa các mạch. View này dành cho người phát triển và người thiết lập hệ thống. View này bao gồm các biểu đổ động (dynamic diagram) như biểu đồ trạng thái (state diagram), biểu đồ trình tự (sequence diagram), biểu đồ hợp tác (collaboration diagram), biểu đồ hoạt động (activity diagram) và các biểu đổ thực thi (implementation diagram) như biểu đồ thành phần (component diagram) và biểu đồ triển khai (deployment diagram). 1.5.3.5 Deployment view Deployment view chỉ ra việc triển khai hộ thống trong một kiến trúc vật lý có dùng máy tính và các thiết bị (các nút). Nói cách khác là nó mô tả việc triển khai vật lý của hệ thống. View này dành cho người phát triển, tích hợp và kiểm thử. - 16 - 1,5.4 Các cơ chê chung của UML Các cơ chế chung đưa ra các lời chú thích phụ, các thông tin, các ngữ nghĩa cho các phần tử mô hình, đưa ra các cơ chế mở rộng UML cho từng tổ chức, cho từng chương trình riêng. 1.5.4.1 Chú thích Dù cho mức độ bao quát của một ngôn ngữ có cao đến đâu thì cũng có những thứ chưa được định nghĩa trong ngôn ngữ đó. Để có thể đưa thêm thông tin vào mô hình mà nếu không thì không thể thể hiện được hết mọi điều, ƯML cung cấp khả nâng chú thích. Một chú thích có thể được đặt bất cứ chỗ nào trong biểu đồ và có thể chứa bất kỳ loại thông tin nào. Loại thông tin mà nó chứa là một chuỗi không được thông dịch bởi UML. Chú thích được gắn vào một vài phần tử trong biểu đổ vói đường không liền nét chỉ ra phần tử nào được giải thích thêm hay chi tiết hoá với thông tin trên chú thích. Một chú thích thường chứa các dẫn giải hay các câu hỏi từ người làm mô hình như là một trình nhấc để giải quyết các tình trạng khó xử trong thời gian sau. Một chú thích có thể có các khuôn mẫu (stereotype) mô tả kiểu chú thích. Một chú thích biểu diễn một lời chú giải không có ảnh hướng về ngữ nghĩa, nghĩa là nội dung của nó không làm thay đổi nghĩa của mô hình mà nó gắn vào. Điều này giải thích tại sao các chú thích thường được sử dụng để đặc tả các thứ như các yêu cầu, các nhận xét và các sự giải thích và các ràng buộc. ([6]) Một chú thích có thể chứa bất kỳ sự phối hợp văn bản hay đồ thị nào. Ta có thể đưa vào một URL, thậm chí liên kết hay nhúng vào một tài liệu khác. Theo cách ta bạn có thê dùng UML để tổ chức tất cả các artifact bạn sẽ sinh ra hay dùng trong khi phát triển. Một chú thích là một biểu tượng đồ hoạ để diễn tả các ràng buộc hoặc các lời chú giải gắn vào một hay một tập hợp các phần tử. Bằng biểu đồ, một chú thích được biêu diễn như một hình chữ nhật với một nếp quân ở góc, cùng với chú giải bằng văn bản hoặc đồ hoạ.