phân tích phần mềm với uml

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA CÔNG NGHỆ PHẦN MỀM LỚP SE101.E11  Đề tài: PHÂN TÍCH PHẦN MỀM VỚI UML GVHD: NGUYỄN CÔNG HOAN SVTH: Lăng Hoài Sang 11520327 Vũ Văn Thuận 11520396 Huỳnh Hồ Thị Mộng Trinh 11520431 BÁO CÁO CUỐI KÌ Mục lục I. Mở đầu: Trong quá xây dựng, đối với một căn nhà nhỏ thì chúng ta có thể bắt đầu vào xây dựng ngay, chúng ta có thể tự mình xây chúng. Nhưng đối với một căn nhà to: nhà lầu, vila, biệt thự…, trong quá trình xây dựng cần sự hợp tác của nhiều người, có mối quan hệ giữ kĩ sư – thầu – chủ nhà, để mối giao tiếp đó diễn ra dễ dàng ta cần có bản thiết kế. Trong lĩnh vực phần mềm cũng vậy, phần mềm càng lớn 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 phần mềm, thấy được các tương tác giữa người dùng và phần mềm, thành phần của phần mềm tương tác với nhau. Để hỗ trợ cho việc đó, người ta sử dụng một ngôn ngữ mô hình hóa đó chính là UML. Trong đề tài “UML trong phân tích thiết kế phần mềm”, chúng em xin giới thiệu về ngôn ngữ UML và vai trò của nó trong việc phân tích thiết kế phần mềm. Trong quá trình xây dựng phần mềm quản lí thư viện, chúng ta sử dụng UML như thế nào? Một số biểu đồ thường dùng sẽ được giới thiệu thông qua việc phân tích cụ thể một nhánh của quá trình. Ngoài những vấn đề trên chúng xin giới thiệu một mô hình đã ứng dụng thành công UML vào việc phân tích thiết kế phần mềm. Đó là RUP. II. UML và ứng dụng của UML trong phân tích thiết kế phần mềm: 1. Sơ lượt về UML: - UML là ngôn ngữ chuẩn công nghiệp được dùng chủ yếu trong lĩnh vực khoa học máy tính và công nghệ phần mềm. - UML là ngôn ngữ trực quan (tức là sử dụng các biểu tượng để mô tả các vấn đề và công việc) được dùng trong pha phân tích và pha thiết kế trong quy trình xây dựng một phần mềm hướng đối tượng. - UML là ngôn ngữ kí hiệu bao gồm hệ thống các kí hiệu và bộ các nguyên tắc để kết hợp các kí hiệu đó với nhau để mô tả thiết kế phục vụ cho vấn đề giao tiếp. - UML cho ta biết cách tạo ra và đọc hiểu một mô hình, nhưng UML không cho ta biết những mô hình nào nên tạo ra và khi nào tạo ra chúng. Đó là nhiệm vụ của qui trình phát triển phần mềm. - Lợi ích của việc sử dụng UML trong quá trình phân tích thiết kế phần mềm: • UML cung cấp giao diện đồ họa trực quan, đơn giản, dễ đọc, dễ hiểu. • UML giúp cho việc trao đổi thông tin giữ những người tham gia vào dự án: khách hàng, nhà phân tích, nhà thiết kế, người lập trình … trở nên dễ dàng hơn. • UML và OOAD giúp cho việc xác định yêu cầu, phân tích thiết kế tốt hơn, đảm bảo người tham gia sau vào dự án cũng có thể đọc hiều được. Tạo sự thống nhất trong suốt quá trình phát triển phần mềm. • Khả năng bảo trì hệ thống cao hơn, dễ tiến hóa và tái sử dụng. • Một trong những nguyên nhân gây sự thất bại dự án là: xác định sai, không chính xác nhu cầu người dùng, phần mềm không đảm bảo tính tiến hóa, sự khả chuyển, khó bảo trì và tái sử dụng. Sử dụng UML làm giảm nguy cơ thất bại của dự án phần mềm. - Như vậy việc sử dụng UML trong quá trình phân tích thiết kế phần mềm là vô cùng cần thiết và có hiệu quả. 2. Các sơ đồ trong UML và chức năng của nó: - Các sơ đồ trong UML: - UML cung cấp các loại sơ đồ biểu diễn theo hai hướng khác nhau của hệ thống phần mềm: hướng cấu trúc và hướng hành vi: • Hướng cấu trúc: nhấn mạnh cấu trúc tĩnh của phần mềm bao gồm các đối tượng, thuộc tính, phương thức và mối quan hệ giữa các đối tượng: sơ đồ class, sơ đồ đối tượng, sơ đồ đóng gói, sơ đồ triển khai … • Hướng hành vi: nhấn mạnh cấu trúc động của hệ thống, thể hiện hành vi của hệ thống phần mềm thông qua sự hợp tác của các đối tượng, sự thay đổi trạng thái của các đối tượng: sơ đồ cộng tác, sơ đồ người dùng, sơ đồ hoạt động … - Mỗi biểu đồ là một loại hình vẽ mô tả phần mềm trong một khung nhìn. Các biểu đồ hay sử dụng: Use-case diagram, Class diagram, Activity diagram, State diagram, Sequence diagram, Collaboration diagram. - Vai trò của các loại sơ đồ trong quá trình phân tích thiết kế phần mềm: 2.1. Use Case Diagram: • Là biểu đồ thể hiện sự tương tác, mối quan hệ giữa các Use Case và các Actor trong hệ thống phần mềm • Phục vụ cho việc trao đổi thông tin. Nó cung cấp phương tiện để khách hàng, những người dùng tương lai của phần mềm và những người phát triển phần mềm có thể trao đổi với nhau về biến những yếu cầu về mặt nghiệp vụ của người dùng thành những yếu cầu cụ thể mà lập trình viên có thể hiểu một cách rõ ràng. • Dùng để mô hình hóa các chuỗi hành động của phần mềm. Cung cấp một cách nhìn tổng thể về những gì mà hệ thống sẽ làm và ai sẽ dùng nó. Đưa ra cơ sở để xác định giao tiếp người – máy của hệ thống. Dùng để mô hình hóa các kịch bản (scenario) cho một trường hợp sử dụng. Để người dùng cuối có thể hiểu được và có thể giao tiếp với hệ thống ở mức tổng thể. Làm cơ sở cho việc phác thảo ra các đặc tả kiểm tra. 2.2. Activity Diagram: • Activity Diagram là một dạng đặc biệt của biểu đồ State. Nó chỉ ra luồng đi từ hoạt động này sang hoạt động khác trong một hệ thống. Nó đặc biệt quan trọng trong việc xây dựng mô hình chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi quyền kiểm soát giữa các đối tượng. • Biểu đồ hoạt động là một phương tiện mô tả các dòng công việc (workflow) và được dùng theo nhiều cách khác nhau. • Biểu đồ hoạt động được dùng để: mô tả chi tiết bên trong một thao tác; ngoài ra trước khi xác định các use-case nó còn được dùng để xác định các yêu cầu nghiệp vụ ở mức cao; là phương tiện mô tả các use-case và các hành vi phức tạp bên trong đối tượng; diễn tả các ứng xử của nhiều đối tượng qua nhiều use-case; các biểu đồ hoạt động bổ sung cho biểu đồ tương tác, và có quan hệ mật thiết với biểu đồ trạng thái • Biểu đồ hoạt động gồm hoạt động (activity), trạng thái (state) và chuyển tiếp (transition). Nếu các hoạt động là chủ yếu thì ta gọi là biểu đồ hoạt động; còn nếu trạng thái là chủ yếu thì ta gọi là biểu đồ trạng thái. Nói chung thì khái niệm biểu đồ hoạt động rộng hơn, vì có thể xem trạng thái cũng là một dạng hoạt động (ví dụ như chờ). • Một vài Activity Diagram có thể dùng thay thế cho State machince Diagram. 2.3. Sequence Diagram: • Sequence Diagram là một dạng biểu đồ tương tác (interaction), biểu diễn sự tương tác giữa các đối tượng theo thứ tự thời gian. Nó mô tả các đối tượng liên quan trong một tình huống cụ thể và các bước tuần tự trong việc trao đổi các thông báo (message) giữa các đối tượng đó để thực hiện một chức năng nào đó của hệ thống. • Biểu đồ tuần tự có thể sử dụng cả trong pha phân tích và pha thiết kế hướng đối tượng, Biểu đồ này có 3 mức: mức hệ thống (system-level) được sử dụng để diễn tả chính xác scenario, nghĩa là chỉ có hai tác nhân tham gia là tác nhân bên ngoài và hệ thống (tức là phần mềm); mức dịch vụ (service- level) mô tả các dịch vụ, trong đó tương tác là các hành động, không hẳn là phương thức của các đối tượng; và mức phương thức (method-level) trong đó các tương tác chủ yếu là các phương thức của các đối tượng. Thực ra mức này trong tài liệu gốc được gọi là mức đối tượng (object-level), nhưng cách gọi này không thể hiện được bản chất của vấn đề, vì trong biểu đồ tuần tự ở mức nào cũng do các đối tượng tham gia cả. Trong phân tích thiết kế hướng đối tượng thì khái niệm đối tượng được sử dụng với nghĩa rất rộng, hầu như mọi vật đều là đối tượng, chứ không hẳn chỉ là thể hiện của lớp. Mức phương thức thường được dùng trong pha thiết kế để xác định các phương thức của các lớp. Trong biểu đồ nếu đối tượng đích là thể hiện của lớp thì tên tương tác chính là tên phương thức của đối tượng đích. Còn nếu đối tượng đích là tác nhân hay đối tượng kiểu như bảng dữ liệu thì tên tương tác là tên thông tin chuyển đến. Trong quá trình phân tích thiết kế hướng đối tượng người ta thường vẽ biểu dồ mức phương thức. • Tương tác trong biểu đồ tuần tự là lời gọi phương thức của đối tượng, nhưng cũng có khi chỉ là một hành động bình thường. Hành động này không hẳn là lời gọi phương thức, mà nó chỉ gợi ý cho ta xây dựng các phương thức của các lớp tham gia biểu đồ mà thôi. Cách biểu diễn các đối tượng cũng rất khác nhau: có khi là vòng tròn với một vài quy uwowsc đặc biệt, có khi chỉ là hình chữ nhật đơn giản. 1.1. State Diagram: • State Diagram chỉ ra một máy chuyển trạng, bao gồm các trạng thái, các bước chuyển trạng và các hoạt động. Nó đặc biệt quan trọng trong việc mô hình hóa hành vi của một lớp giao diện (interface class) hay collaboration và nó nhấn mạnh vào các đáp ứng theo sự kiện của một đối tượng, điều này rất hữu ích khi mô hình hóa một hệ thống phản ứng (reactive). • Biểu đồ trạng thái (state diagram) là một phương tiện mô tả các sự thay đổi trạng thái của các lớp (thực ra là các đối tượng). Về hình thức, biểu đồ trạng thái giống biểu đồ hoạt động, trong đó công việc được thay bằng trạng thái. Biểu đồ hoạt động chủ yếu được dùng để mô tả các dòng công việc (workflow), còn biểu đồ trạng thái lại được dùng để mô tả sự thay đổi trạng thái của một lớp (thực chất là thể hiện của lớp, tức là đối tượng). Ví dụ máy điện thoại có thể có các trạng thái: đang gác máy, đang quay số, máy bận và bị ngắt kết nối. Như vậy, biểu đồ trạng thái chủ yếu được dùng để mô tả hành vi của các lớp. Tuy nhiên chúng cũng được dùng để mô tả hành vi của các phần tử khác, như use-case, actor, hệ thống con và thao tác. Các biểu đồ trạng thái còn được sử dụng trong quy trình phân tích để mô tả hành vi phức tạp của các phần tử trong môi trường hệ thống, chẳng hạn như hành vi của một khách hàng. Biểu đồ trạng thái là một trong những biểu đồ của UML dùng để mô tả các dòng (các biểu đồ khác là: biểu đồ hoạt động, biểu đồ tuần tự và biểu đồ cộng tác). Tuy nhiên, biểu đồ trạng thái mô hình hóa các hành vi từ góc độ một thực thể, chẳng hạn như một lớp; còn biểu đồ hoạt động và biểu đồ cộng tác có thể lập mô hình hành vi cho nhiều thực thể • Biểu đồ trạng thái dùng để biểu diễn sự thay đổi trạng thái của một lớp tương ứng với các thông điệp mà lớp đó gửi đi hoặc nhận được: sử dụng để mô tả ứng xử của một đối tượng trải qua nhiều use-case, vẽ biểu đồ trạng thái cho những lớp mà các ứng xử của chúng không dễ hiểu và do đó cần mô tả chi tiết hơn • Biểu đồ trạng thái không phải là công cụ tốt để mô tả cách ứng xử của các đối tượng khi tương tác với nhau. Biểu đồ trạng thái chủ yếu được dùng để mô tả các trạng thái và các sự kiện, hoạt động trong vòng đời của một đối tượng 2.4. Class Diagram: • Biểu đồ lớp mô tả các kiểu đối tượng trong hệ thống và các mối quan hệ tĩnh giữa chúng. • Biểu đồ lớp cho ta biết những thành phần tạo nên phần mềm và mối liên quan giữa chúng. Biểu đồ này chỉ cho biết mối liên quan tĩnh giữa các thành phần. Để thấy được mối tương quan động giữa chúng ta còn cần tới các biểu đồ khác như biểu đồ hoạt động, biểu đồ trạng thái, biểu đồ tương tác (tuần tự và cộng tác). 2.5. Collaboration Diagram: • Gần giống như biểu đồ Sequence, biểu đồ Collaboration 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 nó 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 đó. Có nghĩa là qua đó chúng ta sẽ biết được nhanh chóng giữa 2 đối tượng cụ thể nào đó có trao đổi những thông báo gì cho nhau. • Biểu đồ cộng tác được dùng trong quá trình diễn tả tỉ mỉ biểu đồ lớp nhằm giúp người phân tích hiểu được các nhóm đối tượng tham gia thực hiện một use-case như thế nào. Biểu đồ cộng tác được sử dụng khi biểu đồ lớp không diễn tả được hết ý nghĩa tương tác giữa các đối tượng. Ngoài ra biểu đồ cộng tác còn được dùng để xác định các đối tượng có liên quan trong các thao tác. • Một biểu đồ cộng tác chỉ ra một sự tương tác động, cũng giống như một biểu đồ tuần tự. Việc lựa chọn loại biểu đồ nào được thực hiện theo gợi ý sau: nếu trình tự thời gian là quan trọng hơn thì hãy chọn biểu đồ tuần tự, còn nếu vai trò lớp trong tương tác quan trọng hơn thì hãy chọn biểu đồ cộng tác. Trong biểu đồ cộng tác, các thông điệp được đánh số thứ tự để chỉ thứ tự thời gian thực hiện chúng. 2.6. Object Diagram: • Object Diagram rất giống Class Diagram. • Object Diagram cũng cho thấy các mối quan hệ giữa đối tượng nhưng nó sử dụng những ví dụ cụ thể. • Bao gồm một tập hợp các đối tượng và mối quan hệ giữa chúng. Đối tượng là một thể hiện của lớp, biểu đồ đối tượng là một thể hiện của biều đồ lớp. 2.7. Component Diagram: • Dùng để mô tả mối quan hệ cấu trúc các thành phần của một hệ thống phần mềm. • Chỉ ra cách tổ chức và sự phụ thuộc của các thành phần (component). Nó liên quan tới biểu đồ lớp, trong đó một thành phần thường ánh xạ tới một hay nhiều lớp, giao diện, collaboration. • Thường dùng cho các hệ thống phức tạp nhiều thành phần. Các thành phần kết nối với nhau bằng cách sử dụng giao diện. Các giao diện dược kết nối với nhau bằng kết nối. 2.8. Deployment Diagram: • Cho thấy phần cứng của hệ thống và các phần mềm trong các phần cứng và mối liên hệ giữa chúng. • Deployment Diagram rất hữu ít khi giải pháp phần mềm được triển khai trên nhiều máy tính với nhau có cùng cấu hình duy nhất. 2.9. Package Diagram: • Package Diagram: cho thấy sự khác nhau giữa các gói trong cùng một hệ thống. • Package: tập hợp các yếu tố ngữ nghĩa có liên quan. 2.10. Profile Diagram: • Là một loại Diagram mới, chỉ xuất hiện trong UML 2, và rất ít sử dụng. 2.11. Composite Structure Diagram: • Composite Structure Diagrams: được sử dụng để hiển thị các cấu trúc bên trong của một lớp • Phân loại tương tác với môi trường thông qua các cổng (Port) • Kết hợp với mô hình collaboration use diagram. 2.12. Communication Diagram: • Communication Diagram: tương tự như sequence diagrams nhưng nó tập trung chính vào mối quan hệ giữa các đối tượng, các trao đổi giữa các đối tượng (Ví dụ như A trao cho B cái gì, khi nào trao… ). 2.13. Interaction OverView Diagram: • Interaction overview diagrams tương tự activity diagrams • Activity diagrams cho thấy 1 chuổi các qui trình thì Interaction overview diagram cho ta thấy một chuổi các tương tác. 2.14. Timing Diagram: • Timing Diagram cũng tương tự như Sequence Diagram • Nó đại diện cho hành vi của hệ thống trong một hành vi. 3. Năm góc nhìn của UML trong việc phân tích thiết kế phần mềm: - Góc nhìn (khung nhìn, hay hướng nhìn): là một khái niệm trong UML, chứ không phải là một thành phần biểu diễn có thể nhìn thấy được như use-case, biểu đồ, lớp Trong đời thường, khi quan sát một vật thể phức tạp ta phải nhìn từ nhiều hướng khác nhau. Khi biểu diễn các vật đó trên giấy cũng không thể chỉ biểu diễn trong một bản vẽ duy nhất mà phải dùng nhiều bản vẽ, mỗi bản vẽ biểu diễn vật từ một hướng nhìn. Với một phần mềm phức tạp cũng vậy, ta cũng phải quan sát từ những hướng khác nhau. Tuy nhiên hướng ở đây không còn được hiểu theo nghĩa đen nữa, vì phần mềm không phải là một vật có thể quan sát một cách rõ ràng như ngôi nhà, chiếc cầu Hướng nhìn ở đây được hiểu là các khía cạnh khác nhau cần mô tả, mô hình hoá và trừu tượng hoá của hệ thống. Mỗi hướng nhìn gồm một số loại biểu đồ khác nhau. 3.1. Góc nhìn người dùng (Use case view): • Thể hiện mối quan hệ giữa người dùng cuối và phần mềm. Góc nhìn người dùng mang tính trung tâm, vì nó là cơ sở cho các hướng nhìn khác. • Bao gồm các Use Case mô tả ứng xử của hệ thống theo cách nhìn nhận của người dùng, người phân tích phần mềm. Nó không chỉ ra cách cấu trúc của hệ thống phần mềm, nó chỉ dùng để nhìn nhận một cách tổng quát những gì mà hệ thống sẽ cung cấp, thông qua đó người dùng có thể kiểm tra xem các yêu cầu của mình đã được đáp ứng đầy đủ hay chưa hoặc có chức năng nào của phần mềm là không cần thiết. Biểu đồ dùng đến là biểu đồ Use Case. [...]... được kí hiệu là hình nhân - Yêu cầu phần mềm được kí hiệu lad một hình elip Người dùng tác động trực tiếp tới yêu cầu phần mềm dùng mũi tên nét liền - Các mũi tên nét đứt ( ) thể hiện sự tham chiếu, liên kết giữa các yêu cầu phần mềm với nhau Nhân viên thủ thư tác động trực tiếp đến các yêu cầu TraCuuDocGia, ChoMuonSach, NhanTraSach, BCTKChoMuonSach, TraCuuSach Phân tích nghiệp vụ tra cứu sách: • TraCuuSach:... tin qua thủ kho Tại thủ kho, phần mềm sẽ kiểm tra lại thông tin một lần nữa, hợp lệ thì sẽ cập nhật sách hiện có và gửi lại cập nhật cho Thủ thư, không hợp lệ sẽ thông báo lại cho thủ thư và kết thúc yêu cầu 8 Sơ đồ Deployment: Thể hiện quan hệ giữa các thành phần phần cứng trong cơ sở hạ tầng vật lí Mô tả chi tiết các phần cứng cũng như giao thức kết nối giữa các phần cứng với nhau Như ở ví dụ trên thì:... Bao gồm các component và file tạo nên hệ thống vật lý Nó chỉ ra sự phụ thuộc giữa các thành phần này, cách kết hợp chúng lại với nhau để tạo ra một hệ thống thực thi 3.5 - - III Góc nhìn triền khai (Deployment view): • Chỉ ra cấu hình phần cứng mà hệ thống sẽ chạy trên đó Nó thể hiện sự phân tán, cài đặt các phần mà tạo nên kiến trúcvật lý của hệ thống Biểu đồ được sử dụng là biểu đồ Deployment Kết... cần tra cứu Phần mềm hiển thị các kết quả tìm được Kịch bản phụ: o Người dùng có thể chọn vào tìm kiếm nâng cao để lọc ra những thông tin cần thiết o Người dùng mở màn hình tra cứu sách nâng cao o Nhập thông tin cần tra cứu o Phần mềm hiển thị kết quả tìm được Kịch bản xử lý lỗi: o - - 5 Sơ đồ class: - Cung cấp logical view chi tiết: FormTraCuuSach sau khi mở lên và nhập đầy đủ hoặc một phần thông tin... vai trò của mỗi người tham gia vào dự án thì có sử dụng các góc nhìn khác nhau cũng như một, một phần hoặc toàn bộ các biểu đồ của từng góc nhìn Trong các góc nhìn trên đây thì góc nhìn use-case và góc nhìn logic đóng vai trò quan trọng cốt yếu trong phân tích và thiết kế hướng đối tượng Ví dụ và phân tích: 4 Sơ đồ Use Case: - Actor (Các tác nhân) - ThuThu: Là người phụ trách việc cho mượn sách và... FormTraCuuSach - Mô tả các lớp, interface và quan hệ giữa chúng • Các lớp được thiết kế rõ ràng như hình vẽ: gồm 5 lớp với những thuộc tính, phương thức đặc trưng • Quan hệ được thể hiện rõ qua hình với những con số 0 1(quan hệ 11) hay 0 *(quan hệ 1- nhiều) - Được sử dụng trong thiết kế phần mềm hướng đối tượng Mỗi lớp được thể hiện trong hình là một đối tượng riêng biệt 6 Sơ đồ Sequence - Góc nhìn process... đối tượng - Mô tả chuỗi sự kiện xảy ra theo trình tự thời gian Có 4 đối tượng chính trong nghiệp vụ tra cứu sách là: Để tra cứu 1 thông tin, phần mềm và người dùng sẽ phải trải qua 14 bước (gọi 14 phương thức) và mỗi đối tượng sẽ có một nhiệm vụ riêng và liên kết với nhau như hình vẽ Sau khi kiểm tra tính đúng đắn dữ liệu nội bộ của từng đối tượng(thông tin nhập vô, truy xuất… thể hiện bằng mũi tên quay... hiệu: Các chấm đen là các nút thể hiện các yêu cầu và kết quả xử lí của phần mềm Sau khi lấy hai dữ liệu từ thủ kho và nhân viên quản lí độc giả, thủ thư tra cứu thông tin phiếu mượn sách, tiếp theo phiếu mượn sách sẽ được kiểm tra về sách và độc giả(Dấu ngang và mũi tên ra hai hướng ) khi kiểm tra xong hai điều kiện sẽ được giao lại với nhau( ) rồi xét yêu cầu cho mượn sách Một lệnh rẽ nhánh dùng để kiểm... (lớp, đối tượng, quan hệ), cũng như sự tương tác giữa các đối tượng để thực hiện các chức năng mong đợi của phần mềm 3.3 Góc nhìn tiến trình (Process view): • Chia hệ thống thành các tiến trình (process) và luồng (thread), mô tả việc đồng bộ hóa và các xử lý đồng thời Dùng cho người phát triển và tích hợp hệ thống, bao gồm các biểu đồ sequence diagram, collaboration diagram, activity diagram và state... với nhau Như ở ví dụ trên thì: • Một máy chủ cơ sở dữ liệu có thể cho nhiều PC kết nối tới, Các PC không giao tiếp trực tiếp với nhau mà thông qua máy chủ CSDL Các máy in có thể dùng chung giữa các PC • Các PC kết nối tới máy chủ cơ sở dữ liệu bằng giao thức TCP/IP, kết nối với máy in bằng giao thức IPX - IV Rup: V Tài liệu tham khảo . và phần mềm, thành phần của phần mềm tương tác với nhau. Để hỗ trợ cho việc đó, người ta sử dụng một ngôn ngữ mô hình hóa đó chính là UML. Trong đề tài UML trong phân tích thiết kế phần mềm ,. ứng dụng của UML trong phân tích thiết kế phần mềm: 1. Sơ lượt về UML: - UML là ngôn ngữ chuẩn công nghiệp được dùng chủ yếu trong lĩnh vực khoa học máy tính và công nghệ phần mềm. - UML là ngôn. dụng UML làm giảm nguy cơ thất bại của dự án phần mềm. - Như vậy việc sử dụng UML trong quá trình phân tích thiết kế phần mềm là vô cùng cần thiết và có hiệu quả. 2. Các sơ đồ trong UML và