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.

Messages - DanG83616

Pages: [1] 2 3 ... 13
This might help you in the mean time:
1. Export to CSV
2. Use a spreadsheet to make the updates
3. Import from CSV

Make sure you export the GUIDs and check the "Preserve Hierarchy" box. DO NOT delete parent elements from the spreadsheet or you will lose the hierarchy. If you search on my other posts you'll see a little more detail.

You can also use a text editor to edit the CSV file for simple search and replace operations. I've found this techinque to be better than editing the xmi but have occasionally done that as well.


you should make a formal change request to Sparx and mention that you are training people to create multiple classes with the same name in models just for this purpose. That might get their attention. I shudder to think of trying to manage a model with a bunch of same-named classes in it. :-X

Don't schematic capture programs allow the same item to be broken up and shown in convenient places on a single diagram? If you drop a class onto a diagram twice, it still has the same name so it is obviously the same class. Since the diagram is just a visualization of the model I cannot come up with any rationale to limit the number of times one item can appear on a diagram. I vote "yes" for this feature because I have been forced to break up diagrams just to avoid spaghetti strands meandering through a single diagram.

Regarding making diagrams enjoy the rights of elements within the repository, why not create a classifier for that? You could create a classifier that has a tag for referencing a diagram. Along with the diagram tag you could add your other tags. For example, you could have a tag to identify filtering. A transform might then take the original diagram and apply the filtering to produce a specialized rendition. You would be modeling how you want to present your model.


Suggestions and Requests / Re: v8 - Diagram Filters need Connector Filters
« on: November 10, 2010, 06:08:10 pm »
I'm not sure I'd recommend using the filtering mechanism for version diffing. Could turn into a mess when just creating a new diagram for the future state would be pretty quick. Notes can be used to call attention to the differences in the diagram depicting future state. I have tried to do it with just one diagram and was dissatisfied. Filtering for that purpose would not have helped enough to avoid a new diagram.

I still support the feature as a means to elide certain aspects of a single design. Hmmm... not coming up with a likely use case. Everything I can think of involves also eliding an element which naturally hides the connector.


Suggestions and Requests / Re: v8 - Diagram Filters need Connector Filters
« on: November 10, 2010, 03:17:10 am »

Thanks for the bump.

Near the end there was discussion about how structured techniques failed in the past. I have been working on the idea that they failed due to inadequate specification technology.

Products implemented with software can be very much more complex  than products implemented with hardware. Software devices are not subject to constraints so concisely defined by the laws of physics (f=ma, v=ir, ...). The lack of constraints frees us to make really complex things. It is not that software makes things more complex; rather, it is that we can do more complex things with software.

The greater complexity requires greater ability to specify. We simply not up to the task with the tools and experience we had back in the 70's. When complexity exceeds ability to specify it we can use artists and craftsmen to do the building. They don't always get it right but often enough it is close enough and sometime some of them can actually get it right. Agile methodology is a really good way of getting the very most out of a artisan/craftsman workforce.

Improved ability to specify (describe that which does not exist such that it can be made to exist) improves productivity. The cost of attaining that ability and practicing it have to be economical compared to the artisan/craftsman method. Currently the artisan/craftsman method is economical for all but the most safety critical systems. Those  systems are the ones where close enough or occasionally right production is not economical.

I do not know what will change the economics. It might be that we discover new laws of physics that apply to software devices. Without the scientific discovery that occurred in the 19th century we would not have had the industrial revolution. Those latent laws might provide the constraints that we now unknowingly violate and build systems that fail. In the mean time, we can work on optimizing our ability to specify software more efficiently without them.

The UML and tools like EA improve specification efficiency. The UML provides the means to express aspects of software devices more concisely than we had back in the 70's. Tools like EA provide an economical way to organize and maintain those expressions. Standardizing the organization of them as in the IEEE standards would provide a baseline from which to start incremental improvement.

Having said all of that, I think the user community has to learn to utilize and improve the standards. I don't know that Sparx can do anything to specifically address Keven's suggestion.

Oh, and where is the EA wiki?


Suggestions and Requests / Re: UML for Forum
« on: October 12, 2010, 03:10:30 pm »
Good idea, Beginner. I've created Now I just need to put something in there next time I have a question.

I still think it would be cool to have something like a public project. You would need a Corp Ed to use it so it might actually pay for itself in user upgrades.


