Bài giảng Phân tích thiết kế hệ thống bằng UML - Chương 4: Lược đồ Activity - Đại học Công nghiệp TP.HCM

Nội dung text: Bài giảng Phân tích thiết kế hệ thống bằng UML - Chương 4: Lược đồ Activity - Đại học Công nghiệp TP.HCM

1. CHƯƠNG 4: Lược đồ Activity PTTKHT bang UML - BM HTTT 1
2. Nôị dung  Vai trò cuả lược đồ activity  Thanh̀ phâǹ cuả lược đồ activity  Giai đoaṇ Inception  Giai đoaṇ Elaboration PTTKHT bang UML - BM HTTT 2
3. Vai trò cuả lược đồ Activity  UC mô tả chức năng cuả hệ thônǵ , chỉ ra actor sử dung̣ hệ thônǵ để làm gì.  Có nhiều tình huống (scenario) xảy ra trong cùng 1 use case.  Môĩ tinh̀ huônǵ được mô tả băng̀ cać dong̀ sự kiêṇ (flow of events) nhưng do diêñ đaṭ băng̀ text trong UC: khó xem →Có thể mô tả hinh̀ anh̉ cać dong̀ sự kiên??̣ → Dung̀ lược đồ Activity PTTKHT bang UML - BM HTTT 3
4. Cać thanh̀ phâǹ cuả lược đồ Activity  Biêủ tượng Activity  Biêủ tượng băt́ đâù (start State) và kêt́ thuć (end state)  Transition (chuyên̉ đôi)̉  Đông̀ bộ hoá (synchronization)  Điêm̉ quyêt́ đinḥ (Decision node)  Đôí tượng và dong̀ đôí tượng PTTKHT bang UML - BM HTTT 4
5. Biêủ tượng Activity  Dang̣ đơn gian̉ Activity 1  Dang̣ phức: chứa nhiêù hanh̀ đông̣ (action) bên trong PTTKHT bang UML - BM HTTT 5
6. Biêủ tượng Activity  Trong môṭ activity có thể có 1 trong 4 loaị hanh̀ đông̣ sau: ◦ Entry ◦ Exit ◦ Do ◦ Event  Cać hanh̀ đông̣ naỳ là tuỳ choṇ , nhưng cho cać thông tin chi tiêt́ giuṕ hoaǹ thanh̀ công viêc̣ thiêt́ kế PTTKHT bang UML - BM HTTT 6
7. Biêủ tượng Activity  Ngay khi băt́ đâù 1 activity, hanh̀ đông̣ naỳ được đanh́ dâú băng̀ từ khoá “entry”  Khi ra khoỉ 1 activity, hanh̀ đông̣ naỳ được đanh́ dâú băng̀ từ khoá “exit”  Trong khi thực thi môṭ activity, hanh̀ đông̣ naỳ được đanh́ dâú băng̀ từ khoá “do”  Ngay khi có 1 sự kiêṇ naò đó xaỷ ra, hanh̀ đông̣ naỳ được đanh́ băng̀ từ khoá “event” PTTKHT bang UML - BM HTTT 7
8. Biêủ tượng băt́ đâù (start State) và kêt́ thuć (end state)  Để baó nơi băt́ đâù và kêt́ thuć cuả lược đô.̀  Môĩ lược đồ actitvity phaỉ có điêm̉ băt́ đâù nhưng không băt́ buôc̣ phaỉ có điêm̉ kêt́ thuc.́  Trong 1 lược đồ activity có thể có nhiêù hơn 1 điêm̉ kêt́ thuć , nhưng chỉ có 1 điêm̉ băt́ đâù mà thôi PTTKHT bang UML - BM HTTT 8
9. Biêủ tượng băt́ đâù (start State) và kêt́ thuć (end state) Start State End State PTTKHT bang UML - BM HTTT 9
10. Đôí tượng (object) và dong̀ đôí tượng (object Flow)  Đôí tượng là môṭ thực thể bị anh̉ hưởng bởi dong̀ sự kiện. Nó có thể được dùng hay bị thay đôỉ bởi 1 activity.  Biêủ tượng đôí tượng: Ticket  Đôí tượng được nối với activity thông qua ký hiệu object flow PTTKHT bang UML - BM HTTT 10
11. Đôí tượng (object) và dong̀ đôí tượng (object Flow)  Nơi đôí tượng xuât́ hiêṇ trong lược đồ activity để chỉ nơi mà trạng thái đối tượng bị thay đôỉ và thay đôỉ như thế nao.̀ PTTKHT bang UML - BM HTTT 11
12. Đôí tượng trong lược đồ Activity  Đôí tượng Ticket bị tać đông̣ bởi 2 activity “Enter credit information” và “Reserve seat” nhưng đôí tượng naỳ cung̃ tać đông̣ ngược laị activity “Generate confirmation number” PTTKHT bang UML - BM HTTT 12
13. Transition (chuyên̉ đôỉ )  Chỉ ra dong̀ điêù khiên̉ đi từ activity naỳ sang activity khac.́  Ký hiêụ cuả transition:  Để kiểm soát được khi nào xảy ra chuyên̉ đôỉ có thể dung:̀ ◦ Sự kiêṇ (event) ◦ Điêù kiêṇ rẽ nhanh́ (guard condition) . PTTKHT bang UML - BM HTTT 13
14. Transition (chuyên̉ đôỉ )  Nêú dùng sự kiêṇ : thì sự kiêṇ buôc̣ phaỉ xaỷ ra thì chuyển đổi mới được phép xaỷ ra.  Sự kiện được đặt tên, tiêṕ theo là đôí số trong căp̣ ngoăc̣ đơn (nêú co)́ năm̀ doc̣ theo đường muĩ tên cuả transition. Event PTTKHT bang UML - BM HTTT 14
15. Transition (chuyên̉ đôỉ )  Sự kiện chỉ đóng vai trò kích khởi transition  Để kiểm soát xem transition có đươc phép xảy ra hay không thì phải dùng điều kiện.  Nếu điều kiện đúng thì transition mới xảy ra.  Ký hiệu của điều kiện [condition] nằm dọc theo đường mũi tên của transition [New reservation] Reserve seat Generate confirmation number PTTKHT bang UML - BM HTTT 15
16. Đông̀ bộ hoá (synchronization)  Là cach́ để chỉ ra hai hay nhiêù nhanh́ cuả 1 dong̀ sự kiêṇ xaỷ ra song song nhau.  Ký hiêụ : dang̣ thanh ngang, nơi phân nhanh́ hay hôị tụ cuả dong̀ sự kiên.̣ PTTKHT bang UML - BM HTTT 16
17. Đông̀ bộ hoá (synchronization)  Hệ thônǵ cung̀ luć có thể vừa đăṭ chỗ trước (reserve a seat), vừa phat́ ra số xać nhâṇ (generate confirmation number), vừa phat́ ra biên nhâṇ (receipt) và gửi email biên nhâṇ PTTKHT bang UML - BM HTTT 17
18. Điêm̉ quyêt́ đinḥ (decision node)  Là nơi có 1 hay nhiêù canḥ đêń (incoming edge) và 2 hay nhiêù canḥ ra (outgoing edge).  Các cạnh ra hay vào đều là các transition.  Ký hiêụ : dang̣ hinh̀ thoi. PTTKHT bang UML - BM HTTT 18
19. Điêm̉ quyêt́ đinḥ (decision node) PTTKHT bang UML - BM HTTT 19
20. Lược đồ activity và UC  Thường vẽ lược đồ activity cho scenario chinh́ hay những scenario phức tap̣ khać cuả UC PTTKHT bang UML - BM HTTT 20
21. Giai đoaṇ Inception  Không dùng để thực hiện công đoạn Requirements, thường dùng để xác định tính khả thi (feasibility), các rủi ro (risk) và phạm vi của hệ thống.  Sẽ kết thúc với quyết định có nên tiếp tục điều tra thêm trong giai đoaṇ elaboration không.  Không phải tất cả các hoạt động trong inception đều hợp lý, thường nó hướng theo yêu cầu (requirements-oriented). PTTKHT bang UML - BM HTTT 21
22. Cać hoaṭ đông̣ trong Inception  Hội nghị (workshop) để xác định yêu cầu hệ thống  Hầu hết các actor, goal, use case đều được đặt tên  Hầu hết các UC đã được mô tả ngắn gọn, 10 – 20% use case được viết đầy đủ  Hầu hết các yêu cầu về chất lượng đã được xác định  Lập danh sách các rủi ro (risk)  Prototype hướng giao diện người dùng (user interface- oriented) để làm rõ hơn yêu cầu chức năng  Các kiến nghị (recommendation) về việc nên mua/xây dựng/dùng lại các thành phần của hệ thống cũ.  Lập kế hoạch cho lần lặp đầu tiên PTTKHT bang UML - BM HTTT 22
23. Giai đoaṇ Elaboration  Bao gồm 1 chuỗi các lặp lại (iteration), thường từ 2 đến 4 lần lặp.  Dùng để “ Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources”. PTTKHT bang UML - BM HTTT 23
24. Công viêc̣ trong Elaboration  Thực hiện các lần lặp lại theo hướng giải quyết rủi ro có thời gian hạn định ngắn (timeboxed risk-drive iteration)  Bắt đầu lập trình sớm  Thiết kế, thực thi và test các phần cơ bản của kiến trúc  Test sớm, thường xuyên và thực tế  Viết chi tiết hầu hết các use case và yêu cầu khác thông qua nhiều cuộc họp (workshop), mỗi cuộc họp cho 1 lần lặp lại của elaboration. PTTKHT bang UML - BM HTTT 24
25. Lập kế hoạch cho các lần lặp của Elaboration  Sắp xếp các yêu cầu cần thực hiện theo ba tiêu chuẩn: ◦ Risk: độ phức tạp kỹ thuật và các yếu tố khác như: khả năng sử dụng, độ tin cậy, ◦ Coverage: tất cả các phần chính của hệ thống đều đã xác định được ở lần lặp trước dù chỉ là một thực thi “wide and shallow” ◦ Criticality dùng để chỉ đến các chức năng có giá trị nghiệp vụ cao  Yêu câù naò được xêṕ loaị cao thì sẽ được thực thi trước PTTKHT bang UML - BM HTTT 25
26. Lập kế hoạch cho các lần lặp của Elaboration  Thường xêṕ loaị cho các use case, kịch bản của use case và cả một số yêu cầu diễn tả các chức năng mức cao dù không liên quan đến use case như dịch vụ logging. PTTKHT bang UML - BM HTTT 26
27. Bang̉ xêṕ loaị trong hệ thônǵ POS Yêu cầu (use Xếp loại case hay tính Chú thích năng) Process Sale Đạt điểm số cao cho tất cả các tiêu chuẩn xêṕ loại Cao Logging Xuất hiện nhiều nơi. Khó bổ sung nếu thực thi muộn Maintain users Có ảnh hưởng đến bảo Trung bình mật Thấp PTTKHT bang UML - BM HTTT 27
28. Lần lặp 1 của hệ thống POS (Elaboration 1)  Thực thi kịch bản chính của UC “Process Sale”  Thực thi UC “Start Up” vì nó cần thiết cho sự khởi đầu  Chỉ đơn giản xét kịch bản thành công (happy) và thiết kế thực thi để hỗ trợ chúng  Không xét đến các dịch vụ bên ngoài như CSDL Product hay chương trình tính thuế,  Không xét đến các quy tắc giá cả phức tạp PTTKHT bang UML - BM HTTT 28
29. Phát triển tăng tiến cùng môṭ UC qua các lần lặp  Không phải tất cả các yêu cầu trong “Process Sale” đều được xử lý trong lần lặp 1. Thường thì một UC hay một yêu cầu nào đó quá phức tạp sẽ không thể khảo sát xong trong 1 lần lặp được, từng phần yêu cầu hay kịch bản sẽ lần lượt được xét tiếp trong các lần lặp kế tiếp.  Các lần lặp tiếp theo sẽ phát triển dựa theo lần lặp 1. PTTKHT bang UML - BM HTTT 29
30. UC qua cać lâǹ lăp̣ PTTKHT bang UML - BM HTTT 30