Messages

1

Suggestions and Requests / More Table View Columns

« on: January 17, 2014, 05:01:59 am »

If you have a package of requirements, and you view those requirements in the table view, a useful column would contain the element that the requirement is linked to through the various relationships.

Some examples would be:
DerivedFrom
SatisfiedBy

This could also go for any type of relationship that could exist in the model to any other type of element.

2

Suggestions and Requests / Tracking SysML Issues/Requests for EA

« on: December 27, 2013, 04:33:57 pm »

I have been compiling my issues in google docs and started to put together a site on google code to track these concerns. It is impossible for me to keep track of these otherwise. I believe the SysML plugin is a bit of a red-headed stepchild, so it isn't quite as mature or as integrated as the core UML portion. So many times you may not run into issues unless you are deep into SysML and applying it beyond the simple examples.

I doubt there is a huge SysML user base, but if anyone has potential SysML issues you run into comment here or in the spreadsheet and I'll add them. Many times these are usability or suggested functionality related when trying to replicate examples that are found in the popular SysML texts, but may be technically correct in regard to the spec.

Status: 14 Issues, 13 Open (Need to go back and see which I have submitted as bug reports or feature requests)

SysML Issue/Request Tracking for EA: https://docs.google.com/spreadsheet/ccc?key=0AgotitHXXmF5dGVpWlU3NFBLTlRRZm5CTjRIcW1QSFE&usp=drive_web#gid=0

