Can we represent details of operation in UML?

[mukesh]

Can we represent details/pseudocode of operations in UML?

    For e.g.

operation1()
{
         operation2();
}

         Can we represent such relationship in UML and which UML tool provides this facility?

[StefanPears]

AFAIK UML says nothing about the behaviour inside an operation. You can use any prosa, preudocode or programming language like Java or COBOL you like.

The call of an operation from another operation of the same class can be shown in a sequence diagram by using a self-message.

Stefan

[mukesh]

Its right that UML doesn't specify anything about the behaviour of the operation. We can write any comments/pseudocode in an anchor associated to it(this is generally done). If we write some pseudocode, most of the tools(I don't know any tool which does not) will associate this pseudcode to the concerned class rather than the specific operation, while storing the design in XMI format.

             Can you suggest me a tool, which operates upon operation level for such information.

Thanks a lot for your response.
Mukesh

[StefanPears]

I usually write prosa or C-like pseudocode into the notes of the property of the operation. Sometimes (pls don´t tell anybody  ) I add an activity diagram to the class which I name like acdOperation1 and which I use as a program flowchart.

Stefan

[Bruno.Cossi]

Hi,

in EA there is a tab called "Behaviour" for each operation, that might be a good place to enter the operation-specific behaviour details :-)

Hope this helps!
Bruno

Its right that UML doesn't specify anything about the behaviour of the operation. We can write any comments/pseudocode in an anchor associated to it(this is generally done). If we write some pseudocode, most of the tools(I don't know any tool which does not) will associate this pseudcode to the concerned class rather than the specific operation, while storing the design in XMI format.

              Can you suggest me a tool, which operates upon operation level for such information.

Thanks a lot for your response.
Mukesh

[Kevin G. Watson]

Hi'ya.... Isn't that what UML Action Semantics is about?  I'm new to UML and EA, but sure I saw something that looked like it was doing that in the documentation somewhere.... actions, input and output pins, data and control flows.  I thought it was the 'Analyst' bent of the user population, who handed over their models to coding folks (who can type quicker than draw) who sorta killed that.

How do I attach an Activity Diagram to an operation;  I cud then start to bemoan the lack of Activity Generation templates I hate typing - and would gain oodles of kudos with my manager (who could get rid of the coding phase in all my projects)

Stay tough
Kevin

[bwl21]

Hi'ya.... Isn't that what UML Action Semantics is about?  I'm new to UML and EA, but sure I saw something that looked like it was doing that in the documentation somewhere.... actions, input and output pins, data and control flows.  I thought it was the 'Analyst' bent of the user population, who handed over their models to coding folks (who can type quicker than draw) who sorta killed that.

How do I attach an Activity Diagram to an operation;  I cud then start to bemoan the lack of Activity Generation templates I hate typing - and would gain oodles of kudos with my manager (who could get rid of the coding phase in all my projects)

Stay tough
Kevin

I am facing exactly the same question. I guess I will open another thread with this question.

-b

[jeshaw2]

I really think y'all should look at the Object Constraint Language (OCL).  This allows more precise specification of what the behaviors should be without getting into how they are implemented.

There are good reasons to avoid specification of implementation details at the level of UML usage.

[bwl21]

I really think y'all should look at the Object Constraint Language (OCL).  This allows more precise specification of what the behaviors should be without getting into how they are implemented.

There are good reasons to avoid specification of implementation details at the level of UML usage.

no, it is not the matter to specify implementation details. It is rather a matter of showing the algorithm.

If it would be implementation details - this goes into the source code.

-bw

[jeshaw2]

It matters not if the algorithm is specified in a natural language, pseudo code, Java, C++, or machine language, an algorithm is a specification of how a computational process is to go forward.  

Consider a requirement to convert a temperature in Celsius to Fahrenheit. There are at least 3 algorithms available:  Evaluation of a math function, a conversion table lookup, and delegation to a web service.  Specification of one of these mandates how the conversion is to be done and not a specification of what the goal of the behavior is to be.

If a specific algorithm is made mandatory by your project sponsors, then I would suggest that the appropriate place for its documention is in the constraints section of the Requirements Specification document|diagram or in the textual version of the Use Case Document.

My $0.02 US

[sargasso]

That's all well and good for the requirements Jim.  But there is still a case for succinct transalation of a business level algorithm into a technical algorithm.

The example that springs to mind is Australia's GST (VAT) calculation...as compounded by cash rounding as we aint got  cents anymore.

There are at least   6.213*10^26 different algorithms for working out how to refund someone who has returned a $0.93 pint of milk to the supermarket after they purchased 2 pints.  The major differences lie in the order in which to apply  tax calcs and cash roundings across allocated pricings.  (or in the words of a very wise man - never confuse sales with inventory).

When the milk example is complexified into such products as financial fungibles - where the commodity can be subdivided into any number of different sub packages of any different size - there is a need to communicate to the implementation people the exact way and in what order the calcuation is to proceed.

If different products are calculated differently - and dont think that isn't possible - the algorithms must be associated with the specific object type.

Problems of this type have a characteristic - unless the correct algorithm is used the resultant system is not deterministic i.e. the outcomes specification alone does not give enough information to develop the system.

Consider a cheque clearing system.  The outcome depends entirely on the order in which the incoming transactions occur and on the order in which the business rules are applied.  One bank I know of here has a clearance regime of over 3000 business rules for corporate cheque accounts - the rule stack is applied as a sieve mechanism (txs only go through very few rules before being accepted or rejected) - but the sieves must be applied in a very specific and rigid order.

bruce

[thomaskilian]

Isn't that the place where Business Rules should come into play?

[jeshaw2]

That's all well and good for the requirements Jim.  But there is still a case for succinct transalation of a business level algorithm into a technical algorithm.

That may be true, but I don't think the complexity of the algorithm changes my position; in fact it reenforces it.  I wouldn't want to add that much complexity to a diagram designed to convey other concepts.

In your example, different algorithms yielded different results.  Perhaps the requirement can be restated with a constraint on the attrubutes of the result set.

Isn't that the place where Business Rules should come into play?

Well said Thomas!  And business rules are modeled as requirements and constraints...?

In the Requirements Model, I'd create a hyperlink to a text document that spells out the algorithm if that is required.

[Kevin G. Watson]

Hi'ya

An't analyst folks great ... attach a text doc to explain the action ...

We're only a little shop, so folks get to be Analyst, Designer and Implementor (Code typists, wot).

As a project proceeds through these loose phases, it would be good to be able to introduce 'the how' into the model.

I'm at a bit of a loss as to why you would strive to keep a model simple, thats not the same as providing a simple view.

My soul screams for 'Action Complete' models, there are lots of productivity benefits, to be gained; consistancy, completeness, one representation, all aid maintaining software systems.

Could we introduce a property on a operation that pointed to an activity diagram... some kinda addin to provide a context menu option.

I'm thinking then that, you would be able to execute the model before producing the implimentation.  

Stay tough
Kevin

[«Midnight»]

Kevin,

What about adding a tagged value to your operation? Works like a charm, and you can drill down to parameters, etc. if need be.

There's some maintenance involved when you move things around, but the overhead is similar to what's involved in other structural rearrangement of complex models.

This approach is also a good candidate for automation through add-ins or customization of scripts.

David