Author Topic: OpaqueBehavior (Read 11818 times)

Thomas Mercer-Hursh · « **on:** December 03, 2011, 06:00:29 am »

I am having a discussion in which the recommendation is that I base a stereotype in a profile I have on OpaqueBehavior, but Opaque behavior seems to not exist in 9.1 (909).

Thoughts?

Thomas Mercer-Hursh · « **Reply #1 on:** December 08, 2011, 09:38:24 am »

Does this mean no one here has heard of OpaqueBehavior either?

qwerty · « **Reply #2 on:** December 08, 2011, 07:14:34 pm »

No. Not that term. Sounds like what we have been taught as Information Hiding. Or what is called now Strategy Pattern.

q.

Thomas Mercer-Hursh · « **Reply #3 on:** December 09, 2011, 03:20:53 am »

Supposedly, it is in the UML spec and is derived from Class and is a component of behavior so that one can use it instead of Component in diagramming a legacy, especially non-OO system, and more easily connect it to Activity diagrams and the like. But, I see very little on it.

qwerty · « **Reply #4 on:** December 09, 2011, 08:46:04 am »

Quote

OpaqueBehavior is introduced for implementation-specific behavior or for use as a place-holder before one of the other behaviors is chosen.

from Superstructures.

So why not assign an abstract class to represent that behaviour?

q.

Thomas Mercer-Hursh · « **Reply #5 on:** December 09, 2011, 08:55:04 am »

On the forum where it arose, it was suggested that I use it as the base for my own stereotypes which I am presently using to model legacy, non-OO code. I questioned whether I could just add appropriate tags to my stereotypes, which are based on Component and Part currently, and it was observed that I might not get all the desired behavior that way, notably the link to Activity diagrams.

Geert Bellekens · « **Reply #6 on:** December 09, 2011, 05:20:50 pm »

Thomas,

I think EA has implemented OpaqueBehavior not as a separate entity, but as part of other elements like Operation.
See the behavior tab of Operation.

That might be the reason why you can't find it when creating your profile.

Geert

Thomas Mercer-Hursh · « **Reply #7 on:** December 10, 2011, 03:27:41 am »

So, what does this imply for construction of the stereotypes?

Let me talk about one small piece and see if that gives anyone an idea. In the legacy code, I have Program (a source code piece which will become a Compile Unit), Include (a source code piece which gets included in a program during compile, CompileUnit (the executable), and InternalProcedure (a block inside a Program which can be run from within the Program or, in some usages, the CompileUnit is run persistently and one can execute the InternalProcedure directly from another CompileUnit much like one would a method of a Class that one had instantiated).

One approach is to base Program on Class and make InternalProcedure correspond to a method. The limitation of that approach is that one cannot make links between methods and Tables or other Programs or other methods/InternalProcedures. We wanted to capture that level of detail, particularly since IPs are sometimes used in libraries which aren't all that coherent and they are natural candidate for restructuring in different units.

So, the first cut of this used Component for both Program, Include, and InternalProcedure so that we could make links to Tables and other Programs or InternalProcecedures. We create a "detail" link to/from the IP and a "summary" link from the enclosing Program and CompileUnit. I was going to look whether Part might be better for some of these before I started questioning whether I should be looking at Class.

I *think* the suggestion for OpaqueBehavior was to use it for both the Program and InternalProcedure.

qwerty · « **Reply #8 on:** December 10, 2011, 03:53:08 am »

I think you're not right when you say that you can't make links between methods. EA can do that. Connect two classes. Right click the connector next to one class. Choose Link to Element Feature, then Operation. You now can make a visible connection to one operation. Repeat at the other side. And you're done.

q.

Thomas Mercer-Hursh · « **Reply #9 on:** December 10, 2011, 04:26:33 am »

Well, definitely worth exploring. Do you happen to know if that is something that has changed? The original version of this profile was from 2007.

Thomas Mercer-Hursh · « **Reply #10 on:** December 12, 2011, 09:36:49 am »

One difficulty that I see with this is that it does not appear that I can apply stereotypes to a method... or at least I don't understand how I would. E.g., as described before, I might have a Program containing zero or more InternalProcedures. I can map the InternalProcedures to methods, but I can't assign them the stereotype which I am now using of IPPrivate and IPPublic (according to whether they are publicly accessed). As methods, I could, of course, cut this down to 1 and use the scope of the operation for that, but I need, for example to distinguish between InternalProcedure and Function.

But, while I don't see any way to define stereotypes for methods in Settings=>UML Types, I see that if I create a class and define an operation, there is actually a list of stereotypes there. Where does one edit that list? There is an ellipsis button to the right of it, but nothing happens if I click it.

Now on 9.2, btw.

Thomas Mercer-Hursh · « **Reply #11 on:** December 12, 2011, 09:48:45 am »

BTW, qwerty, you are quite right about the link to element feature. Works a treat.

Thomas Mercer-Hursh · « **Reply #12 on:** December 12, 2011, 11:39:47 am »

qwerty, I may have been happy too quickly. While I can make the *diagram* show links to the individual operations, these don't show in any of the property sheets that I see. Instead, the links appear to be to the class. I am sure that somewhere in there is obviously stored information about what operation is linked to, but I am wondering if this is just in the diagram or what. I think the utility would be much less if I couldn't query the tables and find this.

E.g., we have a piece of automation such that one can start from one element one has dragged on to a diagram and have it follow links of specified types for a specified distance and combine all elements that are reached in the diagram.

qwerty · « **Reply #13 on:** December 12, 2011, 09:47:54 pm »

Hi Thomas,
a lot of additional information. I'll try to pick them up.

Quote

Do you happen to know if that is something that has changed?

Sorry, but no...

Quote

I don't see any way to define stereotypes for methods

Well, I see it. Choose the base class operation, I guess.

Quote

these don't show in any of the property sheets

True, unfortunately. This is a property which is only stored in one of the attributes of a relation which is available via SQL only. I can't recall the exact attribute (it was somewhere in a Style) but can look up if you need it.

q.

Thomas Mercer-Hursh · « **Reply #14 on:** December 13, 2011, 04:30:09 am »

You're right, I see that one can define a stereotype for an operation, so that removes that issue.

Not being able to see it, though, is a problem. Can automation see it, so that one can at least do the kind of diagram builder I described?

Run into another hitch. In the original set, if the IP in one program ran the IP in another class, I connected those with a link of type ControlFlow with a stereotype of IPRun. As a class diagram, EA won't seem to let me change the type to ControlFlow, saying it is not UML compliant.

Sparx Systems Forum

News: