I'm using Enterprise Architect 10.
I need to define additional properties of model attributes, example: show condition (text), edit condition (text), location in data tree from remote source (text) and others. Those properties are for documentation purposes at the moment. But it may occur that some of those properties will be used during generating source code by custom generator.
Use tagged values for this purpose. Creating Advanced/Properties is not really possible. Tagged values can be shown in compartments if you switch that on in the Feature and Compartment Visibility. Shape scripts can use them to render individual shapes and the code generator can also evaluate them.
As Geert points out, start looking into MDG creation. Though it's quite some start-up you have to do, it will pay off in rather short terms.
Related
I'm working on a project where I'm using an SDK that provides things I need via some classes. I've named these ProviderProvider and Provider, that grant access to OneThing that is an IThing.
An example is shown here
.
My question is: What is the correct (or best) way to show that the Model provides the list of OneThings to the View through those classes?
Do you show this explicitly as in my example, by drawing a dependency arrow from Model to OneThing? That doesn't seem right to me and quickly becomes visually cluttered.
Do you not explicitly define that relationship, but is it simply implicitly defined through the other relationships?
Do you define that relationship semi-explicitly through attributes, notes or some other way?
What relations and attributes should I add/remove specifically and why?
You already have the implicit relationship since you use this class as a type of data returned by Model so you do not need to add that relationship explicitly.
It may be useful though, especially for classes that are core in the system, to add a diagram with dependencies only. Then you don't care about relationships between other classes, you only show on one diagram all classes that depend on the core one (it may be even more than one diagram).
One hint - in Case tool (like EA) even if you don't intend to show the relationship on the diagram since it is indicated implicitly it is still good to create the explicit dependency and just remove the arrow. This will support the traceability through tools like traceability matrix or dependency tree.
In my previous question I was trying to achieve the idea of ordering the classes. Although the example I presented wasn't appropriate.
So here is the situation I want to ascribe by UML class diagram:
In ODT document I have something called figure. The figure is comprised of two atomic elements: image and title(of the image). The standard allows me to put the title, either on top of the image or bellow the it. Although In my application the title will always be beneath the image like this:
So in my case I want to submit the (more specific) information that the title must be beneath the image (although the standard does not obligate so). Thus I came up to the idea of making order in my class diagram (this is first, then this, then this, etc...). Because in my case that matters.
Here is my despaired attempt:
Is there any approach to present that information through a UML Class Diagram?
In the UML meta-model, there are meta-elements called Class and Property. An instance of a Class meta-element (e.g., called Figure) may own instances of a Property meta-element. Each instance of a Property meta-element has a type (e.g., Image and Figure). Both of the instances of the Property meta-element in your model are unnamed, which, unfortunately, makes it difficult to refer to them. Nonetheless, all of the instances of the Property meta-element that an instance of the Class meta-element owns are ordered. When you create a property in a UML tool, you generally add it to the end of an ordered list.
In your diagram there are two unnamed properties that are already ordered (implicitly, based on which you created first in the tool). This order can be seen and changed in a UML compliant tool. Here is an example UML model:
I strongly recommend you name all your properties, as I have done in my example model. For example, I named them title and image, starting with a lower-case letter. Among other benefits, that way you can see which is which more easily when you reorder them.
Here is a specification window in a professional tool called MagicDraw, where you can drag properties into the order you like:
You could change the order to say that the image comes before the title.
P.S., in an analysis model, if this ordering is a rule that's important in the problem domain, I would actually show an explicit association between Image and Title having association ends called something like comes before and comes after.
Is there any standard to display features(use cases) that I want to add to system in next version in use case diagram?Or I have to display them for example with specific color,shape or ... ?
There is no standard here.
What I do in such cases is to create a profile that contains stereotyped elements like <<enhancement>> <<feature request>> etc. which simply extend the class meta class. I link them via a (<<trace>> stereotyped) dependency to the relevant element (like e.g. use cases).
The advantage is that I can add tagged values where I can set additional information like target build, responsible, etc.
It's true, there is no standard.
Using colors is a handy approach because changes are visible at a glance e. g. when shown in presentations. Assuming of course that you are not yet using colors for other semantic purposes.
You can also use UML notes.
Generally it makes sense to have diagrams versioned, so you can trace back diagram and model changes.
Some tools allow to store a version in the elements' metadata but you need to check where these can be used, because they are not necessarily visible in your diagrams as well.
I am trying to visually show a relationship on an instance of an object in enterprise architect.
I have a requirement “A” and an instance of a class B, “:B”. Between the two objects I have created a dependency relationship. I would like this relationship to be visible by adding the class name to the instance (for example in the lower right corner) everywhere when the instance is used.
This would mean that in any diagram where ”:B” is used it would clearly seen that “:B” has a relationship to ”A”, even if “A” is not present in the diagram.
Is this possible? I have tried shapescripts without success.
I'm afraid the answer is "not out of the box," because a shape script for an element cannot access the element's connectors. (A shape script for a connector, by contrast, can access certain properties of its source and target elements.) However, there are two alternatives.
Alternative 1
If you represent the requirements not as individual Requirement elements but as internal requirements (accessed in the Requirements tab of the object's properties dialog), you can display them in diagrams by selecting Requirements in the Elements tab of the diagram's properties dialog (makes the setting diagram-wide), or by selecting Responsibilities in the object's Feature and Compartment Visibility dialog (selects it for that element only).
Please note that with the latter option you can also select display of Inherited Responsibilities, which in your case would show, in the object :B, any requirements on the class B.
The disadvantage is that this only works for internal requirements. EA allows you to make internal requirements external, that is, to create proper Requirement elements from the list entries in the Requirements tab, but while this does not remove the externalized requirements from that list, it does stop them from being displayed in diagrams in the above manner.
Alternative 2
Shape scripts offer a get-out-of-jail-free card in the form of the addin property. This allows your shape script to call a function in an Add-In and display the results. So you could write an Add-In with a function which returns the names of all connected Requirement elements and call that. I've used this to display requirements in a similar manner to what you're describing, but that was for a client so I can't post any of that code here.
The disadvantage with the Add-In approach is that anyone who looks at the model needs to have the Add-In installed or the requirements won't show up. But the shape script won't go crazy and crash (it'll just quietly skip any calls to Add-Ins it can't find), and you'll still be able to find the requirements the old-fashioned way by following the links in the properties dialog, or the Traceability View, or the Element Browser.
Which is the better alternative? Well, it depends... I personally prefer modelling requirements as proper, separate elements (possibly starting out as internal requirements, which are then externalized) because it gives you more flexibility. But you should only go the Add-In route if you have some control over the clients, that is, if you can make sure all modellers have the Add-In installed.
I'm currently in a project where I have been asked to create a logical data model in UML. Now i've defined all my logical data entities and know all my attributes i'm just a little lost on how I can map these attributes to the UI.
The point of the exercise is to prove all the attributes in the requirements have been met in the system we have chosen to deploy. Happy to supply more information.
The application I am using is Enterprise Architect.
This question was solved the Enterprise Architect Support Forums.
Connect both classes with an association
Right click the assoc. near the class with attributes
Context menu/Link to Element Feature
Attributes
-> select the one and the assoc. is attached to it
There is an elegant approach which is to use Database stereotypes in your class diagram on attributes and then map it to java ORM annotation in the code.
I don't think EA can do this ORM mapping but other tools can.
Do you have artifacts in your model for the UI, too? That is, as a screen mock up or as a class model of the underlying UI classes? If yes, then you may find it very helpful to establish a traceability for your artifacts using a realization or dependency relationship.
You can further support that by creating requirement entities (in a SysML requirements diagram) and drag'n'drop the respective requirement onto the entity which provides a solution to it. This is described on page 31 in the following EA whitepaper: http://community.sparxsystems.com/whitepapers/Requirements%20Management%20with%20Enterprise%20Architect/Requirements_Management_in_Enterprise_Architect.pdf
I made a screenshot for you of how this looks, but unfortunately I am not yet allowed to post it here since I am a new member. Maybe you can get a rough idea from this screenshot I found on the web: http://www.sparxsystems.com.au/enterprise-architect/images/traceability_lg.png
That mechanism works on class level. On the attribute level you may want to add a link to specific related (requirements) elements in the notes field, if necessary.