Need help for a sequence diagram for validation

[Ivan Debono]

Hi all,

I'm new to UML so I'm still learning about the different diagrams and elements. We have an existing application and I would like to draw a sequence diagram which shows what happens when the user wants to save a record in the db.

These are the steps which take place:

1. User calls the Save method
2. The Save method calls CheckAndShowMessage which validates empty mandatory fields. If the method fails, a message is shown save is ended.
3. If all mandatory fields are not empty, the app makes a Post request to the Web Api layer. This layer simply convert the DTO received from the client and maps it to a domain model. This model is then pass to the Save method of the service layer.
4. The Save method in turn calls a Validate method which validates the model according to business logic. If the validate method fails, an exception is thrown back to app (through the Web Api layer).
5. If validation succeeds, the model is passed to the Save method of the Data Access Layer, which uses Entity Framework to commit the model to the db.
6. Before actually committing, Entity Framework performs another validation of the model. If validation fails, an exception is thrown. If validation succeeds, EF tries to commit the changes to the db.
7. The db might throw an exception if the commit failed, or success if the commit succeeds.
8. If commit succeeds the user gets the updated record (mapped back to DTO), or an exception (either from the business logic layer, EF or the database).

This is what I currently have.

I would like some guidelines on how I might proceed to show the validation steps above in the sequence diagram.

Thanks,
Ivan

[H S Lahman]

Responding to Debono...

> Hi all,
>
> I'm new to UML so I'm still learning about the different diagrams and
> elements. We have an existing application and I would like to draw a
> sequence diagram which shows what happens when the user wants to save
> a record in the db.

This screams of being a homework problem for a CompSci class. These
forums do not exist to do your homework for you; grinding through it is
part of the learning process. OTOH, you seem to have made a good faith
effort to solve it yourself (unless the diagram was given and the
problem is to fix it). So...

>
> These are the steps which take place:
>
> 1. User calls the Save method
> 2. The Save method calls CheckAndShowMessage which validates empty
> mandatory fields. If the method fails, a message is shown save is ended.

How is the error message shown? Wouldn't that be an interaction with the
WebAPI?

> 3. If all mandatory fields are not empty, the app makes a Post request
> to the Web Api layer. This layer simply convert the DTO received from
> the client and maps it to a domain model. This model is then pass to
> the Save method of the service layer.

What client? What DTO? I don't see a DTO argument being passed to/from
anybody.

At this ultra high level of abstraction I don't have problem with the
recursive message, but you might think about using the same trick you
used with CheckandShowMessage to indicate a different process within
WebAPI does this processing and that process would send the Save to the
BuisnessLogicLayer.

> 4. The Save method in turn calls a Validate method which validates the
> model according to business logic. If the validate method fails, an
> exception is thrown back to app (through the Web Api layer).

Is that the line at the bottom back to WebAPI? If so, is there some
other message that announces all went well?

> 5. If validation succeeds, the model is passed to the Save method of
> the Data Access Layer, which uses Entity Framework to commit the model
> to the db.

I don't see any of this on your diagram.

> 6. Before actually committing, Entity Framework performs another
> validation of the model. If validation fails, an exception is thrown.
> If validation succeeds, EF tries to commit the changes to the db.

The failure is presumably announced by WebAPI, which requires a message
to WebAPI.

If the validation succeeds, you need an interaction with a DB entity.

> 7. The db might throw an exception if the commit failed, or success if
> the commit succeeds.

That is presumably announced via WebAPI, so you need an interaction
message for that.

> 8. If commit succeeds the user gets the updated record (mapped back to
> DTO), or an exception (either from the business logic layer, EF or the
> database).

I am confused by what a 'user' is. If it is a person, wouldn't that just
be a display via WebAPI? If it is other software, then you need a
message with the updated record as an argument going back User.

I don't really understand what the 'or' clause is about. Aren't those
exceptions already handled by the previous processing? IOW, they are
manifested in error messages to the WebAPI as they are detected and the
WebAPI displays the appropriate message.

I also believe you need to think about how to indicate the application
completes. For exceptions it seems to shut down after displaying a
massage. If so, there is a problem with that. The application can't
simply close before the User reads the message. IOW, the user needs to
acknowledge the message before the application can close. You have a
similar issue for a the success of the DB store. The User has to look at
the record. In addition, there are probably other things the user might
want to do, so the application wouldn't terminate as it seems to do for
an exception. Thus there might be separate processes in App that handle
different kinds of shutdowns and they need to be invoked by a message
from somebody.

--
A man is drinking beer on his porch with his wife.
He: I love you.
She: Is that you or the beer talking?
He: It's me talking to the beer.

Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
-- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink.
Descartes said, "I think not," and disappeared.

Entropy isn't what it used to be.
-- mwalshe89

Life is an accident of infinitesimal probability.
Thus entropy acts to extinguish it with due dilligence.

Heisenberg, Godel, and Chomsky go in to a bar.
Heisenberg: Clearly this is a joke but how do we tell if is is funny?
Godel: We can't know because we are inside the joke.
Chomsky: Of course it's funny. You are just telling it wrong.

A programmer's wife tells him, "Go to the store and get a loaf of bread.
If they have eggs, get a dozen."
The programmer returns with a dozen loaves of bread.

