SQL UPDATE Capability

[cincykid]

I think it would be helpful if the tool provided a method for selected mass update i.e. element attributes modified as the results of action taken by/within a project.

To wit, during an incremental lifecycle phase, requirements change status and phase by virtue of decisions taken (work completed).  Assuming a large project, requirements (business, functional, non-functional) would change status and phase....from proposed to approved and from definition to build, respectively.  Since I already have a SQL editor, wouldn't it make sense to provide a capability to use the SQL UPDATE procedure to first select and then update the requirements (assuming the correct SQL parameters).

This capability seems to make sense and could perhaps be supported in the search capability as opposed to native SQL.  Please give this some thought - as a productivity enhancement for many user roles for the tool - especially business analysts and systems analysts.

[Geert Bellekens]

I vote for the mass update feature, but against your proposed implementation using SQL.
There should be a better (ie less dangerous) way to perform mass updates. I shiver by the thought that my users start launching update statements on the model. :-/

[Dermot]

I suggest you look at this help page for Package based updates to these fields:
http://www.sparxsystems.com/uml_tool_guide/project_management/updatepkgstatus.html

[Thomas Mercer-Hursh]

Built-in tool based update is naturally preferable since it is presumably safe and structured for the likely purpose.  If you are daring, though, there is nothing to keep you from using SQL to update the model ... everything is just a value in a table in the end.  I build models from scratch and do ex-EA analysis on them, so no reason why you can't puzzle out some mass updates ... as long as you don't mind working with limited documentation.  I.e., take lots of backups.

[cincykid]

Thomas,

Thanks for the input.  So looking at the limited documentation, if a field is restricted to read only, an update SQL query probably won't function...correct?  I'm guessing there are some overrides available to administrator roles, yes?

Thanks Dermont.  My challenge is the selective update.  During the course of a project not all requirement elements will change status i.e. some will move from proposed to approved while others may take on the status of deferred or rejected.  If I require selective update, does your proposal respond to that scenario?

Geert.  I agree that to err on the side of preserving the model integrity is appropriate.  So I too would advocate a less risky method to provide the update capability....but in a pinch, I gotta get some work done.  My guess is that update SQL queries may be restricted by role.  Thoughts?

Thank you all for the input. [smiley=beer.gif]

cincykid

[Dermot]

If you are performing selective element updates then it may be best to look at using the: View | Element List - this allows quick access to each elements status in one view.

[cincykid]

Dermot,

Thanks for the comment.  Does this method provide mass update/status change or do I still have to open each element (requirement in this scenario) and make the change?  I'm looking for a class action as opposed to many individual actions to obtain the results.

Again I feel strongly that since this product is built on top of a relational database, these types of actions (selective mass updates, modifications and changes) should be accessible to super users or high end, properly trained users.  I'm OK with a capability through a UI, but it needs to be "selective", similar to the capability currently in the search window.  Let me search and then selectively update the search results.

I understand the balance between functionality and potential risks caused by unmanaged change.  Please accept this input as it is intended....a recommendation/suggestion from a user.

  

[Thomas Mercer-Hursh]

As near as I can tell, if you get in there and muck around in SQL, then you have all of the power and danger of complete access to everything.  

What I did was to make a series of queries to notice what changed around a manual change and then replicated that in SQL (or, actually ABL in my case since I was using an OpenEdge database as a repository).  There are some clues in the class model, but careful attention to actual experiments is advised, as is lots of backups and checking.