Bài giảng Phân tích thiết kế hệ thống bằng UML - Chương 5: Mô hình hóa nghiệp vụ & lược đồ lớp ý niệm ( Modeling domain model and conceptual class) - Đạ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 5: Mô hình hóa nghiệp vụ & lược đồ lớp ý niệm ( Modeling domain model and conceptual class) - Đại học Công nghiệp TP.HCM

1. CHƯƠNG 5: Mô hinh̀ hoá nghiêp̣ vụ & lược đồ lớp ý niêṃ ( Modeling domain model and conceptual class) PTTKHT bang UML - BM HTTT 1
2. Nôị dung  Mô hinh̀ nghiêp̣ vụ (domain model)  Lớp ý niêṃ (conceptual class hay analysis class)  Môí kêt́ hợp giữa cać lớp  Phân loaị lớp PTTKHT bang UML - BM HTTT 2
3. Phân tích hệ thống  Mô hinh̀ use case diêñ tả cać yêu câù hệ thônǵ (what)  Lớp và đôí tượng mô tả cać phâǹ tử trong hệ thônǵ , coǹ môí quan hệ giữa chunǵ chỉ ra sự giao tiêṕ và tương tać (how). PTTKHT bang UML - BM HTTT 3
4. Mô hinh̀ nghiệp vụ (domain model)  Bước đâù tiên của OOA là phân chia miêǹ nghiêp̣ vụ cuả hệ thônǵ thanh̀ cać lớp hay đôí tượng ý niêṃ (conceptual object)  Mô hinh̀ nghiệp vụ (domain model) mô tả hinh̀ anh̉ cać lớp ý niêṃ hay cać đôí tượng cuả thế giới thâṭ trong phaṃ vi khaỏ sat.́  Mô hinh̀ nghiêp̣ vụ có thể được xem như từ điên̉ hinh̀ anh̉ (visual dictionary) cuả khaí niêṃ trừu tượng, từ vựng và thông tin cuả miêǹ nghiêp̣ vụ PTTKHT bang UML - BM HTTT 4
5. Mô hinh̀ nghiệp vụ (domain model)  Mô hinh̀ nghiệp vụ (domain model) coǹ được goị la:̀ ◦ Mô hình ý niệm (conceptual model) hay ◦ Mô hinh̀ đôí tượng phân tich (analysis objects model).  Cać lớp ý niêṃ (conceptual class) hay coǹ được goị là lớp phân tich́ (analysis class) và không phaỉ là cać lớp phâǹ mêm̀ (software component) PTTKHT bang UML - BM HTTT 5
6. Mô hinh̀ nghiệp vụ (domain model)  Mô hinh̀ nghiệp vụ chứa môṭ tâp̣ hợp cać lược đồ lớp ý niêm.̣  Lược đồ lớp ý niêṃ bao gôm̀ : ◦ Lớp ý niêṃ ◦ Môí kêt́ hợp (association) giữa cać lớp ◦ Thuôc̣ tinh́ (attribute) cuả lớp PTTKHT bang UML - BM HTTT 6
7. Lớp ý niêṃ (conceptual class)  Lớp ý niêṃ là môṭ ý tưởng, sự viêc̣ hay đôí tượng. Ví dụ như liên quan đêń linh̃ vực bań hang̀ cuả thế giới thực có có cać lớp ý niêṃ sau Store, Register và Sale.  Dựa vaò mô tả UC để phat́ hiêṇ ra cać lớp ý niêṃ PTTKHT bang UML - BM HTTT 7
8. Ba kỹ thuâṭ xać đinḥ lớp ý niêṃ 1. Taọ lớp ý niêṃ theo loaị ( conceptual class category list) 2. Tim̀ theo cać cuṃ danh từ 3. Sử dung̣ mâũ phân tich́ (analysis pattern) được taọ bởi cać chuyên gia PTTKHT bang UML - BM HTTT 8
9. Taọ lớp ý niêṃ theo loaị  Taọ môṭ danh sach́ cać lớp ý niêṃ theo loaị (category) như trong bang̉ sau.  Để minh hoạ , trong côṭ ví dụ liêṭ kê cać lớp ý niêṃ có thể có cuả hệ thônǵ đăṭ chỗ maý bay. PTTKHT bang UML - BM HTTT 9
10. Taọ lớp ý niêṃ theo loaị Lớp ý niệm Ví dụ Đối tượng vật lý hay có thể nhìn thấy được Máy bay Đặc tả hay mô tả sự việc, Mô tả chuyến bay Nơi chốn Sân bay Giao dịch Đặc chỗ trước Vai trò của con người Phi công Nơi chứa các sự vật khác Máy bay Sự vật đuợc chứa trong vật khác Hành khách Hệ thống bên ngoài Hệ thống kiểm soát không phận Khái niệm trừu tượng Chứng sợ độ cao Tổ chức Phòng vé Sự kiện Hạ cánh, cất cánh Quy tắc, chính sách Chính sach hủy vé Sổ tay, sách, tài liệu tham khảo Sổ tay bảo dưỡng máy bay, PTTKHT bang UML - BM HTTT 10
11. Tim̀ theo cać cuṃ danh từ  Xać đinḥ lớp ý niêṃ băng̀ cach́ phân tich́ ngữ nghiã : nhâṇ biêt́ cać danh từ hay cuṃ danh từ trong phâǹ mô tả cać scenario cuả UC.  Danh từ có thể là ứng viên tôt́ cuả lớp ý niêṃ hay thuôc̣ tinh́ cuả lớp.  Nên cân̉ thâṇ khi aṕ dung̣ phương phaṕ naỳ , không nên maý moć biêń tât́ cả danh từ thanh̀ lớp vì cać từ tự nhiên thường có nghiã rât́ mơ hô.̀ PTTKHT bang UML - BM HTTT 11
12. Ví du:̣ xać đinḥ lớp từ cuṃ danh từ Main Success Scenario (or Basic Flow): 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 2-3 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. 8. System logs the completed sale and sends sale and payment information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory). 9. System presents receipt. 10.Customer leaves with receipt and goods (if any).PTTKHT bang UML - BM HTTT 12
13. Case study 1: Hệ thônǵ POS  Cać lớp ý niêṃ theo hai kỹ thuâṭ trên: Register Item Store Sale Payment ProductCatalog ProductSpecification SalesLineItem Cashier Customer Manager PTTKHT bang UML - BM HTTT 13
14. Case study 1: Hệ thônǵ POS  Mô hình nghiệp vụ sơ lược lúc đầu của hệ thống POS như sau: PTTKHT bang UML - BM HTTT 14
15. Môṭ số lưu ý khi taọ lớp ý niêṃ  Có nên taọ lớp ý niêṃ Receipt (biên nhân)̣ hay không? ◦ Receipt là môṭ dang̣ baó caó →có thể được suy diêñ từ cać nguôǹ khać , do đó không câǹ đưa Receipt vaò mô hinh̀ ý niêṃ ◦ Receipt có vai trò đăc̣ biêṭ trong quy tăć nghiêp̣ vụ vì nó là băng̀ chứng cho pheṕ trả laị cać măṭ hang̀ đã mua. Với lý do naỳ thì nên đưa receipt vaò mô hinh̀ . Tuy nhiên trong lâǹ lăp̣ laị đâù tiên naỳ , ta không xet́ đêń use case “Handle Returns” thì có thể bỏ qua receipt PTTKHT bang UML - BM HTTT 15
16. Môṭ số lưu ý khi taọ lớp ý niêṃ  Hay bị lâñ lôṇ giữa lớp ý niêṃ và thuôc̣ tinh.́  Để phân biêṭ haỹ dựa vaò quy tăć sau “ Nêú môṭ caí gì đó không có vẽ như 1 con số hay 1 từ thông thường trong thế giới thực thì có thể nó là 1 lớp ý niêṃ ”  Ví du:̣ store nên là 1 thuôc̣ tinh́ cuả Sale hay là 1 lớp ý niêṃ riêng biêt?̣ PTTKHT bang UML - BM HTTT 16
17. Lớp hay thuôc̣ tinh́ ? PTTKHT bang UML - BM HTTT 17
18. Môṭ số lưu ý khi taọ lớp ý niêṃ  Nêú phat́ sinh cać lớp ý niêṃ tương tự nhau → choṇ lớp naò  Giả sử có 2 lớp POST và Register có chức năng như sau: ◦ POST (viêt́ tăt́ Point-Of-Sale Terminal) để chỉ thiêt́ bị cuôí cuả hệ thônǵ ◦ Register: trước đây cać cửa hang̀ có thoí quen ghi laị cać hoá đơn và thanh toań vaò sổ goị là register. ◦ Ngaỳ nay POST thay thế vai trò cuả register PTTKHT bang UML - BM HTTT 18
19. Môṭ số lưu ý khi taọ lớp ý niêṃ  Hai lớp POST và Register tương tự nhau, nên choṇ lớp nao??̀ PTTKHT bang UML - BM HTTT 19
20. UML và biểu diễn lớp ý niệm  Trong UML, phần tử class được biểu diễn bằng 1 hình hộp chữ nhật, thường chứa ba ngăn như sau: Name Attributes Operations  Trong RUP thì tùy theo mỗi loại mô hình, biểu tượng class sẽ thay đổi để đặc trưng cho mỗi loại lớp. PTTKHT bang UML - BM HTTT 20
21. RUP và biểu diễn lớp  Trong mô hình nghiệp vụ (domain model) các lớp ý niệm (conceptual class) được biểu diễn bằng biểu tượng class của UML nhưng chỉ có 2 ngăn tên và thuộc tính  Trong mô hình thiết kế (design model) các lớp thiết kế được biểu diễn bằng biểu tượng class của UML đủ 3 ngăn  Trong mô hình thực thi thì các lớp phần mềm (sofware class) được biểu diễn tuỳ theo ngôn ngữ hướng đối tượng PTTKHT bang UML - BM HTTT 21
22. PTTKHT bang UML - BM HTTT 22
23. Môí kêt́ hợp (Association) giữa cać lớp  Association name (tên kêt́ hợp)  Cơ số (multiplicity)  Vai trò (role)  Cać rang̀ buôc̣ (constraint) PTTKHT bang UML - BM HTTT 23
24. Môí kêt́ hợp giữa cać lớp  Association name (tên kêt́ hợp): thường là 1 đông̣ từ hay cuṃ đông̣ từ để mô tả cać đôí tượng liên kêt́ với nhau như thế nao.̀  Măc̣ dù cać lớp tham gia vaò môí quan hệ naỳ là như nhau nhưng muc̣ đich́ cuả môĩ liên kêt́ là khać nhau, và vì vâỵ cać liên kêt́ naỳ có quy luâṭ và môí tương tać hoaǹ toaǹ khać nhau PTTKHT bang UML - BM HTTT 24
25. Môí kêt́ hợp giữa cać lớp  Ví dụ môṭ người (person) có thể là chủ nhân cuả 1 caí xe (car), hay chỉ là người laí xe,hay người thuê xe. PTTKHT bang UML - BM HTTT 25
26. Môí kêt́ hợp giữa cać lớp  Cơ số (multiplicity) cuả kêt́ hợp: Để xać đinḥ chinh́ xać có bao nhiêu đôí tượng có thể tham gia vaò liên kêt́  Biêủ diêñ cơ số theo cać cach́ sau: ◦ Cać giá trị được phân cach́ nhau bởi có nghiã là 1 miêǹ giá tri.̣ Ví dụ 1 5 ◦ Cać giá trị phân cach́ nhau băng̀ dâú phâỷ có tinh́ chât́ liêṭ kê. Ví dụ 4,8,11 ◦ Dâú * khi dung̀ 1 minh̀ có nghiã là 0 hay nhiêù hơn, dâú * khi dung̀ trong 1 daỹ (1 *) có nghiã là không có giới haṇ trên và phaỉ có it́ nhât́ là 1 PTTKHT bang UML - BM HTTT 26
27. Môí kêt́ hợp giữa cać lớp PTTKHT bang UML - BM HTTT 27
28. Môí kêt́ hợp giữa cać lớp  Vai trò (role) cuả sự kêt́ hợp: dung̀ để mô tả môṭ đôí tượng tham gia vaò môí liên kêt́ như thế nao.̀  Câǹ lưu ý về tên vai trò và tên liên kêt́ : Tên vai trò (role) sẽ được phat́ thanh̀ mã sau naỳ nhưng tên liên kêt́ thì không.  Tên vai trò có thể được dung̀ để đăṭ tên cho thuôc̣ tinh́ giữ môí tham chiêú cuả lớp. PTTKHT bang UML - BM HTTT 28
29. Môí kêt́ hợp giữa cać lớp  Ví dụ về vai trò cuả sự kêt́ hợp “Lớp Project có thuôc̣ tinh́ programmer, để giữ môí tham chiêú đêń lớp Employee naò có vai trò là programmer. Tương tự thuôc̣ tinh́ projectlead cuả lớp Project dung̀ để giữ môí tham chiêú đêń Employee naò đonǵ vai trò là projectlead” PTTKHT bang UML - BM HTTT 29
30. PTTKHT bang UML - BM HTTT 30
31. Môí kêt́ hợp giữa cać lớp  Cać rang̀ buôc̣ (constraint) cuả kêt́ hợp Rang̀ buôc̣ có thể đươc thêm vaò môí kêt́ hợp và được đăṭ về phiá liên kêt́ gâǹ với lớp bị rang̀ buôc̣ để quy đinḥ chỉ có điên̉ hinh̀ naò cuả lớp tuân theo rang̀ buôc̣ mới đuợc tham gia vaò môí kêt́ hợp.  Trong UML, rang̀ buôc̣ được đăṭ trong {} PTTKHT bang UML - BM HTTT 31
32. Lớp kêt́ hợp (association class)  Lớp kêt́ hợp sẽ bao chứa (encapsualate) moị thông tin đăc̣ điêm̉ về môṭ kêt́ hợp naò đo.́  Lớp kêt́ hợp cung̃ tương tự như 1 lớp binh̀ thường, cung̃ có tên, thuôc̣ tinh.́  Lớp kêt́ hợp nôí đêń cać class khać băng̀ đường đứt net.́ PTTKHT bang UML - BM HTTT 32
33. Lớp kêt́ hợp (association class) Môí kêt́ hợp giữa 2 lớp Customer và Product được chuyên̉ thanh̀ lớp kêt́ hợp Order PTTKHT bang UML - BM HTTT 33
34. Cać kiêủ kêt́ hợp  Kêt́ hợp phan̉ xạ (reflexive association)  Quan hệ kêt́ nhâp̣ (aggregation relationship) PTTKHT bang UML - BM HTTT 34
35. Kêt́ hợp phan̉ xạ (reflexive association)  Dung̀ để chỉ môí kêt́ hợp giữa cać đôí tượng trong cung̀ 1 lớp  Cả hai kêt́ hợp trên là tương đương nhau nhưng kêt́ hợp 1 thì dung̀ tên role coǹ kêt́ hợp 2 thì dung̀ chinh́ tên cuả kêt́ hợp để diêñ tả PTTKHT bang UML - BM HTTT 35
36. Quan hệ kêt́ nhâp̣ (Aggregation relationship)  Là dang̣ kêt́ hợp đăc̣ biêṭ để chỉ ra răng̀ cać đôí tượng tham gia vaò quan hệ không chỉ là cać đôí tượng đôc̣ lâp̣ mà chunǵ được tổ hợp hay câú hinh̀ cung̀ nhau để taọ ra môṭ đôí tượng mới phức tap̣ hơn.  Ví du,̣ môṭ số phụ tung̀ khać nhau có thể tổ hợp laị để taọ ra xe hơi, taù thuỷ , hay maý bay. PTTKHT bang UML - BM HTTT 36
37. Quan hệ kêt́ nhâp̣ (Aggregation relationship)  Để taọ ra quan hệ kêt́ nhâp̣ trong lược đồ lớp: ◦ Vẽ đường kêt́ nôí (association line) giữa lớp thanh̀ viên với lớp đonǵ vai trò tổ hợp hay kêt́ nhâp.̣ ◦ Vẽ 1 hinh̀ thoi (diamond) vaò 1 đâù kêt́ hợp, phiá lớp tổ hợp hay kêt́ nhâp.̣ ◦ Gań cơ số thich́ hợp vaò cuôí môĩ môí kêt́ hợp, bổ sung cać quy luâṭ hay rang̀ buôc̣ nêú câǹ vaò quan hệ PTTKHT bang UML - BM HTTT 37
38. Quan hệ kêt́ nhâp̣ (Aggregation relationship) PTTKHT bang UML - BM HTTT 38
39. Cać môí kêt́ hợp có độ ưu tiên cao  Thường cać môí kêt́ hợp có độ ưu tiên cao luôn được dung̀ trong mô hinh̀ nghiêp̣ vu:̣ ◦ A is a physical or logical part of B. Register Store SaleLineItem Sale ◦ A is physically or logically contained in/on B. ProductDescription ProductCatalog ◦ A is related to B Payment Sale PTTKHT bang UML - BM HTTT 39
40. Case study 1: Hệ thônǵ POS  Mô hình nghiệp vụ sơ lược lúc đầu của hệ thống POS như sau: PTTKHT bang UML - BM HTTT 40
41. Nguyên tăć để taọ môí kêt́ hợp giữa cać lớp ý niêṃ  Nguyên tắc: Chỉ tập trung vào các kết hợp “need-to-know”, tránh tạo ra các kết hợp dư thừa hay suy diễn  PTTKHT bang UML - BM HTTT 41
42. PTTKHT bang UML - BM HTTT 42
43. Cać môí kêt́ hợp bi loaị bỏ bởi nguyên tăć “need-to-know” Mối kết hợp Bàn luận Initiated-by (giữa Các yêu cầu không chỉ ra nhu cầu cần phải biết Sale và cashier) hay phải ghi nhận thâu ngân hiện hành. Hơn nữa, nó được suy diễn từ mối kết hợp giữa Register và Cashier Records-Sales-on Các yêu cầu không chỉ ra nhu cầu cần phải biết hay phải ghi nhận lại thâu ngân hiện hành Started-by Các yêu cầu không chỉ ra nhu cầu cần biết hay ghi nhận người quản lý (manager) nào khởi động Register Initiated-by (giữa Các yêu cầu không chỉ ra nhu cầu cần biết hay ghi Sale và customer) nhận khách hàng (customer) nào bắt đầu một cuộc mua bán (sale) Stocks Các yêu cầu không chỉ ra nhu cầu cần biết hay phải duy trì thông tin kho Records-sale-of Các yêu cầu không chỉ ra nhu cầu cần biết hay phải duy trì thông tin khoPTTKHT bang UML - BM HTTT 43
44. PTTKHT bang UML - BM HTTT 44
45. Nguyên tăć để taọ môí kêt́ hợp giữa cać lớp ý niêṃ  Nếu theo “need-to-know” nghiêm ngặt thì sẽ phải bỏ qua1 số mối kết hợp ➔Lược đồ sẽ không còn truyền đạt đầy đủ ý nghĩa nghiệp vụ nữa.  Do đó ngoài tiêu chuẩn này cần phải dựa vào cả nghiệp vụ để hiểu & truyền đạt được các khái niệm quan trọng và mối quan hệ giữa chúng.  PTTKHT bang UML - BM HTTT 45
46. Nguyên tăć để taọ môí kêt́ hợp giữa cać lớp ý niêṃ  Do đó, theo tiêu chuẩn need-to-know thì mối kết hợp “ Initiated-by” giữa Sale và Customer là không cần thiết nhưng nếu thiếu mối kết hợp này thì sẽ làm thiếu đi một ngữ cảnh quan trọng của nghiệp vụ là khách hàng chính là người phát ra việc mua bán (sale), nên mối kết hợp này cần phải giữ lại. PTTKHT bang UML - BM HTTT 46
47. Xać đinḥ thuôc̣ tinh́ cuả lớp  Thuôc̣ tinh́ mô tả 1 phâǹ thông tin cuả môṭ lớp.  Môĩ thuôc̣ tinh́ đêù phaỉ được đăṭ tên và xać đinḥ loaị dữ liêụ mà nó chứa, có thể có cać rang̀ buôc̣ (constraint) về giá tri.̣  Thường giá trị măc̣ đinḥ (default value) sẽ baỏ đam̉ thuôc̣ tinh́ luôn luôn chứa dữ liêụ có nghiã và hợp lê.̣ PTTKHT bang UML - BM HTTT 47
48. Là artifact cuả elaboration 1 PTTKHT bang UML - BM HTTT 48
49. Hệ thônǵ POS  Trong các lần lặp tiếp theo sẽ có sự chuyển tiếp dần từ việc tập trung vào yêu cầu sang tập trung vào thiết kế và thực thi.  Cuối giai đoạn elaboration, có thể 80% các yêu cầu đã được xác định chi tiết và rõ ràng. PTTKHT bang UML - BM HTTT 49
50. Phân loaị lớp ý niêṃ  Có 3 loại analysis class trong mô hình analysis: ◦ Boundary · ◦ Control· ◦ Entity  Từ flow of event cuả UC xać đinḥ được cać lớp phân tich,́ cać lớp naỳ đa số đêù thuôc̣ loaị entity  Hai loaị lớp coǹ laị thường không có măṭ trong flow of events 50
51. Entity class  Được dùng để mô hình thông tin cần được lưu trữ bởi hệ thống và các hành vi có liên quan đến nó.  Có đặc tính “persistent” thường được sử dụng lại trong các use case khác.  Chỉ ra cấu trúc dữ liệu có tính logical của hệ thống. Ví dụ: entity class“Clerk Profile” chứa thông tin về hồ sơ làm việc cá nhân của nhân viên 51
52. Boundary class  Nằm trên phạm vi giữa hệ thống và thế giới bên ngoài.  Dùng để mô hình mối tương tác giữa các actor với hệ thống.  Dùng để nắm bắt được các yêu cầu của giao diện người dùng.  Có dạng form, windows và các interface với ứng dụng khác. 52
53. Boundary class  Ví dụ: lớp boundary tên “Logon Screen” biểu diễn giao diên mà người dùng phải sử dụng để đăng nhâp̣ vào hệ thông. Nó yêu cầu ID và password của người dùng. Logon Screen 53
54. Tìm boundary class  Có ít nhất 1 boundary class cho mỗi tương tác giữa actor–use case. Nó là cái mà cho phép actor tiếp xúc với hệ thống. 54
55. Tìm boundary class  Không nhất thiết phải tạo class riêng biệt cho mỗi cặp actor- use case.  Ví dụ: 2 actor có cùng 1 boundary class để giao tiếp với hệ thống 55
56. Control Class  Là các đối tượng dùng để kiểm soát flow của use case. Nó không thực thi một chức năng nghiệp vụ nào cả, mà điều phối giám sát các đối tượng khác.  Control class không xuất hiện trong flow of event  Ví dụ: một control class phải biết là có nên kiểm tra an ninh của user trước khi tạo báo cáo hay không. Nó không tự kiểm tra mức an ninh hay tự tạo báo cáo nhưng chứa logic tuần tự và các quy tắc nghiệp vụ để báo cho 1 object khác kiểm tra an ninh và tạo báo cáo. 56