Suggestions and Requests / UML for Forum
« on: October 09, 2010, 02:03:10 am »
It is ironic that many times I want to use UML to describe my problems or suggest solutions to the forum but don't have a convenient way.

I wonder if it would be feasible for Sparx to host a repository (or repositories) for this purpose. It wouldn't have to be robust or secure. An inexperienced user (or a malicious one) could wipe out the repository. So what? Even with the occasional mishap I bet the community would benefit.

Even if that solution isn't feasible there must be some way.

Suggestions and Requests / Re: Update for SysML
« on: December 27, 2008, 05:09:56 am »
Took me a few clicks to figure it out but sure enough! "Select another Toolbox or Technology"->MDG Technology for SysML enables filtering on SysML types. Just added this commend to make it a little easier for others.

Still, seems like there are SysML improvements to be made.

Thanks for the help,

Suggestions and Requests / Update for SysML
« on: December 23, 2008, 04:32:09 pm »
The last mention of SysML in conjunction with a release is really old. I downloaded the trial and it doesn't quite match my reference: A Practical Guide to SysML; Friedenthal, Moore, and Steiner. For example, Friedenthal, et al, describes Part, Reference, and Value properties but EA seems to have only BlockProperty. Also, it looks like the plug-in was released prior to 9/2007 when v 1.0 of the language specificaiton was released.

I also noticed that displaying the diagrams as a list isn't well supported. If you try to filter the list you'll see that the pulldown doesn't contain SysML types (Block, PartProperty, etc.).

Any improvements to SysML support coming?


Suggestions and Requests / Re: Handling of nested controlled packages
« on: November 21, 2008, 02:24:25 am »
Oops. Sorry, I didn't see Juri's final post. He said what I was only thinking.

Suggestions and Requests / Re: Handling of nested controlled packages
« on: November 21, 2008, 02:21:43 am »
I cannot see how Sparx doesn't consider this a showstopper. I am now feeling very stupid for creating packages for our entire system only to find that it will be impossible to maintain.

Perhaps Sparx, or some enterprising user, can develop a plugin to check for unresoved links prior to check in.

Suggestions and Requests / Re: RealtimeUML Addin
« on: November 20, 2008, 02:31:31 am »
We have been interested in code gen from state machines as well. We created a pattern to allow the actions to be implemented in separate "business logic" classes. The idea was to avoid having to express action details in the state machine. That, in turn, avoids the issue of modifying generated code and the whole round-tripping mess.

Unfortunately, we have had to get creative with the Operation fields in order to make the diagrams show what we want. For example, we had to enter free-form test in the Action field in order to show the trigger for internal transiitons. E.g., Operation Name: anAction and Action: aTrigger so that the daigram shows "aTigger/anAction". This is not ideal but it is important to show the trigger in the diagram. Doing this also gets in the way of using already defined actions in the Action: pulldown. If anyone has an idea for improvement I'd be most grateful.

Of course, it would be nice if the dialog were "Internal Transition" rather than "Operation". It isn't completely obvious that an internal transition "is-a" operation. Futzing with the diagram rendering just lead us down this path. Using Operation assumes that the state is a class but we are using QuantumFrameworks (Miro Samek) and states are methods of a state machine class.

So, more than code generation, I would like better support for state machine specification that is state pattern implemetation agnostic.


Suggestions and Requests / Non-transition event processing
« on: August 01, 2008, 04:21:18 am »
I want to show events that should be processed in a state and show the effect without a tansition. Using a self-transition indicates that the exit and entry operations will be performed and that is not what I want. For now we are adding operations to the state using the name of the event as the Action, the name of the effect as the name of the operation and Event as the stereotype. For conditions, we use the action field to show the condition and stereotype as Condition. Is there a more straightforward way?


The DDS transform demo looks compelling but I think it could be made better. DDS provides a way to connect components so why not have a transfmoration that creates everything needed based on component or composite diagrams? The current support exposes a lot of details regarding DDS configuration and is a good view for that purpose. However, my real job is creating systems of components so I'd like a view that abstarcts the DDS details to just boards, components, traces and ports (domains, participants, topics, writers/readers). Transforming between the two views would be very nice!

I'm actually starting to do this on my own but I'd rather just buy it (for $1 US  ;)).


Pages: [1] 2 3 ... 13