To do is to be (Descartes).
To be is to do (Sartre).
To be do be do (Sinatra)
-- Kurt Vonnegut

H. S. Lahman
H.la...@verizon.net
website: http://www.hslahman.com/
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972
novel: Hobsons' Dilemma, Inifinity Publishing, 2016

[Ivan Debono]

Thanks for the comments.

First of all this is not a homework problem!! I've been tasked to model some complex processes in our system. As I'm new to UML I've been reading about it and also checking uml-diagrams.org for guidelines. The original diagram I posted was very rudimentary as I was still getting to know the different elements that make up the sequence diagram.

I've redesigned the diagram and I hope I'm moving in the right direction.

Does this new diagram fit the sequence of steps required?

I have question regarding the alt combined fragment.On trying to save the model on Commit, one of 3 things can happen (save successful, DbEntityValidationException or DbUpdateException). Is this alt correct or should there be only one Commit message?

[H S Lahman]

Responding to Debono...

>
> Does this new diagram fit the sequence of steps required?

I think so, but there are a couple of things I don't understand yet.
What is the Client and how does it differ from the Service? Given that
you are destroying the API when done, this suggests you are modeling
some sort of client/server implementation. If so, that raises an issue
about whether this is an OOA model or an OOD model. (An OOA model should
be independent of platform implementation and the Client/Server paradigm
is a pure computing space paradigm.)

Another thing that is not clear to me is what the API is. Originally you
labeled it as WebAPI and I assumed it was a browser client the displayed
stuff to the User. Now I am wondering if the API is some sort of
software Facade around the DB processing while Client is now a web browser.

In any case, I think there may be some inconsistency in the interactions
of the software to the User. For example, what is the ValidationMessage?
Wouldn't that just be another dialog box in the Client, just like the
way exceptions are handled?

Finally, when the User is done, shouldn't there be a message to the
Client announcing that if you are going to destroy the API instance?

>
> I have question regarding the alt combined fragment.On trying to save
> the model on Commit, one of 3 things can happen (save successful,
> DbEntityValidationException or DbUpdateException). Is this alt correct
> or should there be only one Commit message?

I am confused about the labeling of the ALT segments. For example, the
first label says "no ValidationException", yet the only message back to
the API is a ValidationException. I assume the IHttpActionResult is as
generalized format that the Client parses to generate the appropriate
dialogs in the UI, right?

Finally you mention the DB commit above. If this is an OOD model and the
DB interaction employs a two-phase commit, you might want to show that
handshaking as well. OTOH, I suppose you could leave that up to the SQL
Server. If you do, though, I would re-label the last swimlane to show
that with a label like "DBSQLServer" to show that you are washing your
hands of everything on the other side of the SQL Server.

[Ivan Debono]

That is correct. I'm trying to model a client/server implementation where the server part is divided into various logical layers.

The Client is a windows desktop application. The API is a .Net WebApi application which receives requests from the client and fowards them to the service layer. The service layer is where all the business logic is located.

The first validation step is to validate that mandatory fields have at least values. This is what the client does and if validation fails, ValidationMessage is displayed in a dialog box. If validation succeeds, a new webrequest to the WebApi is created and message flow proceeds as in the diagram.

Once at the service layer, the object (model variable) is validated against a set of business rules (Validator timeline). If validation fails, a ValidationException is thrown. If validation succeeds, various validations occur in the "alt" fragment. The first guard is the condition that the business rule validation didn't throw an exception.

Finally, an IHttpActionResult is returned to the client. This might the updated object is success or the other kinds of exceptions that the client will parse and show the appropriate dialog boxes. The connection with the webrequest is closed and any resources destroyed.

Looking at the diagram, I think that the "alt" fragment should start at the client stage. Also, currently the Commit message is repeated 3 times (once per interaction operand). Is it possible to have one Commit message or is the fragment correct?

[Dan George]

Can fragments be guarded by operation names (implying that the operation happened at some prior time in some retained scope)? I'm not finding it.

[Dan George]

Perhaps you should use the "break" fragment type: http://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html#operator-break

I previously commented about the guard being an event instead of a condition (perhaps the moderator filtered that for me :). I'll take that back "no ValidationException()" is a boolean expression. However, the diagram shows that you intend ValidationException() to be called before entering the fragment. If it returns false, the fragment will execute (two out of three cases). I suspect that's not really what's happening. You could remedy that by using the break to show that an exception will send control back to a context that skips the processing presently shown as Alt.

Beware that modeling at the OOD level can blow up on you. Once you introduce one detail at a low level, the model becomes incomplete if you omit the rest of the details that exists at that level of abstraction. You can easily find yourself struggling to draw pictures when 3GPL text would be more concise (and executable!). YMMV.

On Monday, July 11, 2016 at 4:59:59 AM UTC-7, Ivan Debono wrote:

[H S Lahman]

Responding to moderator...

I didn't get de Keijn's original posting or Debono's most recent
message. I did get the responses by Reye and George. It occurs to me
that this may be related to the way messages are posted (e.g., de Keijn
and Debono post to the forum directly while the rest of us access via
email and the direct postings are not being echoed by email).