Specification Language for method

[scs]

Hi,

I need a specification language for class method.  Method for querying and method for modification of the model.  What I can use for this?  OCL?  I have another alternative?

Thanks!

[thomaskilian]

Can't imagine what you want

[Bruno.Cossi]

Automation interface perhaps?  

[scs]

Explaining better...

I have some stages in the software process (analysis, project, implementation and test)

The stage of project I identify to the operations of system (methods) and the designer need to specify the behavior of these methods (in some formal language).  

Then, these methods will be implemented by the programmer based in the specification defined for the designer.

What I want, I am a formal language to specify the behavior of the methods. It would like to know if the OCL would be the best option.

Thanks!!!

[Bruno.Cossi]

Hi,

I understand now. Well, OCL is used to describe constraints and expressions and is not particularly well suited for describing the behaviour. It is declarative (it tells you what you need to have) as opposed to imperative (it does not tell you how to do whatever it is that you are doing).
I think that combination of UML diagrams with potentially an addition of pseudocode within the Behaviour tab on class operations should help.

Bruno

Explaining better...

I have some stages in the software process (analysis, project, implementation and test)

The stage of project I identify to the operations of system (methods) and the designer need to specify the behavior of these methods (in some formal language).  

Then, these methods will be implemented by the programmer based in the specification defined for the designer.

What I want, I am a formal language to specify the behavior of the methods. It would like to know if the OCL would be the best option.

Thanks!!!

[fwoolz]

Another possibility is to flesh out the method algorithm in an activity diagram or statechart.  I agree that OCL is not appropriate; in fact, the OCL spec for UML 2.0 makes this clear:

"OCL is a pure specification language; therefore, an OCL expression is guaranteed to be without side effect. When an OCL expression is evaluated, it simply returns a value. It cannot change anything in the model. This means that the state of the system will never change because of the evaluation of an OCL expression, even though an OCL expression can be used to specify a state change (e.g., in a post-condition).
OCL is not a programming language; therefore, it is not possible to write program logic or flow control in OCL. You cannot invoke processes or activate non-query operations within OCL. Because OCL is a modeling language in the first place, OCl expressions are not by definition directly executable." Section 7.1, UML 2.0 OCL Specification

OCL would, however, be appropriate for defining method parameter and return constraints, pre and post-conditions, invariants, etc.

FCW

[jdavid]

An approach that we use is to define complex methods in an activity diagram using activity, subactivity and actions. We then include code snipets (either actual code or psuedo code) in notes that lint to the associated activity, subactivity, or action

[jeshaw2]

This may sound stupid at first, but give it some thought...

What about writing a textual, class-level Use Case to describe the behaviour of the class with sub-use cases for each method?

[fwoolz]

Jim,

That'll work, but purists may quibble that methods should still be naught but a gleam in the developer's eye at the use case stage. I am of the opinion that use case use isn't a religious issue; developers and teams should do what works best. Having said that, I also think that developers need to watch out for letting details of the design get too far ahead of a good understanding of what the system is supposed to do.

Cheers,
Fred Woolsey

[Bruno.Cossi]

Hi,

I am thinking about this and wondering - is not this nothing more but using the Use Case as a replacement for a note or behaviour fields at the class/attribute level?

Thanks,
Bruno

This may sound stupid at first, but give it some thought...

What about writing a textual, class-level Use Case to describe the behaviour of the class with sub-use cases for each method?

[jeshaw2]

My thoughts were as follows:

• I understand that Use Case, and indeed all of UML model development, does not model how user goals are achieved.  The focus is on what is achieved and how the interaction of participants work to achieve those goals. However, at some time the rubber must meet the road and guidance is needed by programmers not familiar with the problem domain as to how certain logic is to proceed.  How many of us know how to apply the "Rule of 7/8s" to calculate a loan's payoff balance, or how to determine the volume of a sphere?

• Use Case diagrams are usually accompanied by a formal text document.  Normally, they are managed formally under some type of revision control system. Perhaps we can extend its use to document all-gory-isims also?

• In his book Writing Effective Use Cases,  Alistair Cockburn speaks of Use Cases written at three levels:  User Goals, Summary Goals, and Subfunction.  Much of the Use Case discussion I see here is at the User Goal level and above.  Those are the diagrams and documents that are created at Use Case time.

• What we are talking about here is done, not at Use Case Time, but very close to Implementation Time where the model is realized in software.

• Application System components, classes and objects are things used at the subfunction level by software developers;  ergo, Use Cases can be developed at that level too.

• Many of the subheadings in a Use Case document also apply at the subfunction level too.  Only an addition of a new subheading type is needed to give software developers the guidance needed to be succesful.
  

• Why invent a new document structure when a little bit of pseudocode can be added to an existing tool, used at a different modeling time, targeted at a different type of actor; i.e.; the developer?
  

And that's tortured path of how I came to my idea above .  

[fwoolz]

Jim,

If I understand you correctly, you're talking about "drilling down" into the developed/developing design hierarchy and applying use cases as an explanatory/documentary tool at each level (or at least those where it makes sense). One object might be represented as an actor with respect to another object; then one method could be seen as an actor from the standpoint of another method, etc.

Looking at this from Fowler's "UML As Sketch" standpoint, I kinda think the idea is, well, cool. One man's system is another man's component, depending on the level of abstraction. I even have a monicker you can apply: "Recursive Object Oriented Method" or ROOM (oops...I think that acronym may already be spoken for). But seriously, why not apply the same modeling metaphors at each level in the design? Sounds like a plan to me.

Cheers,
Fred Woolsey