Hi EA SysML mavens,
I create a BDD, and it has a block; call the block B1. I give B1 two ports.
I create an IBD diagram.
I drag the block B1 (from Project Browser) onto the IBD diagram. It appears with the two ports.
I later decide I need a 3rd port on B1. So I go back to the BDD diagram and add a 3rd port.
I then look at the IBD and expect that it now has 3 ports. it does not.
Question: Why does the IBD diagram now still have just 2 ports instead of 3 ports?
You need to show newly created port instances manually.
In the above picture Port1 was created with the instance if Class1. (Actually whether /Port1 is directly shown changes with the weather Down Under or how Sparx implements it per versions.) Anyhow, Port2 has been created after instantiation of Class1. So the Features window indicates that /Port2 is not visible. Just set the tick mark and the port will be shown.
Related
I'm new to Autosar.
I was asked to implement Autosar interface for hand written code, create RTE and ARXML files, and send Arxml file to other group.
I have two runnables in my code.
Let's say for example interface variables (inputs) X and Y, and we have output as Z:
here my code:
global X;
global Y;
global Z;
Runnable_Step()
{
Z = X + Y;
}
Runnable_Init()
{
X =0 ;
Y =0;
Z =0;
}
I guess, my question where and how to start?
we have Autosar DaVinci Developer and Autosar DaVinci configurator.
Your question is quite general in nature and can not be answered in a few lines. However, I try to give a general answer which may help other people to orient themselves in AUTOSAR development with Vector DaVinci.
Generally in DaVinci you have the following work split between tools:
DaVinci Developer is used for modeling Application Component(s), Interfaces, Data Types etc. You also can run the RTE generator for generating "Contract Phase" artifacts.
DaVinci Configurator is used for integrating/configuring the ECU (Electronic Controll Unit). In an Application Developer's scenario it is typically used for generating the RTE that will actually be built into the final image.
In practice, the transition between these two tools often is fluid: You enter some information in Configurator (for example signals in the CAN Stack), then switch over to Developer for mapping the signals to your component instance's ports, then switch back to Configurator in order to configure and generate the production RTE.
You should start with thinking about how the AUTOSAR model for your task will look like. This includes the following aspects:
Which Data Types will be used?
Which Interfaces will be used (SenderReceiverInterface, ClientServerInterface)
Which Software Components do you need? Add the required Port Prototypes, using the Port Interfaces you defined in the previous step
Which resources does you SW Component need from the RTE? You add these to the "Internal Behavior" of the Component. In particular, these are Runnable Entities, but there are also Read/Write dependencies to the ports that need to be considered.
Integrate your new Software Component into a top-level composition.
Creation/Editing of these elements is done in Developer. Based on the work done so far you should be able to generate the "contract phase" RTE header files and C-language implementation stubs. You then can proceed to implement your runnable entities by adding code to the provided stubs.
Next, you will probably need to switch over to Configurator in order to configure the ECU your application should run in. If your work is based on an existing ECU, you will just add to the existing model. If you do not have an ECU project yet, you need to create one and typically populate it with the communication aspects of the model. This can be done either by importing a communciation extract or a CANdb file (Vector's proprietary CAN configuration format).
Switching back to Developer, you may deploy your Software Component onto the ECU, and also map its ports to the signals known by the ECU.
Finally, return to Configurator, optionally configure Basic Software and generate the RTE. It may be a lengthy process to get all BSW modules and parameters right in order to pass the RTE generator's validation process.
Once you managed to generate the RTE, you start the build process, and off you go!
Be sure to consult the AUTOSAR documents at https://www.autosar.org/
i have to change the diagram type of a lot of diagrams within my Enterprise Architect model. The change can be made manually using following option (that works as expected):
Select diagram - Diagram - Advanced - Change Type...
As I have to change a lot of diagrams I have created a script which searches for all concerned diagrams and change the type automatically. I wrote already a lot of JScript EA scripts for changing some modeling elements. Unfortunately, this feature seems not be available over the scripting interface.
I have to change the "MetaType" of the the diagram object. But this is read-only (see http://www.sparxsystems.com/enterprise_architect_user_guide/12/automation_and_scripting/diagram2.html). Therefore, I got an error.
var currentDiagram as EA.Diagram
currentDiagram = theDiagram
currentDiagram.MetaType = MY_DIAGRAM_METATYPE // ERROR
In the next step I searched for appropriate functionalities in the Repository interface (http://www.sparxsystems.com/enterprise_architect_user_guide/12/automation_and_scripting/repository3.html) and in the project interface. But I found nothing appropiate.
I am using Enterprise Architect 12.0.1215 and I used JScript.
Has anyone already tried this by script?
Have I missed something?
Is there another approach to achieve the diagram type change by script?
Thanks in advance!
You have to do that in two steps (if you change to different MDG diagram types). E.g. to change a Class diagram to a BPMN2.0::BPEL you first change Diagram_Type from Logical to Analysis. Additionally you need to add MDGDgm=BPMN2.0::BPEL; to StyleEx. In case your old diagram is from another MDG you need to modify the existing MDGDgm attribute in StyleEx.
As Uffe noted, the diagram type in the API is r/o. So if you need to change that you would need to do something like
Repository.Execute("UPDATE t_diagram SET Diagram_Type='Analysis' WHERE Diagram_ID=<theId>")
where <theId> would be the correct diagram ID.
I have two similar (if not identical) node instances that are appearing differently in a deployment diagram (and anywhere else that I use them).
I may have done some odd things in the past while beating EA into submission.
But, now ... by pulling every lever I can imagine, I can't get them to appear the same (or behave the same). The one on the right is consistent with all the other nodes I have.
The colour is off and the "properties" (maybe they're tags?) showing in the body of the one on the left appear but I can't figure out where to edit / remove them.
I've tried:
Element ... Advanced ... Change type (Node --> Device and back to Node just to try and get it to 'forget' anything it's holding onto)
Remove & re-add stereotype to both the Node type (i.e. type from which instance was made) and the instance itself.
Creating a new instance from the same type, just to see what happens. It creates a node instance more like the one on the right.
Early on in developing this model, I created my own MDG technology. My guess is that the node on the left was created from a type in that MDG, which had some attributes available. It's conceivable to me that Sparx is hanging onto those attributes and not providing a way to edit because of the type was changed.
Any guidance on how to manipulate the under lying data (without creating a new node instance and replacing on all diagrams and re-configuring all relationships)?
Those are different elements. You see that the name (FQN) is different on both. Click each and issue Ctrl-G to locate them in the browser.
The green dot on top makes me think that you use your own MDG which puts the dot on <<SUSE>> stereotyped elements. So the MDG is likely what also makes them appear different depending on tagged values.
Regarding the Version and OS shown in the lower compartment of the left class: those are run states. You can edit them via Context/Features../Run State
For the colour of the element, I think what happened is this ... at some point, I selected (Element Context Menu) --> Appearance --> "Default Appearance" and clicked Reset to defaults. Even with a stereotype applied, this reverts to the "unstereotyped" appearance. I grabbed the RGB values from one the element on the right in the image and set the element on the left's values to those numbers and it's all consistent now.
The main question was the Run State variables, which #(Thomas Killian) addresses in another answer.
I have a custom toolbox with a foo element.
I would like the foo to be green on an class diagram and red on flow chart diagram by default.
Adding more than one stereotype to non- UML type is impossible (as far as I know).
Is it possible to create 2 toolboxes- one for class diagrams and one for flow charts, specifying the default diagram for each toolbox in the profile?
Not quite the way you describe it.
Toolboxes don't specify which diagram they open, it's the other way around: you create a custom diagram type and associate it with a toolbox. Different custom diagrams may use the same custom toolbox.
You can create two custom diagram types, one for class ("Logical") and one for flow chart ("Activity"), but if you're only after getting the same stereotyped element (foo) to display differently in the diagrams, you don't need to.
The solution is to create a shape script for the stereotype, which checks the diagram type and changes the color accordingly. The diagram type can be queried from the shape script using the diagram.type property (for the base UML diagram type), or diagram.mdgtype (for the custom diagram type, if you've defined one). There is no need to create an Add-In, as another answer suggests, at least not in EA 11.
Check the help file under Extending UML Models -- MDG Technology SDK -- Shape Scripts -- Write Scripts -- Display Element/Connector Properties.
A simple script might look like this:
shape main {
if (hasproperty("diagram.type", "Logical")) {
setfillcolor(0, 255, 70);
} else if (hasproperty("diagram.type", "Activity")) {
setfillcolor(255, 87, 87);
}
drawnativeshape();
};
No. You need to have two different stereotypes. The target diagram is independent of the element. If you want the element appear different on the type of the diagram where you use it you need to adapt the shape script so it calls an add-in which detects the diagram type.
Well, writing the last sentence I would not know how to detect the diagram where the element in question is in. Needs investigation. But other than that - no solution I know of.
Edit: Since the add-in just receives the element GUID it has no way to figure out the diagram from where the call is made. Probably worth a feature request. But the time where we saw those realized in the next build are gone (since more than 10 years).
A last though: template packages. I almost never used them. Maybe they offer coloring depending on diagram/element.
Edit2: Last resort EA_OnPostNewDiagramObject. Catch that and you can get all information you need to apply the color.
I am trying to draw a part decomposition diagram with EA10. It should look like below.
But I couldn't find how. Is this UML diagram ever supported by EA?
Found it. I need to activate the "More tools..." -> "Composite" first. And choose "Port".
BTW, this is really a bad user experience.
You're doing it wrong. Sorry, but there's no kinder way to say it. :)
If the lifeline (:Class) is associated with a classifier (Class) which has properly defined ports (as it should be), then the following applies:
If you create the lifeline by dropping the classifier onto the sequence diagram, you get the option of displaying the ports (aka "structural elements") immediately.
Regardless of how the lifeline was created, you can right-click it and select "Structural Elements" which allows you to select the ports from the classifier (which may have been added since the lifeline was created).
If you want to create ports under a lifeline which has no classifier, you can do that too. Simply right-click and select "Structural Elements". The dialog allows you to create new ports.
The :Class lifeline presumably gets its type information from a Class element, so the first thing you need to do is find the Class element and give it two ports. Once you have done that, you can right-click the lifeline, select the Embedded Elements dialog and include the ports on the lifeline. (The Embedded Elements dialog may have been renamed Structural Elements in recent versions).