báo cáo công nghệ phần mềm và ứng dụng

4+1 View 4+lView Architecture Architecture in in UML UML Software architecture can be taken as having a number ofdifferent _ Table of Contents meanings dependant on which 4H“ VlOW ArChlt 6CtlirG in UML perspective taken There are not only descriptors for the physical Giới thiệubut : .3 architecture also methods and Giới thiệu sơ lược UML ỉanguages for describing the architecture ofthe physicaỉ USECASE View software at component and theoreticaì ìevels To assure that 3.1 reader USE CASE ? the canfuììy 3.2 Sự cần thiết phải có Use Case 3.3 Hướng nhìn Use case (Use case View): 10 3.4 Mô hình hóa Use Case 12 Process view 28 4.1 Biểu đồ trạng thái(state diagram): 28 4.2 Biểu đồ tuần tự(squence diagram): .31 4.3 Biểu đồ cộng tác (Collaboration diagram): 34 4.4 Biểu đồ hoạt động (Activity diagram): 35 4+lView Architecture in 3UML Giới thiêu : Ngày việc mô tả kiến trúc phần mềm quan trọng Qua Kinh nghiệm nhiều nhà thiết kế phát triển cho thấy phát triển phần mềm toán phức tạp - Những người phát triển phần mềm khó hiểu cho người dùng cần - Yêu cầu thường miêu tả văn bản, dài dòng, khó hiểu, nhiều chí mâu thuẫn - Chọn lựa phần cứng phần mềm thích hợp cho giải pháp thách thức lớn Designer Chu Trình Phát Triển Phần Mềm chuỗi hoạt động nhà phân tích (Analyst), nhà thiết kế (Designer), người phát triển (Developer) người dùng (User) để phát triển thực hệ thống thông tin Những hoạt động thực nhiều giai đọan khác 0 r L D Q J 4+lView Architecture in UML Mục tiêu giai đoạn phân tích hệ thống sản xuất mô hình tổng thể hệ thống cần xây dựng Mô hình cần phải trình bày theo hướng nhìn (View) khách hàng hay người sử dụng để họ hiểu Mô hình sử dụng để xác định yêu cầu người dùng hệ thống qua giúp đánh giá tính khả thi dự án Nhà thiết kế cần phải tạo mô hình mô tả tất khía cạnh khác sản phẩm Ngoài ra, mô hình chia thành nhiều hướng nhìn, hướng nhìn số chúng mô tả khía cạnh riêng biệt sản phẩm hay hệ thống cần xây dựng Một mô hình xây dựng nhiều giai đoạn giai đoạn, mô hình bổ sung thêm số chi tiết định Người ta nhận thấy cần thiết phải cung cấp phương pháp tiệm cận chuẩn hoá thống cho việc mô hình hoá hướng đối tượng Yêu cầu cụ đưa tập hợp chuẩn hoá ký hiệu (Notation) biểu đồ (Diagram) để nắm bắt định mặt thiết kế cách rõ ràng, rành mạch Đã có ba công trình tiên phong nhắm tới mục tiêu đó, chúng thực lãnh đạo James Rumbaugh, Grady Booch Ivar Jacobson Chính cố gắng dẫn đến kết xây dựng Ngôn Ngữ Mô Hình Hoá Thống Nhất (Unitield Modeling Language UML) CONCEPTUAL PHYSICAL Logicai View lmplementation View 4+lViewArchitecture Architectureinin6UML UML 4+lView Các biểu đồ UML Functionality Use Ca se Contiguratbn Giới thiệu View tóm tắt biểu đồ sử dụng UML Management Specihcation * UML Superstructure Specitication chia 13 kiểu biểu đồ thành Scenarios X/7 loại sau : Process Deployment View View Loại : Các biểu đồ cấu trúc : Chúng sử dụng để xác định đác Períormance điểm Scalability kiến trúc tĩnh Chúng gồm có cấu trúc lớp, đối Throughput tượng thành phần mối liên hệ yếu tố có biểu đồ cấu trúc : Package, Class, Object, Composite strucure, Component Deployment Diagrams Loại : Behavioral Diagrams : Các biểu đồ đc sử dụng để xác định đặc điểm kiến trúc động Chúng bao gồm cấu trúc hành vi Kiến trúc 4+1 View Tỏ chức hệ thống phần mềm miêu tả • Các yếu tố cấu trúc giao diện bao gồm hình thành từ hệ thống • Hành vi miêu tả cộng tác yếu tố cấu trúc • Sự kết hợp yếu tố cấu trúc yếu tố hành vi bên 4+lView Architecture in UML - Hướng nhìn thành phần (component view): khía cạnh tổ chức thành phần code - Hướng nhìn song song (concurrency view): tồn song song/ trùng hợp hệ thống, hướng đến vấn đề giao tiếp đồng hóa hệ thống - Hướng nhìn triển khai (deployment view): khía cạnh Figure 1:4+1 View Model Mỗi hướng nhìn miêu tả loạt biếu đồ, chứa đựng thông tin nêu bật khía cạnh đặc biệt hệ thống Trong thực tế phân tích thiết kế dễ xảy trùng lặp thông tin, biểu đồ thật tế thành phần nhiều hướng nhìn khác Khi nhìn hệ thống từ nhiều hướng nhìn khác nhau, thời điểm người ta tập trung vào khía cạnh hệ thống Một biểu đồ hướng - Hướng nhìn Use case (use case view) : hướng nhìn khía cạnh chức hệ thống, nhìn từ hướng tác nhân bên 00 o Hư ớng nhìn logic (logical view): chức thiết kế ^ bên hệ thống nào, qua khái niệm cấu trúc tĩnh m' ứng xử động hệ thống a; c 4+lView Architecture in UML USECASE View 3.1 USE CASE ? UML đưa khái niệm Use Case để nắm bắt yêu cầu khách hàng (người sử dụng) Qua xây dựng thành biểu đồ ca sử dụng (use case diagram) để nêu bật mối quan hệ giao tiếp với hệ thống Biều đồ hay tài liệu use case chức mà người dùng yêu cầu hệ thống xây dựng phải có mà không quan tâm chức thực Use case diagram sử dụng xuyên suốt chu trình thiết kế phần mềm, bật giai đoạn ngiên cứu sơ bộ, phân tích thử ngiệm a) Giai đoạn nghiên cứu sơ bộ: Qua phương pháp mô hình hóa Use case, tác nhân (Actor) bên quan tâm đến hệ thống mô hình hóa song song với chức mà họ đòi hỏi từ phía hệ thống (tức Use case) Các tác nhân Use case mô hình hóa mối quan hệ miêu tả biểu đồ Use case UML Mỗi Use case mô tả tài liệu, đặc tả yêu cầu khách hàng: Anh ta hay chị ta chờ đợi điều phía hệ thống mà không để ý đến việc chức thực thi b) Giai đoạn phân tích: Giai đoạn phân tích quan tâm đến trình trừu tượng hóa đầu 4+lView Architecture in 9UML c) Giai đoạn thử nghiệm: Như trình bày phần Chu Trình Phát Triển Phần Mềm, hệ thống phần mềm thường thử nghiệm qua nhiều giai đoạn với nhiều nhóm thử nghiệm khác Các nhóm sử dụng nhiều loại biểu đồ UML khác làm tảng cho công việc mình: Thử nghiệm đơn vị sử dụng biểu đồ lớp (class diagram) đặc tả lớp, thử nghiệm tích hỢp thường sử dụng biểu đồ thành phần Nhóm phát triển hệ thống cần phải xây dựng nên kịch nêu bật tương tác cần thiết người sử dụng hệ thống khả hoạt động, ví dụ kịch cho tương tác nhân viên thu ngân hệ thống phận tiết kiệm suốt tiến trình giao dịch Một kịch khác ví dụ chuỗi tương tác xảy phận tiết kiệm phận đầu tư giao dịch chuyển tiền Nhìn chung, coi Use case tập hợp loạt cảnh 3.2 Sự cần thiết phải có Use Case Use Case công cụ xuất sắc để khuyến khích người dùng tiềm nói hệ thống từ hướng nhìn họ Đối với người dùng, việc thể mô tả ý định việc sử dụng hệ s thống chuyện dễ dàng Một thực có thật người sử dụng ° thường biết nhiều mà họ diễn tả ra: công cụ Use Casein- 4+lView Architecture in UML trực quan cho phép bạn kết hợp biểu đồ Use Case với loại biểu đồ khác Sáng kiến chủ đạo lôi người dùng tham gia vào giai đoạn trình phân tích thiết kế hệ thống Việc nâng cao xác suất cho việc hệ thống chung trở thành công cụ quen thuộc người dùng mà dự định trợ giúp - thay tập hợp khó hiếu rối rắm khái niệm máy tính mà người dùng giới doanh thương có cảm giác không hiểu làm 3 Hướng nhìn Use case (Use case View): Hướng nhìn Use case miêu tả chức hệ thống phải cung cấp tác nhân từ bên mong đợi Tác nhân thực thể tương tác với hệ thống; người sử dụng hệ thống khác Hướng nhìn Use case hướng nhìn dành cho khách hàng, nhà thiết kế, nhà phát triển người thử nghiệm; miêu tả qua biểu đồ Use case (use case diagram) bao gồm biểu đồ hoạt động (activity diagram) Cách sử dụng hệ thống nhìn chung miêu tả qua loạt Use case hướng nhìn Use case, nơi Use case lời miêu tả mang tính đặc thù cho tính hệ thống (có nghĩa chức mong đợi) Hướng nhìn Use case mang tính trung tâm, đặt nội dung 4+1 View Architecture in 11UML CONCEPTUAL PHYSICAL Implementation View Logical View Functbnality Process View Pertòrmance Scalability Throughput Coníigurat bn ^0 Managem Use Case View Scenarios Deployment View CONCEPTUAL Logical View Class, Object, Package, Composite structure, Process View Sequence, Communication, Activity, Timing, Interaction Overview PHYSICAL Implementation View Use Case View Use Case, Activity Component Deployment View Deployment 0 LD Q J 4+lView Architecture in 12 UML 3.4 - Mô hình hóa Use Case Trường hợp sử dụng kỹ thuật mô hình hóa sử dụng để mô tả hệ thống phải làm hệ thống tồn làm Một mô hình Use Case xây dựng qua trình mang tính vòng lặp (interative), hội thảo bàn luận nhóm phát triển hệ thống khách hàng (hoặc/và người sử dụng cuối) dẫn tới đặc tả yêu cầu tất người chấp nhận Người cha tinh thần mô hình hóa Use Case Ivar Jacobson, ông tạo nên kỹ thuật mô hình hóa dựa kinh nghiệm thu thập trình tạo hệ thống AXE hãng Erisson Use Case nhận quan tâm đặc biệt lớn lao từ phía cộng đồng hướng đối tượng tác động lên nhiều phương pháp hướng đối tượng khác Những thành phần quan trọng mô hình Use Case Use Case, tác nhân hệ thống Ranh giới hệ thống định nghĩa qua chức tổng thể mà hệ thống thực thi Chức tổng thể thể qua loạt Use Case Use Case đặc tả chức trọn vẹn, có nghĩa Use Case phải thực thi toàn chức đó, từ 00 o 3.4.1 Mục tiêu Use Case: A - Để định mô tả yêu cầu mặt chức hệ thống, ^ kết rút từ thỏa thuận khách hàng (và/hoặc người sử* 4+lView Architecture in 37 UML Khi người gọi tác vụ PrintAIICustomer (trong lớp CustomerVVindovv), hành động khởi động, hành động hộp thông báo lên hình; hành động thứ hai tạo tập tin PostScript; hành động thứ ba gởi file PostScript đến máy in; hành động thứ tư xóa hộp thông báo hình Các hành động chuyển tiếp tự động; chúng xảy hành động giai đoạn nguồn thực Các thay đổi bảo vệ điều kiện canh giữ (Guardcondition), điều kiện phải thỏa mãn thay đổi nổ Một ký hiệu hình thoi sử dụng để thể định Ký hiệu định có nhiều thay đổi vào nhiều thay đổi dán nhãn kèm điều kiện bảo vệ Bình thường ra, số thay đổi thỏa mãn (là đúng) Một thay đổi chia thành hai hay nhiều thay đổi khác dẫn đến hành động xảy song song Các hành động thực đồng thời, chúng thực Yếu tố quan trọng tất thay đổi đồng thời phải thực trước chúng thống lại với (nếu có) Một đường thẳng nằm ngang kẻ đậm (còn gọi đồng hộ hóa - Synchronisation Bar) 4+lView Architecture in UML mở - Thanh đồng hóa (Synchronisation bar): chúng cho phép ta Thanh đồng hóa - Điều kiện canh giữ (Guard Condition): biểu thức logic có giá trị hoặc sai Điều kiện canh giữ thể ngoặc vuông, ví [Customer existing] - Điểm định (Decision Point)’ sử dụng để thay đổi khả thi Kí hiệu hình thoi Hình sau miêu tả đoạn biểu đồ hoạt động máy ATM Sau thẻ đưa vào máy, ta thấy có ba hoạt động song song: - Xác nhận thẻ - Xác nhận mã số PIN - Xác nhận số tiền yêu cầu rút Chỉ sử dụng biểu đồ hoạt động, hoạt động song song 4+lView Architecture in 39 UML Biểu đồ hoạt động máy ATM LƯỢC diagram): 4.5 đô thành phần (Component Mô tả mối liên hệ thành phàn hệ thống, thành phần hệ thống bao gồm có: > > > > Tập tin source code Thư viện liên kết (DLL) Chương trình thực thi (EXE) Cơ sở liệu M o ° ư-> QJ c 4+lView Architecture in 40 UML Component diagram mô tả hệ thống quản lý TKB 4.6 LƯỢC đồ triển khai (deployment diagram): Mô tả kiến trúc vật lý thành phần bên hệ thống tương tác giữ chúng, bao gồm kiến trúc phần cứng phần mềm hệ thống triển khai theo lược đồ sau: > Triển khai theo máy đơn Mô tả quản lý Thời Khóa Biểu Q J «< June 5, 2008 +l Vi e w Ar c hi te ct ur e in U M ■£> 4+lView Architecture in 42 UML Mô tả quản lý thời khóa biểu 0 r O) 4+lView Architecture in UML Loqỉcal vỉew Hướng nhìn logic miêu tả phương thức mà chức hệ thống cung cấp Chủ yếu sử dụng cho nhà thiết kế nhà phát triển hệ thống Ngược lại với hướng nhìn Use case, hướng nhìn logic nhìn vào phía bên hệ thống Nó miêu tả kể cấu trúc tĩnh tương tác động xảy đối tượng gửi thông điệp cho để cung cấp chức định sẵn Cấu trúc tĩnh miêu tả biểu đồ lớp (class diagram) biểu đồ Một biểu đồ lớp cấu trúc tĩnh lớp hệ thống (nhìn hình 3.3) Các lớp đại diện cho "vật" xử lý hệ thống Các lớp quan hệ với nhiều dạng thức: liên kết (associated nối kết với nhau), phụ thuộc (dependent - lớp phụ thuộc vào lớp khác), chuyên biệt hóa (specialized - lớp kết chuyên biệt hóa lớp khác), hay đóng gói ( packaged - hợp với thành đơn vị) Tất mối quan hệ thể biểu đồ lớp, kèm với cấu trúc bên lớp theo khái niệm thuộc tính (attribute) thủ 4+lView Architecture in 44 UML Hình 2.1: Biểu đồ lớp tổng quát cho môt Project 5.2 Object diagrams Một biểu đồ đối tượng phiên biểu đồ lớp thường sử dụng ký hiệu biểu đồ lớp khác biệt hai loại biểu đồ nằm chỗ biểu đồ đối tượng loạt đối tượng thực thể lớp, thay lớp Một biểu đồ đối tượng ví dụ biểu đồ lớp, tranh thực tế xảy hệ thống thực thi: tranh mà hệ thống có thời điểm Biểu đồ đối tượng sử dụng chung ký hiệu biểu đồ lớp, trừ hai ngoại lệ: đối tượng viết với tên gạch tất thực thể mối quan hệ Chúng giúp hiểu biểu đồ lớp dễ dàng mối quan hệ lớp trở nên phức tạp Biểu đồ đối tượng không quan trọng biểu đồ lớp, chúng \ / Sales 5.4 4+lView Architecture in UML Marketỉng Composite structure Diagrams Hình 2.2: Biểu đồ lớp trường ĐHBKHN Biểu đồ cấu trúc bên class, bao gồm tương tác 5.3phần Package diagrams hệ thống Nó thể hình dáng mối quan hệ Package Diagrams đơn giản loại biểu đồ bao gồm "gói", Khi biểu đồ có gói thường không định rõ loại biểu đồ cả, mang thành phần đặc trưng Biểu đồ thường dùng để gom nhóm phần tử mô hình hướng đối tượng Như gom nhóm classes in Class Diagrams, gom nhóm components processes Component Diagrams, gom 4+lView Architecture in 47 UML 5.5 State machine diagrams Một biểu đồ trạng thái thường bổ sung cho lời miêu tả lớp Nó tất trạng thái mà đối tượng lớp có, kiện (event) gây thay đổi trạng thái (hình 3.5) Một kiện xảy đối tượng tự gửi thông điệp đến cho - ví dụ để thông báo khoảng thời gian xác định qua - số điều kiện thỏa mãn Một thay đổi trạng thái gọi “ chuyển đổi trạng thái (State Transition) Một chuyển đổi trạng thái o 4+lView Architecture in 49 UML 48 donvitinh Biểu đồ trạng thái không vẽ cho tất lớp, mà riêng cho lớp có số lượng trạng thái định nghĩa rõ ràng hành vi loaithuoc lớp bị ảnh hưởng thay đổi qua trạng thái khác Biểu đồ donvitỉnhlD nuocID loaithuocID nuocSX Có Thuộc thuocl I) * thuoc -S| Z" Gồm Gồm donnhapll) 2k donnhap donthuoc (^ngay nhâp^) Thuộc Hình 2.3: Biểu đồ máy trạng thái tính search cho trang có đăng nhập dỡituong % nhacungcap 5.6 Mô hình hóa với góc nhìn Logic benhnharì s Khi mô hình hóa với góc nhìn Logic, bắt đầu biểu đồ Class Package nhaeungcaplD c doiiuonglD bcnhnhanỉD mở rộng cần thiết UML mô hình hóa liệu dùng biếu đồs quan hệ thực thể (Entity Relationship Diagram) ER Diagram đượcrsl coi ưì' dạng khác Logic view Một kiến quản trúc phần mềm khác phân ER Entity Relationship Diagram Hệsố thống lý dược phẩm [...]... UML sẽ được sử dụng ra sao Các Use Case vì vậy phải được mô tả trong những thuật ngữ và ngôn ngữ của khách hàng/người sử dụng Nhà phát triển cần đến các mô hình Use Case để hiểu hệ thống cần phải làm gì, và qua đó có được một nền tảng cho những công việc tương lai (các mô hình khác, các cấu trúc thiết kế và việc thực thi xây dựng hệ thống bằng code) Các nhóm chuyên gia thử nghiệm tích hợp và thử nghiệm... thành một Use Case riêng biệt và nó có thể được sử dụng bởi các Use Case kia, một mối quan hệ như vậy được gọi là quan hệ sử dụng Trong quan hệ sử dụng, phải sử dụng toàn bộ Use Case khái quát hóa, nói một cách khác, ta có một Use Case này sử dụng toàn bộ một Use Case khác Các hành động trong Use Case khái quát hóa không cần phải 4+lView Architecture in UML Quan hệ sử dụng giữa các Use Case được biểu... giản và nhất quán về việc các tác nhân và các Use Case (hệ thống) tương tác với nhau ra sao Nó tập trung vào ứng xử đối ngoại của hệ thống và không đề cập tới việc thực hiện nội bộ bên trong hệ thống Ngôn ngữ và các thuật ngữ được sử dụng trong lời miêu tả chính là ngôn ngữ và các thuật ngữ được sử dụng bởi khách hàng/người dùng Văn bản miêu tả cần phải bao gồm những điểm sau: - Mục đích của Use Case:... lọc ra các thực thể đáng quan tâm theo khía cạnh sử dụng và tương tác với hệ thống Sau đó chúng ta có thể thử đặt mình vào vị trí của tác nhân để cố gắng nhận ra các yêu cầu và đòi hỏi của tác nhân đối với hệ thống và xác định tác nhân cần những Use Case nào có thể nhận diện ra các tác nhân qua việc trả lời một số các câu hỏi như sau: - Ai sẽ sử dụng những chức năng chính của hệ thống (tác nhân chính)?... tính và thao tác với máy tính Để có thể nhận dạng được tốt nhiều tác nhân khác nhau, hãy tiến hành nghiên cứu những người sử dụng của hệ thống hiện thời (một hệ thống thủ công hoặc một hệ thống đang tồn tại), hỏi xem họ đóng những vai trò nào khi thực thi công việc hàng ngày của họ với hệ thống Cũng người sử dụng đó có thể thực thi nhiều vai trò khác nhau tại nhiều thời điểm khác nhau, tùy thuộc vào... lại lối ứng xử kho : Muốn thông tin giao dịch chính xác, và đầy đủ hoạt động của hệ thống Nhưng xin nhớ rằng, một lời phương thức miêu tả Brief Description: cảnh kịch chỉ là một sự bổ sung chứ không phải là ứng cử viên để Nhân thay viên giữ kho nhập thông tin linh kiện nhập về trong ngày vào thế kho cho lời miêu tả Use Case Trigger Sau khi các Use Case đã được miêu tả, một hoạt động và một Nhân côngviên... biệt khác giữa biểu đồ hoạt động và biểu đồ trạng thái là 4+lView Architecture in 36 UML - Để nắm bắt công việc (hành động) sẽ phải được thực thi khi một thủ tục được thực hiện Đây là tác dụng thường gặp nhất và quan trọng nhất của biểu đồ hoạt động - Để nắm bắt công việc nội bộ trong một đối tượng - Để chỉ ra một nhóm hành động liên quan có thể được thực thi ra sao, và chúng sẽ ảnh hưởng đến những... xa lạ đối với những người không quen sử dụng 3.4.3 - Hệ thống Vì hệ thống là một thành phần của mô hình Use Case nên ranh giới của hệ thống mà ta muốn phát triển cần phải được định nghĩa rõ ràng Xin nhớ rằng một hệ thống không phải bao giờ cũng nhất thiết là một hệ thống phần mềm; nó có thế là một chiếc máy, hoặc là một doanh nghiệp Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải bao... Use Case Có ba loại quan hệ Use Case: Quan hệ mở rộng, quan hệ sử dụng và quan hệ tạo nhóm Quan hệ mở rộng và quan hệ sử dụng là hai dạng khác nhau của tính thừa kế Quan hệ tạo nhóm là một phương cách để đặt 3.4.6.1 - Quan hệ mở rộng Nhiều khi trong quá trình phát triển Use Case, người ta thấy một số Use Case đã tồn tại cung cấp một phần những chức năng cần thiết cho một Use Case mới Trong một trường... hệ thống này và tác vụ nào thì tốt 4+lView Architecture in UML chức năng căn bản và tập trung vào việc định nghĩa một kiến trúc hệ thống thích hợp, rõ ràng, có nền tảng rộng mở để nhiều chức năng hơn có thể được bổ sung vào hệ thống này trong các phiên bản sau Yếu tố quan trọng là bạn phải tạo dựng được một bản catalog của các khái niệm (các thực thế) trung tâm cùng với các thuật ngữ và định nghĩa ... trình bày phần Chu Trình Phát Triển Phần Mềm, hệ thống phần mềm thường thử nghiệm qua nhiều giai đoạn với nhiều nhóm thử nghiệm khác Các nhóm sử dụng nhiều loại biểu đồ UML khác làm tảng cho công. .. dài dòng, khó hiểu, nhiều chí mâu thuẫn - Chọn lựa phần cứng phần mềm thích hợp cho giải pháp thách thức lớn Designer Chu Trình Phát Triển Phần Mềm chuỗi hoạt động nhà phân tích (Analyst), nhà... Ngày việc mô tả kiến trúc phần mềm quan trọng Qua Kinh nghiệm nhiều nhà thiết kế phát triển cho thấy phát triển phần mềm toán phức tạp - Những người phát triển phần mềm khó hiểu cho người dùng