Author Topic: Examples of Modeling the Behavior of a Stored Proc  (Read 781 times)

JohnWSaundersIII

  • EA User
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Examples of Modeling the Behavior of a Stored Proc
« on: June 09, 2011, 03:53:09 am »
The topic http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1221462754/ made some suggestions about how to model the behavior of a stored procedure. Unfortunately, it doesn't answer my questions.

  • Considering a stored procedure that uses data from tables A, B, and C to insert rows into table D, how should this be modeled? Should I use a DataStore element for each table, and show object flows leading into an Action element?
  • Should there be an object flow out of that Action leading to a DataStore element for table D?
  • What kind of Action element should I use?
  • Similarly, what kinds of Action should I use for a DELETE or UPDATE operation?
  • If I don't want to model the details of how a stored procedure operates on the data, may I use a simple Activitiy with the same sorts of DataStore element going into and out of it?
  • Does anyone have any examples of this sort of modeling?
John Saunders

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Examples of Modeling the Behavior of a Stored
« Reply #1 on: June 09, 2011, 10:31:40 pm »
I don't know if this will help but I'll cast in a couple of nasturtiums that may spark (no pun intended) some further input.

A stored procedure is a behavior.  It is invoked by some external stimulus.  When it is, it acts on a specific set of attributes, to produce some predefined outcome.

To what classifier does this behavior belong? In other words, what species of being exhibits this behavior? Could be a table, could be a view, could be a dataset? I don't know, but I think it could any of them.

Do we need to know the classifier, or could it just be a behavior that belongs to the environment? I don't know.  Does it matter?  Do all behaviors in the model need instantiable classifiers?

(State machine modellers may start interjecting at any time.)

Beats me! It sounds like it's quacking but it doesn't look like a duck.



"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

JohnWSaundersIII

  • EA User
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: Examples of Modeling the Behavior of a Stored
« Reply #2 on: June 10, 2011, 02:26:45 am »
I haven't made any suggestion about which entity exhibits the behavior. It wasn't directly relevant to my question. If I had to guess, I would say that the database as a whole exhibits the behavior, since the database I'm using, SQL Server, does not support smaller scopes like a "package".
John Saunders

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 8371
  • Karma: +202/-25
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Examples of Modeling the Behavior of a Stored
« Reply #3 on: June 10, 2011, 03:49:00 pm »
John,

Here's what I think:
- The stored procedure is behavior
- UML has different diagrams to model behavior, you'll first need to choose one of them. Activity diagrams or Sequence diagrams seem applicable to me.
- If you choose Activity diagram, there are a number of subtypes of Action you can use to model the different steps in your behavior, think CreateObjectAction, DestroyObjectAction, ...
- Think about modelling the behavior of the stored proc in a functional (PIM) way, without getting too technical. Think on the lines of creating/updating/deleting entities rather then records in a table. The tables and stored proc are just a technical implementation of your functionally described model.

Geert

JohnWSaundersIII

  • EA User
  • **
  • Posts: 50
  • Karma: +0/-0
    • View Profile
Re: Examples of Modeling the Behavior of a Stored
« Reply #4 on: June 12, 2011, 12:52:58 pm »
Thanks,

I was planning, at least at first, to model at a fairly high level. For instance, I don't care much whether an INSERT or UPDATE is being performed; I'm more interested in the fact that a particular table is being changed. At some point, I might be interested in modeling which particular columns are being changed, and modeling where the data came from that changed them.

I eventually hope to be able to help answer questions like, "what could have caused this column to be NULL", but tracing back the code that updated the column, where the data came from that updated it, which code called that code, etc.
John Saunders