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
Related
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
I was able to define a custom programming language in Enterprise Architect with custom data types by navigating to Project > Settings > Code Engineering Datatypes.... When I create a MDG file, I have the option to include the programming language definition, and as far as I can tell, this is working - at least, in a new project that uses the MDG file, I can see the programming language.
Now I would like to have the same behavior for DBMS and database datatypes defined through Project > Settings > Database Datatypes.... From my tests, I get the impression that these types are not automatically included in the MDG file, and I haven't found a trivial way to include them. Is there a way to add the database datatypes to the MDG file as well? If not, is there a way to achieve the same result through the automation interface, e. g. by writing an add-in that creates the DBMS and the associated datatypes?
Going the MDG Technology way, the answer appears to be no. It's possible to trick EA (11) into exporting DB types in an MDG Technology, but even if they're in there, they will be ignored in projects that use the MDG Technology.
DB types and code engineering (or, sometimes, "programming language") datatypes are both stored in EA's t_datatypes table. The same product name can be used for both a programming language and a DB engine.
It looks like the MDG Technology Wizard scans this table looking for rows with "Code" in the Type column during the setup (Code Modules wizard page), but when the time comes to write the actual datatypes into the output file, it retrieves all rows with the specified ProductName.
This means that if you create a DB product and populate it with a set of datatypes, and then create a programming language product with the same name but just a single dummy datatype, your DB types will be included in the MDG Technology XML file along with the dummy type.
However, it appears that while the regular properties dialog (for classes etc) checks the loaded MDG Technologies in addition to the t_datatypes table in order to populate the Language drop-down list, the specialized properties dialog for database tables does not check the MDG Technologies when populating the corresponding Database drop-down. So even though the datatypes are in the file, you can't use them.
Going the Add-In route, the answer is yes.
Have your Add-In respond to the EA_FileOpen event and check the Repository.Datatypes collection to see if your DB types are installed and if not, add them.
You don't actually need to write an Add-In if you don't want, you can write an in-EA script. The only thing an Add-In can do that scripts can't is respond to events (which is why those are listed in the Add-In Model section of the help file). So with a script you would have to trigger the function manually.
There is also an API to manage project's reference data of which code / DB datatypes is one category, but it only gives you control of some of the categories (eg requirement types and constraint types), and the datatype category is not one of them.
I have to model a product, which has properties that aren't listed in the Schema.org Product type. After seeking in many places, I didn't find anything that fits to my need.
How can I extend the Schema.org Product type?
You could always use other vocabularies (that offer the properties you need) in addition to Schema.org. But if you want to use only the vocabulary Schema.org, you have two options in general:
Propose new properties (or classes).
You can do this on Schema.org W3C Community Group’s mailing list, or on Schema.org’s GitHub issue tracker.
See: How can I get involved? How can I propose new schemas or other improvements?
If accepted, it might become part of the core (if it’s something "the most common web applications need"), or it might become an extension.
(deprecated!) Extend existing properties.
Extending existing properties is documented at http://schema.org/docs/old_extension.html, but note that this mechanism is considered outdated.
For specific types (including Product), you can use Schema.org’s additionalProperty property:
A property-value pair representing an additional characteristics of the entitity, e.g. a product feature or another characteristic for which there is no matching property in schema.org.
How to store only metadata for an object of type sys:base or cm:object? I have a type which is sub-type of sys:base. I need to store the metadata of it.
My doubts are:
1. Where should the data be stored?
How to retrieve the data, as in content and folder you can see the appearance as icon in the company home or user home etc. How does the metadata appear in a folder(is it like an icon of cm:object)?
With reference to the question posted earlier in alfresco forum (http://forums.alfresco.com/forum/developer-discussions/content-modeling/can-i-store-only-metadata-alfresco-11292012-0437) should the object be of type cm:content to store the metadata (except that they do not have a content property). Is there anyway to create metadata other than being subtype of cm:content?
Thank you
You can store metadata on instances of any type as long as the content model includes properties that meet your needs. Those might be out-of-the-box types or they might be custom types.
If you need to create objects that have a content stream, use cm:content. If you don't need to set a content stream you might consider using one of the two types you mentioned. But it won't necessarily hurt anything if you elect to simply create instances of cm:content that don't have a content stream.
If you want to use sys:base or cm:object, simply create an instance of either of those types. Alternatively, define your own sub-type of those types then instantiate that custom type and set your metadata.
If you don't know how to define custom types or you are unsure about how to set, update, or query metadata, you could start by reading this tutorial.
Also note that if you create instances of any type other than cm:content, cm:folder, or a custom type that inherits from one of those two types, you will be unable to do that using CMIS. That isn't the end of the world, just be aware that it is currently a limitation. Someday Alfresco will support the "item" type which is new in CMIS 1.1, but until then, CMIS in Alfresco can only work with documents, folders, and your custom types that inherit from those types.
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.