uml - From the given scenario I need help knowing if my Sequence Diagram is correct - Stack Overflow

admin管理员组

文章数量:1023242

This is the scenario I am trying to create a sequence diagram for :

A medical Assistant needs to view patients’ information by supplying the patient’s ID (PID) to specify whose information is required. The information system module requests the necessary information from the Medicare system which seeks authorization from the Authorization System (AS). If the request is validated, the necessary authorization is approved. If authorized, the patient’s information is returned and is displayed on a form on the user’s screen. If authorization fails, an error message (“Authorization Failed”) is returned.

The following is my sequence diagram:

I am unsure whether i need to add a fifth class for Patient information that is validated,as well as if my labels are corret? Any help appreciated thank you!

This is the scenario I am trying to create a sequence diagram for :

A medical Assistant needs to view patients’ information by supplying the patient’s ID (PID) to specify whose information is required. The information system module requests the necessary information from the Medicare system which seeks authorization from the Authorization System (AS). If the request is validated, the necessary authorization is approved. If authorized, the patient’s information is returned and is displayed on a form on the user’s screen. If authorization fails, an error message (“Authorization Failed”) is returned.

The following is my sequence diagram:

I am unsure whether i need to add a fifth class for Patient information that is validated,as well as if my labels are corret? Any help appreciated thank you!

• uml
• diagram
• sequence-diagram
• case-tools

Share Improve this question Follow edited Nov 19, 2024 at 0:42 Christophe 73.8k77 gold badges8383 silver badges169169 bronze badges asked Nov 18, 2024 at 19:10 StarKidStarKid 1122 bronze badges

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 0

The sequence diagram seems to correspond to the narrative.

The headers of the lifelines seem ok. Here MedicareSystem would be the name of a system instance. If it would be the instance of a class, you'd use something like

 :PatientInfo          (anonymous instance of class PatientInfo))

or

 patient:PatienInfo    (named object, the name can then be used in expressions.     

The return messages in the alt fragment could be dotted return messages, as the caller probably reads the answer to the request and doesn't wait to be called back. But this is a detail. More info on the use of return messages here.

There is no need for a fifth life line with the patient info. Indeed, the other lines do not exchange messages with this class, at least not at the level of granularity used for the diagram. You could just indicate the returned object in the feedback message:

patientInfo = ReturnPatientInfo() 

It is basically Ok. However, I have some remarks.

The PID in the first message is probably the parameter name. It is not necessary to show it here, because the interaction obviously doesn't depend on the actual value of this parameter. If you really want to show the parameter name, you have to assign it a value. This could also be a wildcard value, which is shown with a hyphen: SupplyPatientInfo(PID=-).

For me it looks as if all messages in the alt-fragment should be reply messages. Following rule applies for the message label:

<reply-message-label> ::=  
[<assignment-target> ‘=’] <message-name> [‘(’ [<output-argument-list>] ‘)’]
[‘:’ <value-specification>]

The message name of a reply message is the same as the synchroneous message it is replying to. The reply to RequestAuthorization() would therefore be labeled with RequestAuthorization():True. As you see, the return value is shown after the message name separated by a colon.

The next reply message would be labeled: RequestInfo():requestedPatientInfo

You could save one reply message by moving it out of the alt fragment and assign the return value to a local variable: authorized=RequestAuthorization(). The condition in the alt-fragment would then simply be [authorized].

If you leave the two reply messages, you should remove the conditions in the alt fragment. The two scenarios described in the fragments are already defined by the different return values. Since these are only arriving in the fragment, the values cannot determine which fragment occurs.

As you see, names of reply messages are pre determined. If you want to use different names, you can use asynchroneous signals in both directions instead. Maybe, that is even a better representation for communication with humans, which is inherently asynchroneous. These messages are shown with open arrow heads. Good names for signals to the MedicalAssistant could be PatientInfo(info:foundPatientInfo) and Error(text:"Authentication Failed").

The execution specifications (the long, grey, vertical boxes) should only begin after a lifeline has received a message. Of course, they don't add any useful information. So, simply remove them - they are optional. This also makes it easier to edit the diagram.

All the lifelines are probably representing participants of this interaction typed by the classes named in the head of the lifeline. As types the names should have a leading colon. Of course, everybody will also understand it without them.

This is the scenario I am trying to create a sequence diagram for :

A medical Assistant needs to view patients’ information by supplying the patient’s ID (PID) to specify whose information is required. The information system module requests the necessary information from the Medicare system which seeks authorization from the Authorization System (AS). If the request is validated, the necessary authorization is approved. If authorized, the patient’s information is returned and is displayed on a form on the user’s screen. If authorization fails, an error message (“Authorization Failed”) is returned.

The following is my sequence diagram:

I am unsure whether i need to add a fifth class for Patient information that is validated,as well as if my labels are corret? Any help appreciated thank you!

This is the scenario I am trying to create a sequence diagram for :

A medical Assistant needs to view patients’ information by supplying the patient’s ID (PID) to specify whose information is required. The information system module requests the necessary information from the Medicare system which seeks authorization from the Authorization System (AS). If the request is validated, the necessary authorization is approved. If authorized, the patient’s information is returned and is displayed on a form on the user’s screen. If authorization fails, an error message (“Authorization Failed”) is returned.

The following is my sequence diagram:

I am unsure whether i need to add a fifth class for Patient information that is validated,as well as if my labels are corret? Any help appreciated thank you!

• uml
• diagram
• sequence-diagram
• case-tools

Share Improve this question Follow edited Nov 19, 2024 at 0:42 Christophe 73.8k77 gold badges8383 silver badges169169 bronze badges asked Nov 18, 2024 at 19:10 StarKidStarKid 1122 bronze badges

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 0

The sequence diagram seems to correspond to the narrative.

The headers of the lifelines seem ok. Here MedicareSystem would be the name of a system instance. If it would be the instance of a class, you'd use something like

 :PatientInfo          (anonymous instance of class PatientInfo))

