Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Oliver F.

Pages: 1 2 [3] 4
31
Bugs and Issues / Locks applied with previous builds
« on: August 26, 2009, 12:24:51 am »
Just filed this bug:

============
Several users here have reported that locks applied on elements with eg. build 844 can not be unlocked with build 848.
I can confirm that we have folders in the database locked with a 7.1 build which I can not unlock even as admin.

Lock a package with a 7.1 build, then open the same model with a 7.5 build (eg. 848) and try to unlock.
============

Oliver

32
Bugs and Issues / RTF documentation via JS automation locks up EA
« on: August 21, 2009, 05:52:31 pm »
The following bug has been reported by me:
==========================
Using the automation interface one can call the "RunReport" method from the project interface. When instead of a package ID an element ID is given EA displays the message "ADODBField[-2146825267] Either BOF or EOF is true, or the current record has been deleted. Requested operation requires a current record". After acknowledging the message twice EA starts creating a document from an unknown source and locks up in the process.
This does not occur when doing the same pŁeration manually by selecting the element and pressing F8.

Select an element and run the following JavaScript over it (adapt the template name if necessary):

function main()
{
      var pi = Repository.GetProjectInterface();
      var obj = Repository.GetTreeSelectedObject();
      
      print("running");
      
      if (obj!=null)
      {
            print("Name of object:" + obj.Name);
            print("Type of object:" + obj.Type);
            var elGUID=obj.ElementGUID;
            print ("GUID:"+obj.ElementGUID);
            pi.RunReport(obj.ElementGUID,"Use Case","c:\\temp\\uc.rtf");
      }      
}

main();
====================

Oliver

33
Bugs and Issues / Transformation of tagged value in foreign keys
« on: August 21, 2009, 01:28:26 am »
Something from the frustration department...
The transformation editor has lots of possibilities to write various transformation rules (as it is supposed to do, well).

The question is: Why does a DDL connector template of the following kind transform name and notes but no tagged values (excerpt from the foreign key section)?

Code: [Select]
   Column
    {
%if connectorDestRole != ""%
      name=%qt%%connectorDestRole%%qt%
%else%
      name=%qt%%CONVERT_NAME(connectorDestElemName, "Pascal Case","Camel Case")%ID%qt%
%endIf%
      type=%qt%%CONVERT_TYPE(genOptDefaultDatabase,"Integer")%%qt%
        notes="Hallo Source Column1"
        
        Tag
        {
            name="A"
            value="B"
        }
    }      
  }

The resulting foreign key has the "Hello Source Column1" note but not the tagged value "A:B". In EA I can add a tagged value to a foreign key attribute from the tagged value editor without problems.
From the templates I do not seem to be able to do so.
Well.

Oliver

