Control Flow Logic in Seqence Diagram

[jyoung]

Hi all,

I am trying to model a Login Use Case with a Seqence Diagram.

I am having trouble getting control flow logic into the diagram. I have the main success flow laid out but if the users password or username is bad then i want to take a different action (i.e. show bad login to user instead of redirection to home page).

Now I have found that Fragments are what I should use for this, but I cannot figure out how to add sequences to the fragment.

If anyone could supply a link or reference or anything that can help me out, it would be greatly appreciated.

Many Thanks,

Joe

[Paolo F Cantoni]

Hi all,

I am trying to model a Login Use Case with a Seqence Diagram.

I am having trouble getting control flow logic into the diagram. I have the main success flow laid out but if the users password or username is bad then i want to take a different action (i.e. show bad login to user instead of redirection to home page).

Now I have found that Fragments are what I should use for this, but I cannot figure out how to add sequences to the fragment.

If anyone could supply a link or reference or anything that can help me out, it would be greatly appreciated.

Many Thanks,

Joe

Hi Joe,

My understanding was that the Sequence diagram only models a sequence of calls.  No conditioanly logic s possible.

I thought they were designed to show a specific scenario in a use case - thus you would need a diagram for each flow.

HTH,
Paolo

[jyoung]

Hi Paolo,

I thought the same thing too then I discovered this link:
http://www-128.ibm.com/developerworks/rational/library/3101.html

Granted they appear to be using Rational but if I read the article correctly fragments are part of UML 2.0.

I don't know perhaps its best to have different scenarios in different diagrams just trying to reduce the amout of work involved.

Thanks Joe

[jyoung]

To kinda followup on what I am trying to do, here is my Login Sequence:


The "alt Validate" is the alternate fragment. I am trying so specify a sequence in the fragment when user == null and when user != null.

This may not be the way to do things. I am still somewhat new to UML.

If it is "best practice" to have every scenario (main success and alternates) in seperate models, do you model the entire sequence or just the sequence that changes, in this case the Validate method?

How would you model complex logic in UML and specifically in EA?

Thanks,

Joe

[Paolo F Cantoni]

[size=13][SNIP][/size]
Granted they appear to be using Rational but if I read the article correctly fragments are part of UML 2.0.

I don't know perhaps its best to have different scenarios in different diagrams just trying to reduce the amount of work involved.
[size=13][SNIP][/size]

Hi Joe,

I must confess that I was actually talking about interaction diagrams...  :-(  Since I'm principally a Data Architect, I'm not as familiar as I should be with the behaviour diagrams...  Alternate flows CAN be shown on sequence diagrams by means of suitable guards on the message transitions.

Anyhow, it does seem as though the example you referred to is using UML 2.0.  The UML 2 [size=13]Superstructure[/size] Specification confirms the usage.

However, for what it's worth, I might make a couple of observations on your diagram and what I saw in the IBM example.

1) The Alt frames use guards to create the various operands.  Guards, in my view, are slightly more complicated than simple conditionals and it's important to ensure that there is an explicit else option.  In your example, I would expect [User == null] and [else]

2) The Alt frame need to explicitly hook to an existing lifeline typically by extension.  From the naming of the Alt frame name, you appear to be expanding the Validate message.  This seems wrong to me.  If you were trying to model how the SecurityService handles the validation of the supplied user, then you might consider using a subordinate sequence diagram interposed between the Entry of the Validate message and the FetchUserEntity message (along the lines of the Figure 11 in the IBM article).  By the way, this would have the effect of encapsulating the downstream processing in a subordinate diagram.  (As a data person, I often see very complex sequence diagrams that attempt to show total interactions rather than the correctly encapsulated interactions one would expect from OO based designs - this would imply that the designers aren't actually thinking in OO terms)

3) The Alt guards are typically expressed in terms of a previously acquired data property.  You show the returns as guarded via [UserEntity]  - these aren't valid guards (as far as I can see - there is no condition).

HTH,
Paolo

[jyoung]

Hi Paolo,

Thanks for the explaination. I am web developer and pretty decent and use case and class / database diagrams but this sequence stuff is a bit challenging for me.

It seems like the subordinate diagrams are the way to go and I will have to see about implementing them in this case.

Thanks a ton for the info.

Joe

[sargasso]

Hi Joe,

Here's a hint as you say you are new to UML.

Print your sequence diagram, cover everything up apart from the user and the login page.  Now try and model the interactions between these two only.   When you are happy then move rightwards across the diagram showing only two objects at a time (note they may not be adjacent!)  

Now maybe one object works with more than one other in order to complete its task,  that's fine just uncover all three etc.

The trick is to never uncover  any objects that do not interact directly while you are sorting out the flows.   So for instance, your SecurityService can not "see" your UserEntity, it only interacts with it indiretly through your DataAdapter.  While this may sound trivial when working with an obvious flow but when you get into more complex flows  ....


hth
bruce