Google Code Site (not sure if I'll use this or not): https://code.google.com/p/sparxeasysml/issues/list

3

Suggestions and Requests / Re: Registered bug report form

« on: December 27, 2013, 04:21:00 pm »

I found this does cause an issue with reporting bugs. If you happen to misread the captcha, you lose everything you just typed up. This happened to me, so I just said forget it at that point. Now I make sure to copy the body of the report before I submit.

There has got to be a better way to do this. Making it difficult to submit bugs means the product is going to suffer overall. And by not exposing the list of bug reports and responses seems like it would just end up causing more work. There will be duplicate or misunderstood bugs reported that someone at Sparx has to track down and respond to. Most users would love to be able to do this work for you. If it was more like google code, I think it would benefit both Sparx and the users.

Every other product I have used has some type of setup like this. If I was doing a formal tool selection I'd definitely ding the vendor maturity and outlook. If a major issue is found during use, how would you have insight into whether the issue will be stagnant forever or a fix is being released next week?

4

Suggestions and Requests / Hiding Port and Item Flow Stereotypes

« on: November 16, 2013, 08:31:42 am »

For Item Flows using blocks, the sterotype of block shows up which makes the item flows messy. Additionally, typed ports show the port type as part of the text.

There should be a way to hide the sterotype for the ports and item flows.

5

Suggestions and Requests / Re: Reverse Integration with DOORS

« on: November 07, 2013, 01:42:26 am »

Personally I would use DOORS just to extract requirements from Word documents sent in by the customer. Then just leave them as they are and continue with a different process in EA where those requirements were transferred. However, it is difficult as "responsible persons" tend to use their known tool chain (that is all that Rational stuff with following change management etc.) and setup a mess of an overall process.

The reason why I would do that is that once you have synthesized the use cases you will need to change requirements (not possible, wrong condition, alternatives), add new requirements (e.g. internal non-functional ones) and adapt use cases. This can not be done with DOORS but only in EA (or maybe in RSA? But how is actually still using that?).

q.

We have a complicated hierachy of requirements at each level on the government side. We essentially look like a customer to the higher level system of systems group. We take their spec, then we(our requirements team) derive our own system spec. So, what we'd like to do is mature that spec since it is recognized as our specification instead of creating a new spec. When that one is mature, we create an RFP and put it on contract. Then the contractor develops their own spec that traces up to our level, which traces up to the higher level. So yeah, it is more organizational pressures that push us down this road.

We are still working through the business process, but we'd like to have regular reviews with the requirements team to "accept" the changes/additions. A more automated process for managing the relationships between requirements (vice scripting it), and sending changes back to DOORS would be nice.

6

Suggestions and Requests / Re: Reverse Integration with DOORS

« on: November 06, 2013, 08:49:16 am »

I guess the answer is CSV :-/ You can export your requirements that way and import it into DOORS. However, if you use DOORS it does not make much sense to also capture requirements inside EA. Just place them in DOORS and synch back to EA.

q.

We thought this would suffice, but we are currently looking for 2-way solutions. The reason is just because of entrenched methods of currently working. There are requirements people who need DOORS, it is the adopted tool of choice and we continue to maintain the baseline requirements in that. However, we know we can create much better requirements by doing analysis in a tool like EA.

The issue comes where we start doing more analysis using SysML when we get the system of system level requirements for our system. We want to derive these requirements into a more detailed spec through functional analysis, or alter existing requirements. If only one-way syncing exists, there is risk that something will end up being missed.

It definitely would be an appreciated feature, among other things like creating the actual requirement relationships between requirements, activities, etc based on doors attributes. Currently, I believe it will only add tags.

7

Suggestions and Requests / Re: Set Default Line Style and Tree Routing

« on: September 27, 2013, 02:35:59 am »

Hi Helmut,

This add'in would be really useful! I also often use the orthogonal style, hence having the ability to set it by default would be great.

When do you think this plugin will be released on the community site?

Thanks
Guillaume

I put this script together and posted it here: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1377757601/2#2

I forgot to link to it from here in case others needed it. You can set it up to convert all lines on the current diagram to any of the line styles, using the built in scripting tools.

I used the scripting interface because I do not have admin rights to my work computer, so cannot use an add-in to change the style on the event of creating a new connector.

8

Suggestions and Requests / Re: Set Default Line Style and Tree Routing

« on: June 25, 2013, 07:28:24 am »

I know it’s not what you want, but an add-in will do what need quite easily. Check the OnPosNewConnector and set the attributes as you wish.

q.

Thanks, is this something that is doable via scripting or only by an add-in? I'm pretty limited on anything that requires modifying registry etc due to the computer environment I have to work in.

9

Suggestions and Requests / Set Default Line Style and Tree Routing

« on: June 22, 2013, 03:13:59 am »

I find that orthogonal square line style works the best for me, most of the time. However, I have to select every single line, right click, go to the menu, then select orthogonal square.

If there was a tree auto routing (versus pointing to the sides of the block) and/or I could have every line automatically be orthogonal square, this would save me a lot of time.

The auto route line style works ok, but sometimes it acts strangely around corners of blocks or compartments.

10

Suggestions and Requests / Re: SysML Activity Diagram to More Fully Meet the

« on: September 04, 2013, 09:48:23 am »

Actions are physically nested within the Activities that invoke them.

The relationship between them is defined in UML by a composition.

The referenced diagram is a link between two activities and not actions at all. If you look at Figure 11.13 you'll see a more concrete example. From that example (and 11.14 for the objects) it's clear to me that the relationships would need to be explicitly defined.

EA allows that kind of diagram to be created, but you'll need to explicitly set the activities to use rectangle notation and the quicklinker doesn't contain composition (but you can create it from the toolbox.)

Yeah, I misspoke.

The thing that was confusing for me was that I had to reproduce the functionality that works essentially like blocks and parts. So I ended up creating a script that I could run on a directory that:

• Goes through all the nested activities/actions.
• For each action, i get its classifier
• For each classifier look for existing associations to the composite element
• I look for an existing tag on any found connector
• I add a tag with the action's GUID to the connector if it doesn't exist
• I update the role with the action name

11

Suggestions and Requests / Re: SysML Activity Diagram to More Fully Meet the

« on: September 04, 2013, 12:10:31 am »

I'm struggling to find a way to handle the activity to action relationships manually or via scripting.

Would the process be to find each diagram that is composite for each activity.
Then find each action in that activity diagram.
Then find each Activity called by that action (can't find how to do this via scripting)
Then add the composite associations?

12

Suggestions and Requests / SysML Activity Diagram to More Fully Meet the Spec

« on: August 31, 2013, 02:50:31 am »

[size=12]Activity Decomposition in BDD[/size]
Currently there is no relationship between the Activities and the Actions that they invoke.

The SysML spec provides a description of how this should be depicted via a BDD: http://www.omg.org/spec/SysML/1.3/PDF/
See page 121/272 (labled page 99).
An action should have a Composition relationship to the Activity that invokes it, and an association relationship to an object node.

Allocation
When creating partitions in an activity diagram, you should be able to use specific instances instead of the generic classifier for the partition.

When dragging actions into the partitions, the partition should allocate the action to the block. (153/272)

An Activity shown in rectangle style should be able to show an allocatedto or allocatedfrom compartment. Same with a block, it should have allocatedto/allocatedfrom.

That way you can perform functional allocation to system structure and be able to depict that relationship within the element symbol. (152/272)

13

Suggestions and Requests / Re: Requirements Management Features

« on: August 23, 2013, 11:20:36 pm »

I've been working to get our team setup with using SysML and EA. I agree with many of the points, and have experienced them while trying to import our requirements tree via using JavaScript within EA.

In EA in general, the containment relationship is not automatic, and does not reflect the project browser. I submitted a feature request for this.

The tag for the text field does provide the memo value, but I think that there is a way around that. You have to set or read the tagged notes instead of the tagged value I believe.

Also, using the sysml extended requirement would allow you to show the verification method etc in element symbol.

14

General Board / Re: Development on parallel branches with EA

« on: March 01, 2014, 09:40:01 am »

I have a customer with the same issue.
Large shared model, with users working on some parts of it, but the changes don't get committed to the Shared model until the change is implemented, which may be many months later, once testing is complete.
BUT, all users need to see that the change MIGHT happen, so they can check if they are affected.
So I don't think baselining of the shared model would be practical: users need to see the 'trunk' and the 'branch'(s), so both EA baselines would need to be in the model at the same time, which isn't how baselines work ?

 We're proposing that the 'branch' elements are cloned from the trunk, and connected back to their trunk elements via an EA Connector. Then users of the trunk version can see that there are potential changes, by following the link to the branch.
 ..but all this has to be done manually: the initial  'clone' is hard, as the 'copy element' doesn't work reliably (issue reported for v11 Beta1), but that is as nothing compared to how hard it is to do a 'Merge'.

I seem to keep coming across this same issue in every client recently: they want to see the trunk and the in-progress branches, and this is the least-worst solution I can come up with.

I'm SURE someone has solved this in a more elegant way?

That is an interesting concept. It seems like it might be difficult to deal with in practice. You would be making the trunk aware of past and future changes through links.

A less complicated but less granular concept would be to manage your baseline as a standalone model. In that you create a concept of your "change packages" or whatever they would be called. This parent model is the model of the models. Use artifact concepts or something link that with some pointer to a branch that was created to develop the change.

It is the responsibility of some person (who should be identified in the identified baseline model) to merge any new baseline changes from the trunk into the potential change package. Then whenever you are ready to implement the change, you merge the branch back into the trunk.

15

General Board / Re: Enterprise Architect 11 Beta 1 (1101.4) - Rele

« on: February 15, 2014, 07:18:09 am »

Rothnic,

I can't comment much at the moment, but I want to give you what I can.

Lining up ports, destributing them, etc. Basically treat them just like any other element on the diagram, except they are confined to the edge of an element. If you have two part properties on an IBD, both with ports, and a connector. You would want to select each port and the connector at the same time, then align centers. So the connector and ports would be centered.

Non-resizeable diagram frames. I mean when you drag and drop a diagram from the project browser onto a diagram and select "Diagram Frame". For example, if you wanted to have an overview diagram that has large thumbnails of each diagram instead of just a link.

Connectors tied to IBDs. This one I put into a couple long posts with examples and verified 3 other similar modeling tools that do not behave this way. I think it is because this is more a UML focused tool. With SysML, you may design System, with Subsystem 1 and Subsystem 2. If you created an IBD for Subsystem 1, you would use the connectors between the part properties/ports. If I included Subsystem 1 in a special context called "Subsystem 1 Testing Environment", then showed the structural elements of Subsystem 1 within the Testing Environment IBD the connectors would not exist in that context. With SysML, if you wanted to change the internal connections, you would define a specialized version of Subsystem 1 (Subsystem 1 for Testing) and define the alternative connectivity.
http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1374248326 A sample model file and screenshots
http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1382661152/2#2 A follow up, but still don't think this is understood.

Visual Diff: Wow, thanks. Somehow missed this. Scoured the baseline compare of a package looking for something related to "diagram". The toolbar, compare options, right click menu just say compare to baseline. Seems like more intuitive behavior might be to show the full visual diff by default when double clicking on a diagram icon, below or above the diagram properties. Then allow to deselect as needed. Now I need to look into whether I can script exporting these diff diagrams out....