I wouldn't say anything is designed for you to do this as we have never
considered the requirement. So getting it to work without changing ArgoUML
itself will require a little experimentation on your behalf.
You could override FigClass with your own custom version that overrides
createCompartments.
createCompartments is in FigCompartmentBox and currently looks as below.
protected void createCompartments() {
Object owner = getOwner();
if (Model.getUmlFactory().isContainmentValid(
Model.getMetaTypes().getAttribute(),
getOwner())) {
FigCompartment fc = new FigAttributesCompartment(
owner, DEFAULT_COMPARTMENT_BOUNDS, getSettings());
addFig(fc);
}
if (Model.getUmlFactory().isContainmentValid(
Model.getMetaTypes().getEnumerationLiteral(),
getOwner())) {
FigCompartment fc = new FigEnumLiteralsCompartment(
owner, DEFAULT_COMPARTMENT_BOUNDS, getSettings());
addFig(fc);
}
if (Model.getUmlFactory().isContainmentValid(
Model.getMetaTypes().getOperation(),
getOwner())) {
FigCompartment fc = new FigOperationsCompartment(
owner, DEFAULT_COMPARTMENT_BOUNDS, getSettings());
addFig(fc);
}
}
The code above assumes that everything that extends it wants just one
compartment of each valid type as it would be for standard UML.
You could try something like this in your own class overriding FigClass
protected void createCompartments() {
Object owner = getOwner();
if (Model.getUmlFactory().isContainmentValid(
Model.getMetaTypes().getAttribute(),
getOwner())) {
FigCompartment fc = new MyFigAttributesCompartmentType1(
owner, DEFAULT_COMPARTMENT_BOUNDS, getSettings());
addFig(fc);
FigCompartment fc = new MyFigAttributesCompartmentType2(
owner, DEFAULT_COMPARTMENT_BOUNDS, getSettings());
addFig(fc);
FigCompartment fc = new MyFigAttributesCompartmentType3(
owner, DEFAULT_COMPARTMENT_BOUNDS, getSettings());
addFig(fc);
}
if (Model.getUmlFactory().isContainmentValid(
Model.getMetaTypes().getEnumerationLiteral(),
getOwner())) {
FigCompartment fc = new FigEnumLiteralsCompartment(
owner, DEFAULT_COMPARTMENT_BOUNDS, getSettings());
addFig(fc);
}
if (Model.getUmlFactory().isContainmentValid(
Model.getMetaTypes().getOperation(),
getOwner())) {
FigCompartment fc = new FigOperationsCompartment(
owner, DEFAULT_COMPARTMENT_BOUNDS, getSettings());
addFig(fc);
}
}
There may be other ways we might be able to resolve this by changing
ArgoUML. If you have no luck with any other solution and want to try
supplying a patch then go ahead.
My suggestion would be to add a static method to FigCompartmentBox that
allows to register some factory class. You can then register your own
factory class in the startup of your module.
FigCompartmentBox can then have its createCompartments method changed
something like this.
protected void createCompartments() {
if (compartmentBuilder != null) {
Array<FigCompartment> compartments =
compartmentBuilder.createCompartments();
for (FigCompartment fc : compartments) {
addFig(fc);
}
} else {
... code here as existed before
}
}
On 5 September 2012 02:27, Ibrahim Beicker <ibrabeic...@gmail.com> wrote:
> Thanks for your reply mr Tarling
>
> I'd already implemented your solution when I discovered that this doesn't
> satisfy the objective of the project. I have to create a new button, and
> this button has to create a block diagram, as in it has to start with 8
> compartments. Is there any way of adding more than one attribute
> compartment to a FigClass and chose in which compartment I can add one
> attribute? I tried to modify createCompartments() of FigCompartmentBox to
> add new attribute containers but they are just copies, what I add in one
> appears in the others
>
> I'm thinking about attributes because it has a nice property of having
> whatever name I want to give it. Those new compartments could just as well
> be strings but I think argo does not support adding new properties to a
> diagram and this would break a lot of things in the view layer
>
> Any advises?
>
>
>
>> You might consider if you can extend FigAttributeCompartment with some
>> specialist class of your own.
>> That could then order the attributes as you wish and add any separators
>> you might require between groups of attributes (maybe by grouping them by
>> stereotypes).
>>
>> On 26 August 2012 01:44, Ibrahim Beicker <ibrabeic...@gmail.com> wrote:
>> Thanks for your response
>> I actually don't need to create a new kind of attribute. My problem can
>> be solved by adding 6 containers to the class diagram, all of them
>> containing attributes, and choosing how many will appear by a property of
>> some sort. But as I've seen on the code, argouml requires every container
>> to be from a different type(Attribute, Operation, etc), so that's why I
>> mentioned creating new classes that are the same as the Attribute class. Am
>> I wrong in this assumption? Is it possible to add more containers and
>> having a Class diagram having 7 Attributes containers?
>> >To see how to create a new diagram and register it with ArgoUML see the
>> sequence diagram module -
>> http://argouml.tigris.org/svn/argouml/trunk/src/argouml-core-diagrams-sequence2
>> >
>> >You can use this to register a diagram but the only problem is you need
>> to specify a type which is one of the standard UML types. We may have to
>> consider adapting his to allow some ad-hoc type to be created with some
>> unique id for purposes such as your own.
>> >
>> > What do you mean by new types of attribute? Why do you need something
>> different if there is no different behaviour?
>> >
>> >You are right that you will always be restricted to UML model types. If
>> you want types then you need some way to create an attribute and
>> automatically apply some stereotype to it. Which stereotype you apply can
>> indicate your type.
>> >
>> >Is there some standards body that describes a Block Diagram?
>> >
>> >Regards
>> >
>> >Bob
>> On 6 August 2012 02:15, Ibrahim Beicker <ibrabeic...@gmail.com> wrote:
>> I have a project in which I need to add a new kind of diagram to argoUML,
>> the block diagram of aspect oriented systems. My idea is to replicate the
>> "Attribute" of UMLClass to use for the additional containers of the block
>> diagram. From what I could gather from the code I need to create an
>> "UMLBlock" class, analogous to UMLClass, a "FigBlock" analogous to
>> FigClass, create the definition of what a Block Diagram contains
>> in UmlFactoryMDRImpl and create 2-3 new kinds of Attributes. These new
>> kinds of attributes will have no special behavior and will be just like a
>> normal Attribute
>> This is where I ran into my problem, how do I create new kinds of
>> Attributes? The code for the Attribute interface says explicitly to not
>> implement or subclass it because "It is generated from a MOF metamodel and
>> automatically implemented by MDR". I have searched for this metamodel on
>> the code but with no success.
>> So how can I go about creating these new attributes? Also any guidelines
>> regarding creating new kinds of diagrams may be extremely helpful
>> Thanks
>
> Hello
>>
>>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=3003746
To unsubscribe from this discussion, e-mail:
[dev-unsubscr...@argouml.tigris.org].
To be allowed to post to the list contact the mailing list moderator, email:
[li...@tigris.org]
