For our project, wo would like to document certain information with the model in Enterprise Architect, in order to not have multiple sites where stuff get's documented.
A consequence is, that the default model of EAUML::table and EAUML::column is insufficient.
Therefore I started to extend the classes to add our custom properties as shown below.
Now (after exporting and importing a MDG Profile) I am able to change our defined tables to our new stereotype.
Question here is: Is there a way to change the default column stereotype to "CUSTOM Col" for the "CUSTOM Table" instances? I don't seem to find a way. I imagine with a script in the right place or a "substitution" of the right kind. But I am an EA-Newby and have no clue how to solve this.
Thanks for any pointers.
Best
Related
I see that Magic Draw supports both graphical and tabular notations. However, I would like to know if they can be synchronized to one another or they only function separately. So, if I create a class diagram with the graphical editor, can I generate a table from it in MagicDraw? And whenever I make the changes to one editor, the changes to be reflected in the other editor?
Thank you!
The answer is complex.
First, diagrams are views of the model. Tables, as just another kind of diagrams, are therefore views of the model. In other words, changing an element in a table will change the element in any diagram it is displayed.
Now it gets complex - but how you use the tool can simplify the. You seemed to ask, can a table be synchronized with a table and a table with a diagram? A table can be based on a scope, a query, or by composition (drag an element onto the table or create on the table). Scope or query is is a lot better because they can be used to match the diagram or package where the diagram puts its data (by default, the package where the diagram is stored).
However, diagrams are intended to be expressions of the human for us humans. Thus the diagram does not automatically add elements if they were added in a table.
How do we square the circle? How do we add (or even detect) an element created on a diagram? There is a way to get a list of diagrams (https://community.nomagic.com/usage-in-diagram-displayed-in-generic-table-t5789.html ). Using a similar technique a rule could be created to warn about elements that are not on any diagram. It is still up to you to add the element to the diagram with this information at hand (or write a fancy plugin).
I am trying to add a Tagged Value in Enterprise Architect which allows the selection of one or more values, a multi-select tagged value type in effect.
Is this possible?
Xstian's answer is partially correct if you're working with profiles. However, it only provides you with a select-from-a-list tag type (and you should not import profiles directly into a project, you should create MDG Technologies instead).
EA also allows you to create what are known as structured tagged values. These come in different flavours, and allow you to select a value from an enum list, a file name from a browser dialog, a date from a calendar, and many others -- including classes in the same model.
These tagged value types are configured in Settings - UML Types - Tagged Value Types. The syntax is described in the help file under Extending UML Models - MDG Technology SDK - Tagged Value Types - Predefined Types (but note that you do not need to create an MDG Technology or even a profile for these tag types to work).
You can add to any model element more than one tagged value of the same name - each of them can have different value. Together they logically constitute "set of values" (i.e. multi-valued tag).
Yes it is.
I solved in this way.
You should create a your Stereotype
http://www.sparxsystems.com/enterprise_architect_user_guide/10/extending_uml_models/addingelementsandmetaclass.html
(e.g. see image)
You should export this profile in XML and import it into EnterpriseArchitect
http://www.sparxsystems.com/enterprise_architect_user_guide/10/extending_uml_models/importingprofiles.html
Add this stereotype to your class,connector, etc
I hope I've given you all the answers about your question
PowerAMC/PowerDesigner allows you to create "graphical synonyms" of underlying entities allowing you to place the same entity twice (or more) on a diagram. Each is an instance of the same entity. This is great to pretty-up diagrams when, somehow, an entity must be linked to two others that happen to be on opposite ends of the diagram.
Is there a way to do this in Visio 2010 when using the database modeling template?
There are two ways of doing this:
Open the Table and Views panel (Database tab, Model Preferences, first tab, "when deleting an object from the diagram" should be on "Ask the user")
Drag and drop the existing table from that panel onto the diagram
This creates a duplicate of the logical entity and recreates all links (relations) to it. Not immediately useful to clean up the diagram but if you delete the extraneous links and say "No" when it asks if it should also delete the logical elements, then the links disappear visually but the foreign keys remain.
Second method:
Copy a table from the diagram (CTRL+C)
In the Home tab, choose to Paste, Special Paste and keep what should be the default mode: Visio diagram data
A copy of the table will appear but it won't be automatically linked to anything visually.
From both points, the duplicates on the diagram are both logically the same entity. This means that if you modify one, the other is also modified. If you link one to something, the other one is also logically linked (foreign keys will be listed in both, though only one may have the visual link).
Note: I'm using the French version of Visio so exact labels mentioned may be different in English. I tried translating to the best of my ability.
If you press the control key then click and drag an entity it will create a synonym.
I have yet to figure out how to remove a specific synonym without deleting all replicas of it.
Consider the following scenario
We have a simple database that involves two entities: user and category.
For our hypothesis let's say that a user can have only a type of category and a category can be associated with n users.
Now, consider a web page where a user - say ROLE_ADMINISTRATOR - could edit user table and associate them to a different one category.
As far I know (and I'm still new to symfony in general) if I use Doctrine and symfony2 in tandem, with - let's say - annotation method, i'll have two entity (php classes).
Embedded form
I will create a form that will show the user and, for show - and persist, of course! - also his category I "choose" to follow the "embedded form" strategy.
Having said that the entity has been created, i'll have to create a form for category (suppose that into formBuilder I'll add only id attribute of the category).
After that I have to add to formBuilder of UserType class the previous form and, with "some kind of magic" the form will render (after the appropriate operations) as magic and just as magically, when i'll post it (and bind, and so on) back all the informations will be persists onto database
Data Transformers
A.K.A. trasnform an input of a form into an object and vice versa.
In that way I'll have to define a - let's say - CategorySelectorType that into his builder, will add a Class (service ?) that will do those transformations.
Now we define the data transformer itself that will implement the DataTransofmerInterface (with his method and so on...)
The next step will be register that entity into services and add into UserType the form that will use this service.
So I don't understand any "strong" difference between those two metodology but "reusability" of the service. Somebody can offer me a different point of view and explain me the differences, if any?
A data transformer does not replace a embedded form, it rather enhances forms and wraps data transformation nicely.
The first sentence on the cookbook page about Data Transformers sums it up nicely:
You'll often find the need to transform the data the user entered in a
form into something else for use in your program.
In your example above, you could add a drop-down list of categories so the admin can select one for the given user. This would be done using a embedded form. As the category field is the id of an existing category, there is no need to transform the data.
For some reason you now want the admin to be able to enter a free text of the category. Now you need to do some tranformation of the text into the object in question. Maybe you want him to be able to either add a new or select a current category with this text field. Both is possible by using a data transformer which takes the text and searches for the category. Depending on your needs, not existing categories can be created and returned.
Another use case is when a user enters data which needs to be modified in some way before storing them. Let's say the user enters a street, house number and city but you want to store the coordinates instead.
In both cases it doesn't matter if you embed the form into another!
Could you do that in your controller? Of course. Is it a good idea to do such things in the controller? Probably not, as you have a hard time testing (while doing it in the transformer let you unit test the transformation nicely) or reusing it.
UPDATE
Of course it is possible to place the transformation code someplace else. The user object itself is not a good place, as the model should not know about the entity manager, which is needed to do the transformation.
The user type would be possible, but this means that it gets tied to the entity manager.
It all adds up to the very powerfull concept of Separation of concerns, which states that one class should only do one thing to make it maintainable, resuable, testable and so on. If you follow this concept, than it should be clear that data transformation is a thing on its own and should be threated as such. If you don't care, you may not need the transformation functionality.
I would like to experimentally apply an aspect of encapsulation that I read about once, where an entity object includes domains for its attributes, e.g. for its CostCentre property, it contains the list of valid cost centres. This way, when I open an edit form for an Extension, I only need pass the form one Extension object, where I normally access a CostCentre object when initialising the form.
This also applies where I have a list of Extensions bound to a grid (telerik RadGrid), and I handle an edit command on the grid. I want to create an edit form and pass it an Extension object, where now I pass the edit form an ExtensionID and create my object in the form.
What I'm actually asking here is for pointers to guidance on doing this this way, or the 'proper' way of achieving something similar to what I have described here.
It would depend on your data source. If you are retrieving the list of Cost Centers from a database, that would be one approach. If it's a short list of predetermined values (like Yes/No/Maybe So) then property attributes might do the trick. If it needs to be more configurable per-environment, then IoC or the Provider pattern would be the best choice.
I think your problem is similar to a custom ad-hoc search page we did on a previous project. We decorated our entity classes and properties with attributes that contained some predetermined 'pointers' to the lookup value methods, and their relationships. Then we created a single custom UI control (like your edit page described in your post) which used these attributes to generate the drop down and auto-completion text box lists by dynamically generating a LINQ expression, then executing it at run-time based on whatever the user was doing.
This was accomplished with basically three moving parts: A) the attributes on the data access objects B) the 'attribute facade' methods at the middle-tier compiling and generation dynamic LINQ expressions and C) the custom UI control that called our middle-tier service methods.
Sometimes plans like these backfire, but in our case it worked great. Decorating our objects with attributes, then creating a single path of logic gave us just enough power to do what we needed to do while minimizing the amount of code required, and completely eliminated any boilerplate. However, this approach was not very configurable. By compiling these attributes into the code, we tightly coupled our application to the datasource. On this particular project it wasn't a big deal because it was a clients internal system and it fit the project timeline. However, on a "real product" implementing the logic with the Provider pattern or using something like the Castle Projects IoC would have allowed us the same power with a great deal more configurability. The downside of this is there is more to manage, and more that can go wrong with deployments, etc.