34
Bugs and Issues / Build 846: eaapi.jar not upgraded
« on: July 15, 2009, 05:06:28 pm »
846 has just been released and the first issue is here †:o
The eaapi.jar with the JAVA API has obviously not been upgraded to build 846 as the DeleteBaseline method is missing from the Project class.
In the VisualBasic API the method is present.
And I was so happy when I found that method in the release notes  :-[

Oliver

35
Bugs and Issues / PIM2PSM transformation transforms wrong classifier
« on: July 15, 2009, 01:14:19 am »
Here is another (crtiical) bug I submitted:

===============
Several classifiers might be available with the same name in different hierarchies of the model.
Eg. take the following example:
Code: [Select]
class C1
{
     attribute1: package1.classifier;
}

class C2
{
   attribute2: package2.classifier;
}

The classifier in C1 is indeed another object than the classifier of C2- it just resides in different locations of the model but has the same name. The classifiers can be correctly chosen from the types dialog.
However during a transformation to a PSM (eg. by using the Java template) the classifiers are not identified correctly and, depending on the order in the model, the transformed attribute2 is transformed to have package1.classifier as type.
Propably a getbyname is applied and the first one found is chosen instead of correctly choosing the appropriate ClassifierID.
This is a highly critical bug as it completely spoils our transformation.
=========================

Oliver

36
Bugs and Issues / RTF creation standard and via automation differs
« on: June 26, 2009, 01:13:12 am »
While Dermot lately said that creating RTF reports from elements is not supported and the prefered way to do this is by choosing a package instead I noticed today that there are in fact two (!) different dialog variants accessible for RTF report creation when pressing F8. The difference is that the dialog starts with different root depending on the selection. The labeling is indeed "Root package" when selecting a package and "Root element" when selecting an element. Conclusion: There is support for both variants and indeed experience shows that reports on elements work flawlessly.
The drawback: The automation interface only allows for package report generation via the RunReport method.
Result: We are unable to have an automated extraction of single use cases unless we put each primary UC in its own package. So I would judge this to be a bug considering the fact that the RTF dialog allows support for both package and element.
A Sparx comment on this issue would be great.

Oliver

37
Bugs and Issues / Implementation details do not reflect target type
« on: May 04, 2009, 10:11:27 pm »
FYI, this is the latest bug I filed:

===========
The implementation details list does not reflect the "Set Target Type" filter when the checkmark "Show Implemented" is ticked.
Instead all elements are shown which have a Realization link regardless their type.


Steps to reproduce:

- Create some elements of different type (UseCase, Requirement, Change, etc.).
- Connect those by realize links
- Open "Project->Documentation->Implementation Details", the complete list is shown.
- Tick the "Show Implemented" checkbox
- Click on the "Set Target Types" button
- Restrict the target types to eg. UseCases by removing all elements ecxept the UseCase type from the left combo box.
- Close the dialog and press "Refresh List" on the Implementation details dialog -> Still all target type elements are shown, not only UseCase types.
=========

Regards,

Oliver

38
Bugs and Issues / YARTFTB - Yet another RTF template bug in 7.5beta2
« on: March 10, 2009, 09:04:01 pm »
Just filed another RTF template editor bug for 7.5 beta2- list numbering is broken. Looks as if 7.5 beta2 is actually not the way to go when it comes to RTF template reporting.  I would like to go back to 7.1, unfortunately this requires to rebuild the templates from scratch...

========
- Create a new template
- Open the list level editor (Edit->Lists & Overrides-> Edit List level)
- Change the list level to 5, the number text shows "~1~.~2~.~3~.~4~."
- Change the list level to 6, the number text shows "~1~.~2~.~3~.~4~."
- Change the list level to 7, the number text shows "~1~.~2~.~3~.~4~."
- Change the number text of level 5 to "~1~.~2~.~3~.~4~.~5~"
- Close the editor and reopen to verify the settings, number text is ok.
- Close the dialog, save the template, exit the RTF template editor
- Reopen the template editor, open the liste level dialog and verify the list level 5. The number text shows "~1~.~2~.~3~.~4~."
- Repeat the same with an existing template. When opening the list level editor and selecting list elevel 5, everything is ok. After exiting and saving the template, the list level has changed to "~1~.~2~.~3~.~4~."
- Create a report from such a template -> All headings from Heading 5 on reflect the wrong numbering scheme.
================

Oliver

39
Bugs and Issues / XSD generation and reference connectors
« on: March 27, 2009, 11:27:59 pm »
Filed the †following bug:

=============================================
When creating XSD schema files connectors which are defined with a
"Reference"containment instead of "Value" are always treated as a
composite relation.
Expectation is that such a relation is created as a reference tag .
The online help shows the following style to be created:
<xs:element ref="Account"/>
This is not accomplishable without changing tagged values for each
source connector. Instead the full object is always included:
<xs:element name="Account" .../>

Reproduced with build 834 up to 842.


Steps to Reproduce: †

Create a class diagram with classes and aggregations between those.
Set the connector containment of some to "Reference" and some to
"value".
Creating the XSD from those does not make a difference.

===================================

Addendum: It does not matter whether an aggregation. association or composite it used.

Oliver

40
Bugs and Issues / Solved: Diagram elements are not included in RTF
« on: March 18, 2009, 03:27:44 am »
FYI:
With build 842 diagram elements are no longer included in reports even if the checkbox "Include all diagram elements in report" is checked and the templates have the appropriate sections.
This worked with build 834 but does not with build 842 any longer and can be easily reproduced by creating corresponding reports †of the same data with the same templates with 7.1 and 7.5beta.

Reported to Sparx.

Addendum:
In case somebody feels offended that I am posting †bugs I have reported, this serves several purposes.
I feel it is important to emphasize that 7.5beta is a beta version which has flaws. People using it should be aware where the problems are when applying it in productive scenarios. This helps also Sparx and prevents from unnecessary complaints.
And, of course, demonstrating that issues are resolved by Sparx as I will (hopefully) update this list .

This has nothing to do with whatever judgements about some low quality this might imply.
I am almost certain Sparx will resolve those issues quick and responsive and in fact I am getting used to it †:P

Oliver

Update: Rephrased as the titel and description were misleading
Update2: Could not be reproduced, see statement below. Who knows what happened when we had that issue first.

41
Bugs and Issues / SOLVED: 7.5: Beware of modifying RTF templates
« on: March 06, 2009, 10:58:11 pm »
Hi all.

This is a warning for all beta testers of 7.5 beta2.
If you are modifying RTF templates in 7.5 they will no longer work in 7.1, instead they will lead to a "unexpected end of file" error when creating reports from it. Opening such a template in 7.1 with the RTF editor crashes EA.

Sparx is aware of this issue, if they can reproduce it, a fix will follow.

Regards,

Oliver

Update: See my post below for fixes.

42
Bugs and Issues / RTF templates and tables bug report
« on: February 25, 2009, 03:38:32 am »
FYI, after fiddling a few hours with the RTF templates again, I filed the following bug report:

========
Actually the handling of tables inside sections is not only inconsistent, it furthermore breaks a document structure:

-Putting a table in an element scenario section below the scenario notes and scenario types leads (if applied to an element with 4 scenarios) to 4 tables in the RTF document but only one scenario description.

- If a table is placed directly below a diagram section the diagram is placed into the table header.

- A table with more than one line in a diagram section reproducably breaks the document structure if a Diagram.DiagramImage element is included.
=========

Oliver

43
Bugs and Issues / RTF numeration issues sorted out
« on: February 19, 2009, 01:41:00 am »
Yesterday I took the time to sort out the numeration issue several people (including myself) encountered and came to the following conclusion which might be helpful for others, too...

Basically there is not that much freedom in defining numeration hierarchies as one would expect. The numeration depth is not only defined by the place an object has in the model tree but, and here comes the surprising part, from the element section itself as levels are automatically adjusted.

Meaning:
- Package is the first hierarchy level 1.
- Package elements are adjusted by 2 levels (eg 1.1)
- Package element requirements are adjusted by three levels (eg. 1.1.1)
- Package diagrams should be adjusted by this logic by 2 levels (1.1) however they appear to have been adjusted by three levels also (1.1.1). Wonder whether this is a bug.
- Elements are adjusted by 2 levels (eg 1.1)
- Element constraints, scenarios and requirements always increase the level of depth by two (when Element is H1, its constraint is adjusted to H3).
- Sections below elements are adjusted by the corresponding level, except diagrams for which the same applies as for package diagrams.
- to be continued


As a result it is advisable to give all template elements the same hierarchy level (eg. Heading 1) as the RTF generator automatically adjusts levels per sections (except diagrams as it seems ...) unless you explicitely want to shift the levels.

Child packages and child elements are adjusted accordingly.

Online help and RTF white paper seem to suggest that eg. a package is H1, its elements should have H2, etc. but according to my experience this would produce a result of heading 1 for the package and heading 3 for the package element after adjustment. This occurs at least with user defined numbering.

Of course one can switch off level adjustment but in this case everything has the same level which does not look good also.

I hope this helps further for those who encountered this, too.

Oliver

44
Bugs and Issues / Component shape scripts - working or not ?
« on: January 08, 2009, 03:47:19 am »
Maybe it is just me, but I am having a hard time to make my shape script work on stereotyped components and interfaces.

Results when applied on usecase types are very good, however on components and interfaces it seems to be a no-go.

Before I file that bug - can someone please try out the following shape script (including decorations) on a stereotyped component just to see whether it works in general or not ? I do not even get blue and red rectangles to see.

Code: [Select]

shape main
{
      setFillColor(0,0,255);
      rectangle(20,20,100,100);      
}

decoration linkeddocument
{
      setFillColor(255,0,0);
      rectangle(0,0,100,100);
       †       
      /*if (hasproperty("haslinkeddocument","true"))
      {
       † image("document.png",10,10,70,90);
      }*/
}

Thanks in advance.

Oliver

45
Bugs and Issues / UML patterns and MDG technology
« on: October 23, 2008, 03:18:11 am »
Lately I came across the idea of using patterns to provide architects with  ready to use component structures (meaning a component with parts, ports and provided interfaces).
That worked including importing the pattern in the resource view.
The next step caused some head scratching until now because I have not found an answer to the question:

Why can I include a pattern in a MDG technology (there is even a dialog to select it at creation time and it appears in the XML) but it never gets automatically imported with the MDG technology ?
Do I really have to manually deploy it for every developer in question ?

Besides that trying to merge the pattern with an existing component  (by moving it onto a component element and changing "create" to "merge")  immediately grays out the ok button.

That looks rather suspicious to me.

Comments are welcome.

Oliver

Pages: 1 2 [3] 4