Bạn đang xem bài viết Staruml 5.0 User Guide (Modeling With Sequence Diagram) được cập nhật mới nhất trên website Englishhouse.edu.vn. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất.
Modeling with Sequence Diagram
The following elements are available in a sequence diagram.
Object
Stimulus
SelfStimulus
Combined Fragment
Interaction Operand
FrameSubsytem
Object
Procedure for creating object
In order to create object,
window].
Object quick dialog is shown. At the quick dialog, enter the object name.
Press [Enter] key.
Procedure for setting active object
In order to set class to active object,
Set assigned class’s [IsActive] property to true.
For MyObject, change MyClass’s IsActive property.
If class property is not assigned, you can’t change object to active object. The result is as follows.
Procedure for setting to multi object
In order to set object to multi object,
Set object’s [IsMultiInstance] property to true.
Then the object is changed to multi object.
Procedure for creating object from class
In order to create object from class,
Select class in the [model explorer].
Drag and drop it into [main window].
Finally, a object is created on the diagram.
Procedure for creating class from object
If class is not assigned to object,
At the [Enter element name] dialog, enter the new class name.
And new class is created and assigned to object.
button in object’s classifier property, and select class to be assigned to object at the [Select a model element] dialog.
Procedure for creating outgoing from object stimulus by using shortcut creation syntax
In order to create outgoing stimulus from selected object to another object,
pop up quick dialog.
Press [Enter] key and outgoing stimulus from selected object to target object is created and placed at the last order.
Stimulus
Semantics
A Stimulus is a communication between two Instances that conveys information with the expectation that action will ensue. A Stimulus will cause an Operation to be invoked, raise a Signal, or cause an Instance to be created or destroyed.
Procedure for creating stimulus
In order to create stimulus,
button.
Drag from one object, and drop to the other(object or lifeline) in the [main window] in outgoing direction.
Stimulus quick dialog is opened. Enter the stimulus name at the quick dialog and press [Enter] key.
Finally, a stimulus is created as follows.
Procedure for using operation in class as stimulus
If classifier property of receiver(object) of stimulus is assigned and you want to assign operation to stimulus,
Select operation
New stimulus mapped to class’s operation is added as follows.
Procedure for creating operation of class from object
To create operation of class as stimulus’s receiver from object and assign it to stimulus,
button at the quick dialog.
button.
New operation is added to the class and text is filled at the quick dialog (This procedure is valid when there exists assigned class.). Press [Enter] key.
See [model explorer] to confirm creation of new operation.
Procedure for creating previous stimulus of current stimulus by using shortcut creation syntax
In order to create previous stimulus to current stimulus,
stimulus, or select a stimulus and press [Enter] key.
At the quick and stimulus name.
Press [Enter] key, and then new object and stimulus are created and arranged above selected stimulus.
Procedure for creating next stimulus to current stimulus by using shortcut creation syntax
In order to create next stimulus to selected stimulus,
stimulus, or select a stimulus and press [Enter] key.
At the quick and stimulus name.
Press [Enter] key, and then new object and stimulus are created and arranged next to selected stimulus.
Procedure for creating sub stimulus by using shortcut creation syntax
In order to create a sub stimulus of selected stimulus,
stimulus, or select a stimulus and press [Enter] key.
At the quick and sub stimulus name.
Press [Enter] key, and then new object and stimulus are created and arranged on the bottom of selected stimulus’s activation.
Procedure for reconnecting to another object
In order to reconnect stimulus to another object,
Drag the end of stimulus and drop it to another object.
Then stimulus will be connected to another object.
Procedure for changing ActionKind of stimulus
The [ActionKind] property of stimulus should be assigned to one of five sort as following. To change [ActionKind] property, select stimulus and select the [ActionKind] property on the properties window.
ActionKind Shape
CALL
SEND
RETURN
CREATE
DESTROY
SelfStimulus
Procedure for creating self-stimulus
In order to create self-stimulus,
button.
the [main window].
Object quick dialog is opened. At the quick dialog, enter the stimulus name and press [Enter] key.
The result of procedure is as follows. You may arrange stimulus position to reduce overlapping of text and line.
Combined Fragment
Procedure for creating combined fragment
In order to create Combined Fragment,
[Combined Fragment] button.
will be placed in the [main window].
A combined fragment is created.
Change interaction operator in the properties as follows.
The combined fragment is shown as follows.
Procedure for creating interaction operand
In order to create Interaction Operand,
button.
placed in the [main window].
interaction operand.
The selection points of interaction operand are shown, drag it to arrange its boundary.
Frame
Procedure for creating frame
In order to create Frame,
And
A new frame is created as follows.
Diagram
Procedure for showing sequence numbers in the diagram
In order to show or hide stimulus sequence number,
Select the diagram in the [model explorer] or in the [main window]
And configure [ShowSequenceNumber] property of diagram to true or false.
When [ShowSequenceNumber] is false, sequence diagram is shown as follows.
Procedure for changing signature style of message in the diagram
There are four message style. To change stimulus signature, select the diagram in the [model explorer] or in the [main window], and configure [MessageSignature] property of diagram to one of the followings.
Style Example
NONE
NAMEONLY
TYPEONLY
NAMEANDTYPE
Procedure for changing activation style in the diagram
In order to show or hide stimulus activation, select the diagram in the [model explorer] or in the [main window], and configure [ShowActivation] property of diagram to true or false.
Thực Hành Xây Dựng Bản Vẽ Sequence Diagram
Trong bài trước chúng ta đã tìm hiểu về Sequence Diagram, các thành phần, cách xây dựng và ứng dụng của nó. Trong bài này, chúng ta sẽ bàn về cách ứng dụng sequence diagram để thiết kế cho hệ thống eCommerce mà chúng ta đã bàn ở bài 3 của chuyên mục này.
1. Xây dựng Sequence Diagram
Bước 1: Xác định các Use Case cần thiết kế
Tương tự như Activity Diagram, chúng ta cũng cần xác định các Use Case mà chúng ta cần sử dụng sequence Diagram để thiết kế chi tiết.
Xem xét bản vẽ Use Case Diagram chúng ta đã vẽ ở bài 3, chúng ta có thể thấy các Use Case sau cần thiết kế:
– Xem sản phẩm theo chủng loại
– Thêm sản phẩm theo nhà cung cấp
– Thêm giỏ hàng
– Chat
– Quản lý đơn hàng
– Thanh toán
– Theo dõi chuyển hàng
– Đăng nhập
Tiếp theo, chúng ta sẽ thiết kế cho chức năng ” Xem sản phẩm theo chủng loại “.
Bước 2: Xem Activity Diagram cho Use Case này chúng ta xác định các bước sau:
– Người dùng chọn loại sản phẩm
– Hệ thống sẽ lọc lấy loại sản phẩm tương ứng, sau đó lấy giá, lấy khuyến mãi và hiển thị lên màn hình.
– Người dùng xem sản phẩm
Bước 3: Đối chiếu với Class Diagram chúng ta xác định các đối tượng thực hiện như sau:
– Người dùng: chọn loại sản phẩm qua giao diện
– Giao diện: sẽ lấy danh sách sản phẩm tương ứng từ Products
– Giao diện: lấy giá của từng sản phẩm từ Class Prices và Promotion Amount từ lớp Promotions
– Giao diện: tổng hợp danh sách và hiển thị
– Người dùng: Xem sản phẩm
Bước 4: Vẽ sequence Diagram
– Xác định các lớp tham gia vào hệ thống gồm: người dùng (Guest), Giao diện (GUI System), Sản phẩm (Products), Giá (Prices), Khuyến mãi (Promotions). Trong đó GUI System để sử dụng chung cho giao diện, bạn có thể sử dụng cụ thể trang Web nào nếu bạn đã có Mockup (thiết kế chi tiết của giao diện).
– Guest gửi yêu cầu xem sản phẩm lên giao diện kèm theo chủng loại
– GUI system: gửi yêu cầu lấy danh sách các sản phẩm tương ứng với chủng loại cho lớp sản phẩm và nhận lại danh sách.
– GUI system: gửi yêu cầu lấy Giá cho từng sản phẩm từ Prices
– GUI system: gửi yêu cầu lấy khuyến mãi cho từng sản phẩm từ Promotions và nhận lại kết quả
– GUI system: ghép lại danh sách và hiển thị lên browser và trả về cho Guest
Thể hiện lên bản vẽ như sau:
Chúng ta nhận thấy để thực hiện được bản vẽ trên chúng ta cần bổ sung các phương thức cho các lớp như sau:
– Products class: bổ sung phương thức GetProductInfo(Product Type): trả về thông tin sản phẩm có loại được truyền vào. Việc này các đối tượng của lớp Products hoàn toàn làm được vì họ đã có thuộc tính ProductType nên họ có thể trả về được thông tin này.
– Prices: bổ sung phương thức GetPrice(ProductID): UnitPrice. Sau khi lấy được ProductID từ Products, GUI gọi phương thức này để lấy giá của sản phẩm từ lớp giá. Các đối tượng từ lớp Prices hoàn toàn đáp ứng điều này.
– Promotions: tương tự bổ sung phương thức GetPromotion(ProductID).
– GUI System(View Product Page): bổ sung phương thức DisplayProductList(List of product) để hiển thị danh sách lên sản phẩm. Ngoài ra, bạn cần có thêm một phương thức ViewProductbyType(ProductType) để mô tả chính hoạt động này khi người dùng kích chọn.
Như vậy, chúng ta thấy các phương thức trên đều thực hiện được trên các đối tượng của các lớp nên thiết kế của trên là khả thi. Bổ sung các phương thức trên vào các Class tương ứng chúng ta có bản vẽ Class Diagram như sau:
Hoàn tất sequence diagram cho tất cả các Use Case chúng ta sẽ hoàn thành việc thiết kế, đồng thời cũng hoàn tất bản vẽ Class Diagram.
2. Kết luận
Bản vẽ Squence Diagram có vai trò quan trọng trong việc thiết kế hệ thống. Đồng thời giúp chúng ta kiểm tra lại quá trình phân tích, thiết kế trước đây cũng như hoàn thành bản vẽ Class Diagram. Việc sử dụng thành thạo bản vẽ này giúp các bạn rất nhiều trong việc phân tích và thiết kế phần mềm.
Trong bài tiếp theo chúng ta sẽ bàn về Component Diagram và Deployment Diagram, những bản vẽ cuối cùng cho việc phân tích và thiết kế hướng đối tượng sử dụng UML. Mời các bạn đọc tiếp.
Bài tiếp: Bản vẽ Component Diagram
Bài trước: Bản vẽ Sequence Diagram
Ielts 5.0 Là Gì? Hướng Dẫn Cách Học Ielts 5.0 Cho Người Mất Gốc
I. LỘ TRÌNH HỌC IELTS 5.0 Trực tuyến CHO NGƯỜI MỚI bắt đầu
Về Ngữ pháp, thầy cô chia sử dụng 27 bài, trong đó 6 bài đầu các bạn sẽ củng cố về các thì trong tiếng Anh, chia động từ, 22 bài sau về các dạng từ , dạng câu và từ nối.
Cô có share mẹo học nhớ các thì lâu, các bạn nhấn theo đường link: đo đạt các thì cơ bản trong tiếng Anh với cách ghi nhớ hiệu quả
bên cạnh đó, một việc vô cùng quan trọng mà cô nghĩ các bạn cần làm đó chính là việc “tắm ngôn ngữ” bằng việc nghe tiếng Anh nhiều qua các đoạn speech, radio của TED, BBC, CNN…. (Tuy vào mức độ nghe mà lựa chọn nguồn thêm vào – cô đã chỉ dẫn rồi) để làm quen với kĩ năng nghe thật nhiều.
ngoài ra, bạn đủ sức nghe nhạc, nhìn thấy phim, xem show truyền ảnh Anh – Mỹ luyện cho bạn cả skill nghe và nói tiếng Anh chuẩn hơn rất nhiều.
tips học IELTS speaking
3 phương pháp sống sót trong IELTS Speaking khi cạn ý tưởng
5 tính từ không nên dùng trong IELTS Speaking
[IELTS Speaking] If you don’t like the Topic
cách dẫn dài câu trả lời trong IELTS Speaking Part 1
Khi bạn không hiểu câu hỏi trong IELTS Speaking
tuyệt chiêu trả lời câu hỏi: “What’s your favorite …?
Một số tài liệu bạn đọc qua để học Speaking hiệu quả:
Trọn bộ sách TỰ HỌC IELTS Speaking Full PDF + AUDIO: download
42 Topic IELTS speaking part 1 đa dạng và mẫu câu trả lời:
20 TOPIC HAY GẶP NHẤT TRONG IELTS SPEAKING PART 2: download
Một số sách writing các bạn sử dụng trong quá trình ôn tập như:
Visual IELTS – Gabi Duigu – để luyện Task 1: down
Academic writing for IELTS: down
quyển sách Ideas for IELTS topics – IELTS Fighter biên soạn:
Những quyển sách này giúp các bạn mới học luyện viết Task 2 không có ý tưởng và k biết cần viết gì thì bạn hoàn toàn đủ sức yên tâm dựa trên cuốn Ideas for IELTS topics để viết tốt hơn.
Phần Reading gồm 5 bài với những Chiến thuật giúp sử dụng bài Reading một hướng dẫn hiệu quả nhất, không những thế, cô thầy còn có bài chia sẻ để chỉ dẫn các bạn sử dụng bài tập tốt hơn!
Một số ebook các bạn dùng cho luyện tập skill reading như:
Những quyển sách này khá căn bản cho người bắt đầu học reading có thể bổ sung thêm từ vựng, ngữ pháp và luyện tập bài đọc từ dễ đến nâng cao.
bí quyết để refresh kỹ năng đọc tiếng Anh tốt nhất chính là các bạn cần luyện đọc hằng ngày. Các bạn nên dành 30-60 phút mỗi ngày vào buổi tối/sáng để đọc báo (National Geographic, BBC news, …) hay đọc truyện, tiểu thuyết… Và nghe (TED, BBC, CNN….) sẽ khiến bạn cải thiện rất tích cực 2 kĩ năng này.
Đọc tiếng Anh hằng ngày còn có lợi thế để bạn bổ sung vốn từ vựng hiệu quả và nâng cao skill viết tiếng Anh có văn phong tốt hơn.
Hiểu được các bạn tự học IELTS tại nhà sẽ chông gai với 2 skill Writing và Speaking, chính do đó IELTS Fighter thiết lập chuỗi video bài giảng 10 buổi IELTS writing & Speaking online miễn phí 100% do như Quỳnh cùng đội ngũ chuyên môn IELTS Fighter xây dựng.
Trong công cuộc ôn thi IELTS hiển nhiên các bạn không thể bỏ qua công đoạn luyện đề. Đây là giai đoạn sau quá trình học tập bổ sung kiến thức cho bản thân bạn cần luyện bộ đề IELTS để đo đạt lại kiến thức đang học, check trình độ chính mình cũng như luyện tập và sử dụng quen với cấu trúc đề thi IELTS chuẩn.
Thời gian mỗi tuần các bạn hãy luyện 1 bộ đề full cho cả 4 kỹ năng.
Thời gian đầu khi luyện đề bạn sẽ mất nhiều thời gian so với quy định thời gian thi, các bạn hãy làm mỗi đề thi và phân tích thật kỹ lỗi sai bạn gặp phải gợi ý chỉ rõ nguyên do vì sao câu hỏi này đáp án lại không giống với hiệu quả bạn sử dụng… tiến trình sử dụng đề đánh giá sẽ giúp các bạn đo đạt lại kiến thức vừa mới học kết quả hơn, dựng lại được cách thức làm bài tập cho từng dạng tốt hơn.
Một số tài liệu giúp bạn luyện đề hiệu quả:Cambridge IELTS từ 1-12 , Exam Essentials: IELTS Practice check 2, IELTS Practice Tests Plus 1, 2, 3…
Nguồn:https://ielts-fighter.com/
Use Case Diagram Và 5 Sai Lầm Thường Gặp
Hê lô anh em. Ở kỳ trước mình đã nói về BPMN – một đồ nghề khá hữu dụng của BA. Hôm nay mình sẽ tiếp tục nói về 1 trong những đồ nghề khác cũng cực kỳ quan trọng không kém, đó chính là Use Case.
Bản thân mình thời gian đầu dùng Use Case cũng gặp rất nhiều khó khăn. Một mớ bồng bông câu hỏi cứ lởn quởn trong đầu: bản chất của Use Case là gì, dùng cho mục đích nào, vẽ vậy đúng hay chưa, có chi tiết quá không, hoặc thậm chí vẽ Use Case xong cũng chẳng biết để làm gì???
Use Case là kỹ thuật dùng để mô tả sự tương tác giữa người dùng và hệ thống với nhau, trong một môi trường cụ thể và vì một mục đích cụ thể.
Sự tương tác ở đây có thể là:
Người dùng tương tác với hệ thống như thế nào?
Hoặc, hệ thống tương tác với các hệ thống khác như thế nào?
Và dĩ nhiên, sự tương tác này phải nằm trong một môi trường cụ thể, tức là nằm trong một bối cảnh, phạm vi chức năng cụ thể, hoặc rộng hơn là trong một hệ thống/ phần mềm cụ thể.
Sau cùng, việc mô tả sự tương tác này phải nhằm diễn đạt một mục đích cụ thể nào đó. Use Case phải diễn rả được Requirement theo góc nhìn cụ thể từ phía người dùng.
Ví dụ sơ đồ Use Case diễn tả sự tương tác giữa người dùng là độc giả với trang blog Thinhnotes chẳng hạn.
Tương tác ở đây là gì?
Độc giả đọc bài notes
Độc giả yêu thích bài notes
Độc giả chia sẻ bài notes
Độc giả nhận xét bài notes
Độc giả gửi bài notes cho độc giả khác qua email
Môi trường cụ thể?Quá đơn giản, đó là trang blog chúng tôi (không phải trang Admin).
Mục đích cụ thể?
Người dùng có thể đọc được bài notes trên blog (đơn giản bỏ qua)
Người dùng có thể bày tỏ được sự yêu thích bài notes
Người dùng có thể chia sẻ bài notes này trên các nền tảng khác để nhiều người khác có thể đọc được
Người dùng có thể viết nhận xét khen chê gạch đá các kiểu cho tác giả
Người dùng có thể gửi bài notes này qua email cho một người bất kỳ.
Đó là tất tần tật những nội dung mà một Use Case sẽ thể hiện.
Về hình thức thì Use Case tồn tại ở 2 dạng:
Hình vẽ Use Case (Use Case Diagram)
Đặc tả Use Case (Use Case Specification).
Use Case Diagram là một thành viên trong họ UML (Unified Modeling Language).
Mỗi Diagram trong bộ UML này đều có những mục đích khác nhau. Tùy trường hợp, tùy dự án mà anh em sẽ “rút hàng” ra chiến như thế nào cho hợp lý.
2.1. Actor, Use Case, Communication Link và Boundary
Cũng không có gì quá phức tạp, Use Case Diagram gồm 5 thành phần chính:
Actor
Use Case
Communication Link
Boundary of System
Và, Relationships.
Actor thì có thể là Người dùng, hoặc một System nào đó. Vì UML quy định Actor là hình thằng người nên có thể anh em sẽ nhầm lẫn chỗ đó phải là người dùng nhưng hổng phải.
Một số câu hỏi anh em có thể tự lẩm bẩm trong đầu để xác định Actor như sau:
Ai là người sử dụng hệ thống?
Ai sẽ là người Admin của hệ thống (tức người cài đặt, quản lý, bảo trì… hệ thống)?
Hệ thống này có được sử dụng bởi bất kỳ một hệ thống nào khác không? (*)
Hệ thống lưu trữ dữ liệu, vậy ai là người input dữ liệu vào hệ thống?
Hệ thống lưu trữ dữ liệu, vậy ai là người cần những dữ liệu output?
Ở mục (*), mình muốn highlight cho anh em chỗ này. Không phải giải pháp/ phần mềm nào làm ra đều được sử dụng bởi con người. Có những phần mềm làm ra, để cho… phần mềm khác sử dụng.
Chẳng hạn như làm các services. Mình có một anh bạn làm BA, giải pháp mà ảnh cùng đồng bọn làm ra là 1 services không được dùng bởi con người, mà được dùng bởi một hệ thống khác để xác thực người dùng.
Còn Use Case là anh em sẽ thể hiện dưới dạng hình Oval, thể hiện sự tương tác giữa các Actor và hệ thống.
Communication Link thể hiện sự tương tác giữa Actor nào với System. Nối giữa Actor với Use Case.
Boundary of System là phạm vi mà Use Case xảy ra. Ví dụ trong hệ thống CRM, phạm vi có thể là từng cụm tính năng lớn như Quản lý khách hàng, Quản lý đơn hàng, hoặc cả một module lớn như Quản lý bán hàng.
…
Ô kê nãy giờ dễ ẹc, mấy cái này nhìn sơ qua là anh em biết ngay cái một.
Cái cuối cùng mới chính là cái mà mình tin là nhiều anh em vẫn còn rất dễ lộn, đó là Relationship.
2.2. Relationship
Relationship gồm 3 loại: Include, Extend, và Generalization.
Include nghĩa là mối quan hệ bắt buộc phải có giữa các Use Case với nhau.
Xét về nghĩa, Include nghĩa là bao gồm, tức nếu Use Case A có mối quan hệ include Use Case B, thì nghĩa là: Use Case A bao gồm Use Case B. Để Use Case A xảy ra, thì Use Case B phải đạt được.
Xét ví dụ trên, chúng ta có Use Case: Nhận xét bài notes. Use Case này include 2 Use Case khác là: Đăng nhập WordPress và Soạn thảo nhận xét.
Rõ ràng anh em thấy: để nhận xét được một bài viết, anh em cần phải đăng nhập vào 1 tài khoản nào đó, để blog nhận diện anh em là ai, tên gì, quê quán, giai gái ra sao.
Ví dụ ở blog mình là anh em sẽ cần đăng nhập vào tài khoản WordPress. Sau khi đăng nhập xong, anh em phải soạn thảo nhận xét, tức là gõ nhận xét, chỉnh sửa, xóa tới xóa lui. Sau khi viết xong nhận xét, anh em sẽ bấm nút Submit để hoàn thành chẳng hạn.
Chỉ khi nào xong 2 bước trên ( đăng nhập và soạn thảo nhận xét), thì anh em mới có thể xong bước Nhận xét bài notes được.
Hay nói cách khác để Use Case: Nhận xét bài notes xảy ra, thì Use Case: Đăng nhập WordPress và Use Case: Soạn thảo nhận xét phải bắt buộc hoàn thành trước tiên.
Một số điểm cần chú ý khi vẽ Include cho Use Case
Thực sự không có quy tắc nào rõ ràng cho việc khi nào cần tách Use Case ra thành các Use Case nhỏ và cho nó một mối quan hệ Include cả.
Việc tách hay không tách phụ thuộc duy nhất vào người vẽ. Và lý do lớn nhất để mối quan hệ Include ra đời là giúp cho các Use Case của chúng ta DỄ QUẢN LÝ hơn; làm cho Use Case Diagram trông có vẻ nguy hiểm hơn mà thôi 😎
Và anh em chỉ nên tách Use Case khi nó có độ phức tạp lớn và những thứ tách ra được có thể được tận dụng ở các Use Case sau này.
Độ phức tạp lớn thì khi tách ra mình mới có được những Use Case vừa phải, đủ để diễn đạt dễ hiểu cho các stakeholders. Còn tận dụng được ở các Use Case sau là sao?
Ví dụ Use Case A gồm 2 Use Case nhỏ bên trong là X và Y. Do đó Use Case A được tách thành Use Case X và Use Case Y.
Tương tự, Use Case B gồm Use Case Y bên trong, nên được tách thành Use Case Y.
Nhưng, Use Case C gồm Use Case X và Use Case Z bên trong, nhưng chỉ có Use Case X là được tách ra cho mối quan hệ Include. Vì có thể Use Case Z “không đáng” để tách ra thành một Use Case nhỏ hơn.
Chúng ta tách Use Case X từ Use Case A để Use Case C có thể tận dụng được mà không cần vẽ lại. Tương tự, tách Use Cas Y từ Use Case B để Use Case A có thể tận dụng mà cũng không cần vẽ lại.
Điều này giúp Use Case Diagram của chúng ta trở nên chặt chẽ, logic và gọn nhẹ hơn rất nhiều.
Còn Use Case Z, vì nó không được “dùng lại” ở một Use Case bất kỳ nào sau đó, nên người vẽ có thể cân nhắc có tách nó ra hay không!
Nếu Use Case đó đủ lớn và khá là high-level, thì có lẽ chúng ta nên tách. Còn nếu ngược lại, Use Case đã rõ ràng, là một requirement từ phía User cụ thể thì không đáng để anh em tách nó ra thành một Use Case nhỏ, chỉ làm hình thêm thêm rối mà thôi.
Extend là mối quan hệ mở rộng giữa các Use Case với nhau.
Nếu Include là mối quan hệ bắt buộc, thì Extend là một mối quan hệ không bắt buộc. Nó thể hiện mối quan hệ có thể có hoặc có thể không giữa các Use Case với nhau.
Một Use Case B là extend của Use Case A thì có nghĩa Use Case B chỉ là một thứ optional, và chỉ xảy ra trong một hoàn cảnh cụ thể nào đó.
Lấy ví dụ Grab phía trên, anh em sẽ dễ dàng có được một mối quan hệ Extend như sau.
À…à…Nhắc tới lúc có lúc không, tức là nhắc tới điều kiện xảy ra.
Anh em có thể thể hiện rõ ý chỗ này bằng một thứ luôn đi kèm với Extend, đó là Extension Point 😎
Extension Point nôm na là điều kiện mà Use Case có mối quan hệ Extend sẽ xảy ra. Còn để sát nghĩa thì anh em có thể hiểu chữ Point ở đây nghĩa là điểm dữ liệu thể hiện sự khác biệt.
Tức nếu dữ liệu này là A thì Use Case không xảy ra, nhưng nếu dữ liệu này là B thì Use Case sẽ xảy ra.
//Theo mình nhớ là hình như anh em chỉ có thể gửi tiền tip cho tài xế, nếu cuốc xe đó anh em chấm họ maximum là 5 sao.//
Vậy thì anh em sẽ vẽ Use Case Diagram chỗ đó như sau.
Extension Point ở đây là dữ liệu Driver Rating. Nếu Driver Rating đạt giá trị 5 sao, thì Use Case: Gửi tiền tip cho lái xe sẽ xảy ra, và hoàn toàn optional, tùy thuộc vào khách hàng.
Extension Point không nhất thiết phải là một dữ liệu nào đó trên hệ thống, mà có thể là một “điều kiện” bất kỳ, miễn là nó thể hiện được trường hợp cụ thể mà Use Case sẽ xảy ra.
Ở một ví dụ khác.
c) Generalization
Generalization đơn giản là quan hệ cha con giữa các Use Case với nhau. Nhưng khác biệt với Include và Extend là nó còn được dùng để thể hiện mối quan hệ giữa các… Actor với nhau.
Đầu tiên là mối quan hệ cha-con giữa các Use Case. Ví dụ:
Đăng nhập thì có thể đăng nhập qua số điện thoại, hoặc đăng nhập qua email.
Đặt hàng thì có đặt hàng qua điện thoại, hoặc đặt hàng qua website.
Thanh toán thì thanh toán qua thẻ ATM, qua thẻ thanh toán quốc tế, hoặc qua ví điện tử.
Hoặc tìm kiếm thì có thể tìm kiếm bằng từ khóa, hoặc tìm kiếm theo nhóm sản phẩm.
Hoặc mối quan hệ cha-con giữa các Actor. Ví dụ:
Khách hàng gồm khách hàng cũ và khách hàng mới
Hoặc Vendor thì có thể gồm Retailers và Wholesalers.
Nhìn chung, Generalization giúp anh em thể hiện rõ hơn các yêu cầu bằng việc gom nhóm các Use Case lại theo quan hệ cha-con. Cá nhân mình thì rất ít khi vẽ relationship này, chủ yếu chỉ dùng Include và Extend là chính.
Còn một điểm nữa là Generalization có tính kế thừa. Tức thằng cha có gì thì thằng con có cái đó, kể cả Use Case hay Actor.
Ví dụ Use Case A có include đến Use Case B và C. Thì Use Case A’ là con của Use Case A cũng sẽ có mối quan hệ Include đến Use Case B và C, mặc dù không được thể hiện trên hình.
…
Ô kê, vậy là xong phần Relationship – một trong những phần chuối nhất, dễ lộn nhất trong Use Case. Hi vọng những ví dụ trên giúp anh em hiểu được cụ thể như thế nào là Include, Extend và Generalization trong một Use Case Diagram 😎
Use Case Diagram là thứ để anh thể hiện được requirement của khách hàng.
Vẽ sao mà khách hàng nhìn vô một phát là thấy khoái liền. Khách hàng mà chân nhịp nhịp, miệng lẩm bẩm: “Đúng rồi…đúng rồi…, tính năng này có,… tính năng kia có luôn, à… tích hợp lấy dữ liệu này có, ô kê ô kê,… vầy là đủ rồi!”, thì coi như anh em đã vẽ khá good 🙂
3.1. Chuyện đặt tên
Trong mô hình hóa, chuyện đặt tên là rất-rất-rất quan trọng.
Vì đã nói “mô-hình-hóa” tức là chúng ta dùng hình ảnh để nói chuyện, thì khi đó hàm lượng chữ chiếm rất ít. Và chính vì nó ít, nên những gì chúng ta ghi trên diagram phải rất súc tích, cô đọng và có giá trị ngay tức thì.
Chỉ cần người đọc họ nhìn vô diagram mà thấy ngay 1 dòng chữ khó hiểu, thì ngay lập tức tụt bà nó hết mood, hết muốn xem tiếp rồi.
Nói về Use Case thì có 1 vài lưu ý sau cho anh em:
Actor thì phải đặt tên bằng danh từ, không dùng động từ, và cũng không mệnh đề quan hệ gì hết.
Tên Use Case thì phải ghi rõ ràng, rành mạch, đẹp nhất là dưới format: Verb + Noun.
BA chúng ta vẽ Use Case nhằm mục đích diễn tả yêu cầu cho stakeholders hiểu, do đó anh em không được dùng những từ kỹ thuật trong đây, không thể hiện sự nguy hiểm ở đây, người ta đọc zô hông hiểu gì hết là trớt quớt.
Và đặc biệt là tránh đặt tên quá dài và không nên dùng kiểu bị động.
3.2. Vẽ Use Case mà thành phân rã chức năng
Đây chính xác là lỗi mà mình hay gặp nhất, rất thường xuyên gặp khi vẽ Use Case.
Dấu hiệu nhận biết rõ ràng nhất là khi Use Case Diagram của anh em đầy rẫy chữ “manage”, manage cái này, manage cái kia…
Đầu tiên là chữ Manage rất rộng nghĩa. Yêu cầu quản lý A gồm 5 việc, thì không có nghĩa yêu cầu quản lý B cũng gồm 5 việc. Use Case là diagram thể hiện yêu cầu của End-Users, nhằm đạt được một mục đích nào đó.
Ở ví dụ trên, nếu nói Manage Gears, Manage Brakes, hay Manage Air Conditioner thì quá tối nghĩa, chả ai hiểu nhằm mục đích sau cùng là để làm gì.
Nguyên nhân có thể do người vẽ chưa nắm đủ thông tin về yêu cầu của End-Users, ảnh chưa hiểu rõ rốt cuộc thì người dùng họ muốn làm gì trên hệ thống, hay hệ thống phải tương tác những gì với hệ thống khác.
Từ đó mới có chuyện anh em nhìn vô Use Case Diagram ở trên mà cảm thấy mông lung như một trò đùa. Do đó, chúng ta chỉ vẽ Use Case khi đã có đủ thông tin cần thiết:
Ngoài ra, khi đã có đủ thông tin nhưng Use Case mình vẽ vẫn bị confuse. Lý do có thể do các Use Case mình vẽ bị lệch các cấp độ Requirement với nhau.
Ví dụ Use Case A thì thể hiện Business Requirement, tức là rất high level. Nhưng sang Use Case B và C thì lại nói rất detail tới mức Solution Requirement như.
Để sửa lại Use Case trên, đơn giản mình chỉ cần bỏ Use Case A: Quản lý học viên ra, vì nó là thứ rất chung chung, không thể hiện được mục đích cụ thể, so với 2 Use Case còn lại.
Anh em tham khảo một số hình sau sẽ rõ.
Vấn đề của hình này là ôm đồm quá nhiều. Dẫn đến quá nhiều Use Case xuất hiện trong cùng một Diagram, đã vậy cũng không có Boundary of System rõ ràng.
Như anh em thấy, Use Case này vẽ rất sai ở những điểm như sau:
Xác định sai Use Case (nên mới nhiều UC như vậy): những thứ như single, double, num of guest… rõ ràng đâu phải là một Use Case, đâu phải là một sự tương tác.
Đặt tên Use Case sai: quá nhiều cụm danh từ cho Use Case.
Không có Boundary of System.
Những Use Case có extend không ghi chú cụ thể điều kiện khi nào thì UC extend xảy ra.
Một note nhỏ quan trọng cho anh em, Use Case Diagram sạch đẹp là chỉ nên có trên dưới 10 Use Case trong đó. Các Use Case còn lại anh em hãy dùng Boundary of System để phân chia theo phân hệ một cách hợp lý nhất có thể.
Hình này rõ ràng là quá thứ dữ. Thật ra trường hợp này cũng khá phổ biến, mình trước kia bị hoài. Mấu chốt đến từ một số điều sau:
Một số Use Case đặt tên sai
Chưa tận dụng các Relationship để thể hiện, khiến cho các Use Case quá rời rạc nhau, và trông rất không hợp logic.
Người vẽ không dùng Boundary of System để phân nhóm, giới hạn các Use Case.
Và đặc biệt, người vẽ quá chú trọng đến các chức năng cơ bản nhất, đó là: CRUD – Create/Read/Update/Delete.
3.4. Quá chi tiết các chức năng CRUD
Như ví dụ trên, mỗi thực thể là một lần CRUD. Như vậy quá tốn effort, trong khi 96,69% là ở phân hệ nào, hay dữ liệu nào, anh em cũng đều cần phải CRUD dữ liệu hết.
Điều này tạo ra một sự lặp đi lặp lại ở các Use Case Diagram, nhưng không thể hiện được gì nhiều cho người xem. Để giải quyết vấn đề này, anh em có thể có làm 1 trong 2 cách sau.
Thêm một dòng note trước đoạn mô tả Use Case trong tài liệu: “Toàn bộ dữ liệu đều có chức năng Thêm/ Đọc/ Sửa/ Xóa và chịu tác động bởi sự phân quyền từ phía Quản trị hệ thống” hoặc đại loại vậy. Để cho các stakeholder biết được rằng hệ thống có chức năng CRUD các dữ liệu này.
Nhưng nên nhớ CRUD ở đây là đứng từ góc nhìn End-Users: hệ thống có cho phép End-Users CRUD dữ liệu hay không?
Ví dụ hệ thống CRM lấy dữ liệu khuyến mãi từ hệ thống ERP. Thì về bản chất CRM phải có khả năng Create dữ liệu khuyến mãi, thì mới lấy dữ liệu khuyến mãi từ ERP về được.
Nhưng theo góc nhìn của End-Users, thì không một người dùng nào (kể cả System Admin) có thể tạo thủ công dữ liệu khuyến mãi trên CRM, mà End-Users họ chỉ Đọc/ Sửa/ Xóa dữ liệu được lấy về này thôi.
Do đó ở đây anh em cần mô tả rõ là có phải tất cả dữ liệu đều cho phép End-Users CRUD được hay không (không tính phân quyền).
Tạo hẳn một Use Case với tên là: Manage “X”, với X là một đối tượng bất kỳ.
Nếu không đầy đủ 4 tính năng CRUD, thì anh em có thể làm 1 cái note nhỏ bên trên, nói rõ Manage là có những tính năng gì, không có những tính năng gì.
Cuối cùng vẫn quay về vấn đề thẩm mỹ. Nguyên nhân việc Use Case mất thẩm mỹ đến từ 2 lý do:
Mắt thẩm mỹ kém: chiếm 0,00000000000069%
Ẩu, cẩu thả: chiếm 99,00000000000000069%
Làm gì cũng vậy, đặc biệt là mô hình hóa để làm document. Ẩu là thứ mình nên cố gắng hạn chế nó nhất. Vì làm đúng 1 lần, đẹp 1 lần, sau này đỡ mắc công làm lại chứ hông có gì hết.
Một số điểm anh em cần chú ý sau:
Kích cỡ các Use Case trong Diagram là phải như nhau, kể cả cha-con, lẫn các mối quan hệ Include. Tuy nhiên, Use Case có Extend sẽ được vẽ to hơn một chút.
Nhớ phải đánh dấu Use Case ID trong hình vẽ.
Các mối quan hệ không được chồng chéo lẫn nhau. Anh em có thể vẽ 1 Actor ở 2 vị trí khác nhau để tránh các đường nối bắt chéo lên nhau.
Khi vẽ Use Case Diagram, tập trung vào câu hỏi What để tìm ra Use Case, tránh câu hỏi How, vì khi đó anh em rất dễ đi vào detail.
Và nếu được, hãy tô màu lên Use Case để nhìn Diagram được rõ ràng, sáng sủa và mạch lạc 🙂
.
.
.
Hi vọng qua bài này anh em đã hiểu rõ bản chất của Use Case, và biết cách vẽ Use Case Diagram. À mà không những biết cách vẽ, mà còn vẽ đúng, vẽ đẹp và tránh được những lỗi sai thường gặp nữa.
Bái bai và hẹn gặp lại anh em!!!
Cập nhật thông tin chi tiết về Staruml 5.0 User Guide (Modeling With Sequence Diagram) trên website Englishhouse.edu.vn. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung để bạn nhận được thông tin nhanh chóng và chính xác nhất. Chúc bạn một ngày tốt lành!