or

 patient:PatienInfo    (named object, the name can then be used in expressions.     

The return messages in the alt fragment could be dotted return messages, as the caller probably reads the answer to the request and doesn't wait to be called back. But this is a detail. More info on the use of return messages here.

There is no need for a fifth life line with the patient info. Indeed, the other lines do not exchange messages with this class, at least not at the level of granularity used for the diagram. You could just indicate the returned object in the feedback message:

patientInfo = ReturnPatientInfo() 

It is basically Ok. However, I have some remarks.

The PID in the first message is probably the parameter name. It is not necessary to show it here, because the interaction obviously doesn't depend on the actual value of this parameter. If you really want to show the parameter name, you have to assign it a value. This could also be a wildcard value, which is shown with a hyphen: SupplyPatientInfo(PID=-).

For me it looks as if all messages in the alt-fragment should be reply messages. Following rule applies for the message label:

<reply-message-label> ::=  
[<assignment-target> ‘=’] <message-name> [‘(’ [<output-argument-list>] ‘)’]
[‘:’ <value-specification>]

The message name of a reply message is the same as the synchroneous message it is replying to. The reply to RequestAuthorization() would therefore be labeled with RequestAuthorization():True. As you see, the return value is shown after the message name separated by a colon.

The next reply message would be labeled: RequestInfo():requestedPatientInfo

You could save one reply message by moving it out of the alt fragment and assign the return value to a local variable: authorized=RequestAuthorization(). The condition in the alt-fragment would then simply be [authorized].

If you leave the two reply messages, you should remove the conditions in the alt fragment. The two scenarios described in the fragments are already defined by the different return values. Since these are only arriving in the fragment, the values cannot determine which fragment occurs.

As you see, names of reply messages are pre determined. If you want to use different names, you can use asynchroneous signals in both directions instead. Maybe, that is even a better representation for communication with humans, which is inherently asynchroneous. These messages are shown with open arrow heads. Good names for signals to the MedicalAssistant could be PatientInfo(info:foundPatientInfo) and Error(text:"Authentication Failed").

The execution specifications (the long, grey, vertical boxes) should only begin after a lifeline has received a message. Of course, they don't add any useful information. So, simply remove them - they are optional. This also makes it easier to edit the diagram.

All the lifelines are probably representing participants of this interaction typed by the classes named in the head of the lifeline. As types the names should have a leading colon. Of course, everybody will also understand it without them.

本文标签： umlFrom the given scenario I need help knowing if my Sequence Diagram is correctStack Overflow