Bài giảng Phân tích và Thiết kế hệ thống - Chương 2: Mô hình hóa yêu cầu của bài toán sử dụng use case diagram - Từ Thị Xuân Hiền

Chương 2Mô hình hóa yêu cầu của bài toánsử dụng use case diagramYêu cầu của hệ thốngNhững chức năng mà hệ thống phải thực hiện.Những đặc tính mong muốn của người dùng đối với hệ thống.Những phát biểu về những đề xuất đối với hệ thống mà tất cả các bên tham gia đống ý về các vấn đề của khách hàng phải được giải quyết thỏa đáng.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền2Tiến trình phân tích yêu cầu bài toánTìm hiểu, khám phá và phân tích các yêu cầu của của người dùng đối với hệ thống.Xây dựng các tài liệu yêu cầu Kiểm tra tính hợp lệ của các yêu cầu Quản lý các yêu cầu Mô hình hóa yêu cầuBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền3Mục tiêu của phân tích yêu cầuYêu cầu thường không được nêu một cách rõ ràng, don đó người phát triển hệ thống cần phải làm việc với khách hàng và các bên liên quan để khai thác:Các dịch vụ mà hệ thống cần cung cấpNhững ràng buộc mà hệ thống phải đáp ứngBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền4Mục tiêu của phân tích yêu cầuMục tiêu: Đảm bảo các yêu cầu đối với sản phẩm phần mềm được định nghĩa và hiểu một cách rõ ràng.Thiết lập và duy trì các thỏa thuận về yêu cầu với các bên liên quanĐảm bảo tất cả các yêu cầu được đáp ứng.Tài liệu phân tích yêu cầu dùng để kiểm soát và là cơ sở cho việc phát triển phần mềm và sử dụng trong quản lý dự án.Phát hiện và giải quyết mâu thuẫn giữa yêu cầuXác định phạm vi của phần mềm và cách nó tương tác với môi trường Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền5Các loại tài liệu trong phân tích yêu cầuXác định yêu cầu người dùng (URD – User requirement definition)Xác định những gì người dùng cần cho công việc của họBao gồm yêu cầu doanh doanh nghiệp, quy tắc nghiệp vụ và các ràng buộc khácBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền6Các loại tài liệu trong phân tích yêu cầuĐặc tả yêu cầu phần mềm (SRS – Software requirement specification)Một tập hợp các yêu cầu phần mềm: đầy đủ, nhất quán và chính xác từ quan điểm của nhà phát triểnTài liệu đặc tả yêu cầu dùng làm cơ sở tham chiếu chung của các yêu cầu phần mềm cho khách hàng, nhà phát triển, thử nghiệm và quản lý dự án.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền7Các loại yêu cầuChức năng - FunctionalGiao diện - InterfaceDữ liệu - DataNguồn nhân lực - Human engineeringChất lượng - QualificationNghiệp vụ - Operational Ràng buộc về thiết kế - Design constraintsAn toàn - SafetyBảo mật - Security, etc.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền8Yêu cầu chức năng - Functional requirementsMô tả sự tương tác giữa hệ thống và môi trường của nóMô tả cách ứng xử của hệ thống với hành vi kích hoạt của người dùngCó thể sử dụng mô hình - một sự kết hợp của các ký hiệu đồ họa và cấu trúc ngôn ngữ tự nhiênSử dụng use case diagram, activity, state diagramPrototype, ...Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền9Yêu cầu phi chức năng - NonFunctional requirementsMô tả các hạn chế trên một hệ thống làm hạn chế sự lựa chọn và từ đó đưa ra một giải pháp cho một vấn đề xác địnhCác yêu cầu phi chức năng không được mô hình hóa => được chỉ định chỉ sử dụng ngôn ngữ tự nhiên có cấu trúcBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền10Tính hợp lệ của các yêu cầuĐánh giá các yêu cầu - Requirements ReviewPhân tích thủ công có hệ thống các yêu cầu Tham gia của nhà phát triển, khách hang, các bên tham giaPrototypingSử dụng mô hình thực thi của hệ thống để kiểm tra yêu cầuModel ValidationKiểm tra chất lượng của các mô hình phát được xây dựng trong thời gian phân tíchTest-case generationPhát triển thử nghiệm đối với các yêu cầu để kiểm tra khả năng kiểm thửBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền11Quản lý các yêu cầu thay đổiYêu cầu thay đổi (CR – Change request)Các yêu cầu từ quan điểm khác nhau thay đổi trong quá trình phát triểnKhách hàng có thể xác định các yêu cầu từ góc độ kinh doanh mâu thuẫn với yêu cầu của người dùng cuốiMôi trường kinh doanh và kỹ thuật của hệ thống thay đổi trong quá trình phát triển hệ thốngTiến trình yêu cầu thay đổiBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền12Thuật ngữ - GlossaryKhái niệm:Một tập hợp các thuật ngữ được định nghĩa làm cơ sở cho giao tiếp.Một từ điển để thực hiện mô hình hóaMục đích:Làm rõ ý nghĩa của từ ngữ hoặc có những hiểu biết chung về các điều khoản giữa các thành viên trong nhómĐược tạo ra trong quá trình xác định yêu cầu, xác định use case và mô hình hóa khái niệmĐược duy trì trong suốt quá trình phát triển hệ thốngBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền13Thuật ngữ - GlossaryVí dụ Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền14Nội dung trong tài liệu xác định yêu cầu hệ thống1. Mục đích2. Phạm vi3. Tổng quan hệ thống4. Tài liệu tham khảo5. Xác định các điều khoản, các thuật ngữ chuyên môn6. Yêu cầu chức năng7. yêu cầu phi chức năngBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền15Bài tậpViết một đặc tả yêu cầu cho một hệ thống bán hàng trong siêu thị.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền16Mô hình hóa yêu cầu hệ thốngsử dụng mô hình use caseBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền17Use case diagramMô tả trực quan các chức năng được cung cấp bởi hệ thống. Một Use Case thể hiện một hành động tương tác riêng biệt giữa người dùng (human or machine) và hệ thống.Use case diagram chứa các thành phần: Use cases Actors RelationshipsBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền18Use case diagramUse caseMột use case đại diện cho một chức năng hoàn chỉnh, bao gồm một chuỗi các hoạt động khác nhau mà hệ thống có thể thực hiện bằng cách tương tác với các actor bên ngoài hệ thống.Các yếu tố của một use caseKịch bản (scenarios): là một tập các ràng buộc theo mục tiêu người dùng, thường là một chuỗi các giao dịch được thực hiện bởi một hệ thống, có thể nhìn thấy được, đo lường được kết quả.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền19Use case diagramUse CasesMô tả hoặc nắm bắt yêu các cầu chức năng của hệ thốngMột use case đại diện cho một chuỗi các hành vi tương tác của hệ thống và các actor bên ngoài.Ký hiệu use case trong UMLCó dạng hình ovalTên của use caseSử dụng động từBiểu diễn hành vi tương tác của Actor và hệ thốngBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền20LoginUse case diagramActor:Là một thực thể tương tác với hệ thống, actor có thể là người dùng, hoặc các ứng dụng bên trong, hoặc một hệ thống bên ngoài của hệ thống đang xây dựngLoại Actor:Primary Actor: Actor trực tiếp kích hoạt giao tiếp giữa actor và hệ thống. Thông thường là người sử dụng.Secondary actor: Actor chỉ thực hiện giao tiếp khi được yêu cầu từ hệ thống tại thời điểm thực thi của một use case nào đóBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền21Use case diagramKý hiệu Actor trong UMLTên actor là một danh từPrimary ActorSecondary actorBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền22>Tên ActorVí dụ Ví dụ >Bank ISKhách hàngCác mối quan hệ trong use case diagramQuan hệ giữa Actors và use cases: AssociationActor tham gia tương tác với hệ thống được mô tả bởi use case. Nếu quan hệ association có hướng: Xác định hướng tương tác của actor chính.Xác định luồng điều khiển (not data flow)Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền23LoginSinhvienCác mối quan hệ trong use case diagramQuan hệ giữa Actor và Actor:Được sử dụng để xác định vai trò trùng lắp của các Actor Ví dụ: Người Administrator và Client thực hiện được tất cả các thao tác của UserAdministrator có những thao tác riêng mà User và Client không thực hiện đượcBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền24Các mối quan hệ trong use case diagramQuan hệ giữa Use case với use caseIncludeExtendGeneralization/SpecificationBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền25Các mối quan hệ trong use case diagramInclude: hành vi của included use case là thành phần của base use case Hành vi của base use case không hoàn thành nếu không có included use case.Use case included là bắt buộc (mandatory)Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền26Các mối quan hệ trong use case diagramVí dụ: để thực hiện hành vi Xem điểm thì bắt buộc phải thực hiện hành vi Đăng nhậpBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền27Base Use caseIncluded Use caseSinhvienCác mối quan hệ trong use case diagramExtend: extending use case phụ thuộc vào base use case. Extending Use case thường là tùy chọn và kèm theo điều kiện thực hiện.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền28Các mối quan hệ trong use case diagramVí dụ: sau khi Đăng ký học phần thì sinh viên có thể Xem lịch học (hành vi Xem lịch học là tùy chọn)Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền29SinhvienCác mối quan hệ trong use case diagramGeneralization: được sử dụng khi có hai hoặc nhiều use case có cùng hành vi, cấu trúc và mục đích. Specialized use cases có cùng hành vi, yêu cầu, ràng buộc Những thành phần chung nhất được mô tả 1 lần trong general use caseNhững thành phần khác nhau được mô tả trong specialized use caseKý hiệu trong UMLBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền30Các mối quan hệ trong use case diagramVí dụ: cùng là hành vi Thanh toán, khách hàng có thể thực hiện theo nhiều cách khác nhauBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền31KhachhangThanh toánThanh toán bằng thẻ VISAThanh toán bằng dịch vụ PaypalThanh toán bằng thẻ ATMCách xác định actorĐể xác định đầy đủ actor của hệ thống. Có thể dựa vào các câu hỏi sau:Ai sử dụng hệ thống?Ai cài đặt hệ thống?Ai khởi động hệ thống?Ai duy trì hệ thống?Ai tắt hệ thống?Những hệ thống nào khác sử dụng hệ thống này?Ai được thông tin từ hệ thống này?Ai cung cấp thông tin cho hệ thống?Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền32Cách xác định use caseDựa trên kịch bản của những hoạt động bên ngoài có thể nhìn thấy, đo lường được kết quả của giá trị mà các actor mong muốn. Từ mô tả yêu cầu chức năng của hệ thống.Tìm các động từ mô tả hành vi tương tác của hệ thống và actor trong phần mô tả hệ thống.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền33Cách xác định use caseCó thể dùng các câu hỏi sau đây Những chức năng gì mà các actor mong muốn từ hệ thống?Hệ thống lưu trữ những thông tin gì? Các actor thực hiện những thao tác gì trên những thông tin này?Hệ thống có cần hiển thị thông báo cho actor về những thay đổi trạng thái bên trong hệ thống không?Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền34Câu hỏiXác định Primary actors và Secondary actors của hệ thống ATMKhách hàngChủ thẻ VISANhân viên ngân hàngHệ thống thông tin ngân hàng (Bank IS)Hệ thống chứng thực thẻ VISA (VISA AS)Xác định các use case của hệ thống ATMVẽ sơ đồ use case của hệ thống ATMHệ thống ATMĐặc tả Use-CaseMột use case đại diện cho một hành vi tương tác hoàn chỉnh, nó bao gồm một chuỗi tuần tự các hoạt động giao tiếp giữa actor và hệ thốngĐặc tả use case nhằm mô tả chi tiết chuỗi các hoạt động để thực hiện hành vi của use case từ lúc bắt đầu đến kết thúc bao gồm các lỗi trong quá trình thực hiệnBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền36Đặc tả Use-CaseMỗi use case gắn liền với các kịch bản bao gồm các một chuỗi tuần tự các sự kiện:Basic flow: một luồng sự kiện thành công chính.Alternative flows: Có nhiều luồng sự kiện thanh thếExceptional flows: Ngoại lệ cho những trường hợp lỗiBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền37Mẫu nội dung đặc tả Use-CaseBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền38UCIDMã UC (Duy nhất trong hệ thống, ví dụ: UC1)NameTên use case (cụm danh động từ ngắn gọn)SummaryMô tả vắn tắt hoạt động của use casePreconditionsĐiều kiện tiên quyết để thực hiện use casePostconditionsĐiều gì sẽ là đúng sau khi use case thực thi thành côngPrimary Actor(s)Actor chính thực hiện use caseSecondary Actor(s)Actor phụ tương tác với hệ thống tại thời điểm use case thực thiTriggerCác hành động kích hoạt use caseMain ScenarioStepActionStep #Đây là "kịch bản thành công chính" Mô tả các bước trong use case thực hiện thành côngExtensionsStepHoạt động rẽ nhánhStep #Hoạt động thay thế khi hoạt động trong kích bản chính lỗiOpen IssuesIssue #Các vấn đề liên quan đến use case cần phải giải quyếtBài tậpHãy viết đăc tả các use case trong hệ thống ATMKiểm tra tài khoản Rút tiềnMô hình hóa luồng sự kiện với activityBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền40Sơ đồ activityMột sơ đồ hoạt động (activity) dùng để mô hình hóa một cách trực quan các bước thực hiện của một use case. Các hoạt động trong mô hình có thể được thực hiện tuần tự hoặc đồng thời. Một sơ đồ hoạt động luôn có một điểm khởi đầu và các điểm kết thúc.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền41Các ký hiệu trong sơ đồ ActivityĐiểm bắt đầu (Initial State): Biểu diễn điểm khởi đầu cho sơ đồ hoạt động. Đối với sơ đồ hoạt động sử dụng swimlanes, phải đảm bảo các điểm bắt đầu được đặt ở góc trên cùng bên trái của cột đầu tiên.Ký hiệu trong UMLCác ký hiệu trong sơ đồ ActivityHoạt động (Activity)Hoạt động là một hành vi đại diện điều phối dòng chảy của hành động.Hoạt động (activity) chứa các nút có thể là:Hoạt động (action)Đối tượng (object)Điều khiển (Control)Hành động tại các nút có thể là:Chức năng số học.Lời gọi của hành vi.Truyền thông, như gửi các tín hiệu.Thao tác của các đối tượngBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền43ActivityKý hiệu trong UMLCác ký hiệu trong sơ đồ ActivityLuồng hoạt động Minh họa quá trình chuyển đổi từ một trạng thái hoạt động này sang trạng thái hoạt động khác.Ký hiệu trong UMLVí dụ:Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền44Các ký hiệu trong sơ đồ ActivityNút quyết định Khi một hoạt động đòi hỏi phải có một quyết định trước khi chuyển sang các hoạt động tiếp theoMột nút quyết định có một đầu vào nhiều đầu ra, Các nhánh phải được dán nhãn với một biểu thức điều kiện.Ký hiệu trong UMLBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền45conditionconditionElseCác ký hiệu trong sơ đồ ActivityNút MergeSự kết hợp của các luồng sự kiện. Các đầu vào không đồng bộ.Nhiều đầu vào và chỉ có một đầu raKý hiệu trong UMLBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền46Các ký hiệu trong sơ đồ ActivityĐồng bộ hóa (Synchronization)Nút fork được sử dụng để chia một luồng đến đơn thành nhiều luồng đồng thời.Ký hiệu trong UMLNút Join nối nhiều dòng đồng thời trở thành một luồng đi duy nhất.Ký hiệu trong UMLBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền47Các ký hiệu trong sơ đồ ActivityFork và Join được sử dụng cùng nhau gọi là đồng bộ hóa.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền48ActivityActivityActivityActivityForkJoinCác ký hiệu trong sơ đồ ActivityNút kết thúc (Final State hoặc End Point)Nút kết thúc hoạt động cho thấy một hoạt động được hoàn tất.Một sơ đồ hoạt động có thể có nhiều hơn một nút kết thúcKý hiệu trong UMLBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền49Các dạng ActivityActivity Partition (swimlane)Đại diện cho một số thuộc tính như vị trí mà tại đó một hành vi được thực hiện.Activity hiển thị bằng ký hiệu swimlane với các dòng thường song song, hoặc ngang hoặc thẳng đứng. Bất kỳ các nút hoạt động đặt giữa những dòng này được coi là chứa trong phân vùng đó.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền50Các dạng ActivitySub ActivityBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền51Bài tậpSử dụng sơ đồ Activity mô hình hóa các hoạt động của use case rút tiền trong hệ thống ATM.Sử dụng sơ đồ Activity mô hình hóa hoạt động của use case xem điểm trong hệ thống Quản lý điểm của sinh viênBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền52Mô hình hóa hoạt động của use case với Sequence diagramBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền53Sơ đồ tuần tự - Sequence diagramSơ đồ tuần tự được sử dụng trong cả giai đoạn phân tích và thiết kế. Trong giai đoạn phân tích yêu cầu của bài toán, sơ đồ tuần tự được sử dụng để mô tả luồng sự kiện theo thời gian cấu trúc các hoạt động thực hiện một use case.Sơ đồ tuần tự biểu diễn chi tiết quan hệ giao tiếp giữa các đối tượng trong quá trình thực hiện use caseBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền54Sơ đồ tuần tự - Sequence diagramSơ đồ hoạt động và tuần tự trong phân tích yêu cầu bài toánSơ đồ hoạt động mô tả một chuỗi các hoạt động theo cấu trúc điều kiện, vòng lặp hoặc đồng thời để thực thi một use case.Sơ đồ trình tự mô tả chuỗi các thông điệp giao tiếp giữa các đối tượng theo thời gian và cấu trúc logic.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền55Các thành phần trong sơ đồ tuần tựLifeline là một yếu tố được đặt tên đại diện cho một cá nhân tham gia trong sự tương tác. Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền56Các thành phần trong sơ đồ tuần tựĐối tượng tham gia (Participant): đối tượng thực hiện hành động trong sơ đồ trình tự.Ký hiệu trong UMLBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền57Oject:Class:ClassCác thành phần trong sơ đồ tuần tựLifeline: biểu diễn thời gian sống của đối tượng trong sơ đồ tuần tự, Kích hoạt (Activation): biểu diễn thời gian một đối tượng đang ở trạng thái hoạt động.Kết thúc đối tượng (Destroying): đối tượng kết thúc sau khi hoàn tất hoạt động.Ký hiệu trong UMLBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền58Oject:Class:ClassActivationDestroyinglifelineCác thành phần trong sơ đồ tuần tựThông điệp (Messages): biểu diễn giao tiếp giữa các đối tượng. Thông điệp không đồng bộ: được gửi từ một đối tượng sẽ không chờ thông điệp trả về từ đối tượng nhận trước khi tiếp tục.Ký hiệu trong UML:Ví dụ: Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền59Các thành phần trong sơ đồ tuần tựThông điệp đồng bộ: đối tượng gửi thông điệp chờ đến khi thông điệp được xử lý trước khi tiếp tục.Ký hiệu trong UML:Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền60Các thành phần trong sơ đồ tuần tựReturn MessageThông điệp trả về kết quả cho đối tượng gửi.Ký hiệu trong UMLBài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền61returnCác thành phần trong sơ đồ tuần tựSelf MessageMột một cuộc gọi đệ quy của một hoạt động, hoặc một phương thức gọi một phương thức khác trên cùng một đối tượng. Ký hiệu:Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền62Các thành phần trong sơ đồ tuần tựThời gian sống của một đối tượngMột đối tượng bắt đầu bằng lệnh create và kết thúc bằng DeleteCreation: biểu diễn bằng mũi tên với nhãn 'new‘ Một đối tượng được tạo sau khi bắt đầu kịch bản sẽ xuất hiện thấp hơn những đối tượng khác. Deletion: ký hiệu X tại cuối của lifeline Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền63Hoạt động tương tác trong sơ đồ tuần tựFrame: một hộp biểu diễn một phần của sơ đồ tuần tự để thể hiện sự lựa chọn hoặc lặphộp xung quanh một phần của biểu đồ trình tự để biết sự lựa chọn hoặc loopif -> (opt) [condition]if/else -> (alt) [condition], separated by horizon. Dashed lineloop -> (loop) [condition or items to loop over]Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền64Hoạt động tương tác trong sơ đồ tuần tựAlt Biểu diễn cho một sự lựa chọn hoặc thay thế của hành vi.Ví dụ: Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền65Hoạt động tương tác trong sơ đồ tuần tựOptionĐại diện cho một sự lựa chọn của hành vi mà một trong hai (duy nhất) toán hạng sẽ xảy ra hoặc không có gì xảy ra. Ví dụ:Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền66Hoạt động tương tác trong sơ đồ tuần tựLoopVòng lặp sẽ được thực hiện chính xác số lần quy định.Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền67Hoạt động tương tác trong sơ đồ tuần tựVí dụ: sơ đồ tuần tự tính tiền hóa đơn (Order) Bài giảng Phân tích thiết kế hệ thống - GV: Từ Thị Xuân Hiền68