When i am generating gmfgen model from gmfmap this error validation is shown." Phantom nodes that are not targeted by a link mapping representing containment reference present in model. "
What is the solution of it?
For me it meant that I forgot to specify a 'containment feature', which is a property of a node in the .gmfmap file.
I realize this is too late for you, but I arrived here through Google and so might other people.
Related
I was recently studying an online course. it was recommended that to reduce coupling we could simply pass the ID from the customer object to the Order object. that way the Order did not have to have a full reference to the Customer class.
The idea certainly seems simple and why pass a whole object if you don't need all its attributes?
1) What do you think of this idea?
2) How would I express the relationship between the Customer class and the Order class in UML if only an ID is passed. This isn't just an example of aggregation is it? Doesn't composition and aggregation require more than just passing a value?
Thanks!
First of all you need to be clear about what UML actually is. On the one hand you have an idea and on the other side there is some code running on hardware. Ideally the latter supports the first in a way that brings added value to a user of the idea. Now, there are many possibilities to describe the way from idea to code. And UML is one of them. It is possible to describe each step on this way but for pragmatic reasons UML stops at the border of code, namely programming languages.
Now for you concrete question: Any object can be seen as an instance. That is some concrete memory partition with a fixed address. Programming languages realize instances by allocating memory and using the start address as reference. And since this reference does not change the object can be identified by its address. Clearly then, an association will just be the a pointer. And an association class will hold two (or more) such pointers.
Honestly, the very first time I started with OO I was also confused and thought that it's a waste of resource to pass those large objects. But since it's just a pointer it's really easy going.
Again, things can get more difficult if you need to persist objects. In that case you need an artificial key you can save along with the object and you will likely need tables to map artificial key to the concrete instance address.
The answer to this question depends on a number of factors, which I started listing in a comment attached to your question. I will assume that you are either using UML to create a Domain Model, or you are describing an implementation done using a statically typed language.
If you are using UML to create a Domain Model, you are obfuscating the semantics when you use an ID to "link" classes. Just draw and annotate the association and you're done.
If you are describing an implementation done using a statically typed language - types exist for a reason. Using generic IDs to link things means that the information that the system needs most become more indirect, and therefore more opaque (which is bad). In your case, the Order object still must acquire a typed reference to a Customer object to do anything with it.
For example, the Order may acquire a reference to the Customer by invoking a lookup by the ID, but it must cast the reference to an appropriate type to invoke anything on the Customer object. So you haven't reduced the coupling from the Order to the Customer. You just buried it somwhere else.
According to UML specs every Element can have an owner. Whether he has/must have an owner is determined by method mustBeOwned(): Boolean, which by default is true (see 7.8 Classifier Descriptions in specs).
In cases when an element is completely enclosed by its owner (such as a class in a package) it is quite obvious.
However for relationships (normal, directed, generalization, …) I didn't find any specification. Is the "source" (for directed at least) also the owner?
Is it the first common owner in the ownership chain? So for example association between two classes in a same package, the owner of the association would be the package.
Or is it simply not defined and it can be whatever I want?
To be honest, the definition of terms in Superstructures is still very poor.
Looking closer it's even worse (citing from ptc 13-09-05).
Relationships (p. 15)
A Relationship is an Element that specifies some kind of relationship between other Elements. Descendants of Relationship provide semantics appropriate to the concept they represent.
Connector (p. 235)
A Connector specifies links that enables communication between two or more instances. In contrast to Associations, which specify links between any instance of the associated Classifiers, Connectors specify links between instances playing the connected parts only.
I wasn't aware that they made a difference between both. Appears to be quite picky.
Association (p. 206)
An Association classifies a set of tuples representing links between typed instances. An AssociationClass is both an Association and a Class.
No mentioning of Relationship as being a parent.
Now seeking for the truth about owner
owner (p. 37)
/owner : Element [0..1]{union} (opposite Element::ownedElement) The Element that owns this Element.
mustBeOwned (a bit down)
mustBeOwned() : Boolean
The query mustBeOwned() indicates whether Elements of this type must have an owner. Subclasses of Element that do not require an owner must override this operation.
So here one is stuck unless reading to
Association (p 209)
Ownership of Association ends by an associated Classifier may be indicated graphically by a small filled circle, which for brevity we will term a dot. The dot is to be drawn integral to the graphic path of the line, at the point where it meets the Classifier, inserted between the end of the line and the side of the node representing the Classifier. The diameter of the dot shall not exceed half the height of the aggregation diamond, and shall be larger than the width of the line. This avoids visual confusion with the filled diamond notation while ensuring that it can be distinguished from the line. The dot shows that the model includes a Property of the type represented by the Classifier touched by the dot. This Property is owned by the Classifier at the other end. In such a case it is normal to suppress the Property from the attributes compartment of the owning Classifier.
Answer?
Most likely (!) connectors do not have the mustBeOwned constraint and can be owned in which case you will see the dot that has been introduced with 2.5. Else they are probably not owned.
To my understanding, the relation is generally not owned by elements it connects. What is owned is the association (relationship) end's and corresponding attributes/properties. Section 6.4.2. of UML specification 2.4.1 clarified this much better than your linked 2.5 beta. I would suggest that you use the current official version of specs rather than the beta one. I find the 2.5 being kind of unintelligible, the table of contents looks very chaotic.
The Relationship itself exists independently, it has no owner. Except when stated otherwise by concrete type of relationship (as in case of Generalization).
Which brings me to the main point of my answer by question. Why do you need to know?
I have been reading and explaining the specification for years now, but never came across such a specific question, which moreover is relatively clearly stated in the specs.
I would recommend to look at concrete relations and search (Ctrl+F) for "owned" (an Association has more than a page of text on this very topic in detail starting on page 40 in 2.4.1).
I myself have been trying to figure out what can own an instance of Association. I am using 2.4.1. This appears to me to be a(nother) case of the standard not actually being usable.
I haven't looked at all of the specializations of Relationship. I have looked at Association. It inherits owner from Element. The property is noted as a derived union. I can't find any property of Association (or any of its antecedents) that subsets owner. That being the case, I don't see how Association can actually have an owner.
I think that it seems reasonable for a Package to own an association.
I am using a UML tool that certainly does initialize the value of owner for associations. I am programmatically interpreting models created in that tool and using them as input for other modeling tools that I am working on. The makers of the first tool obviously had to just make up / guess at things and now I have to decide whether what they did was actually rational and if I want to agree with their conclusions (which happen to allow Classifiers to own Associations, which I think is weird) or do something else. Thanks OMG. Grrrr.
I wonder if older versions of the spec were any more clear?
I seem to have a problem about a simple time tracker. The way its set up is that a user can track hit time related to a project or type in something freely. This means that a timetrack object always has a user but does not always have a project. The inconsistency can occure when I create a Timetrack object in the database connected to a user, but then connect a project that does not have a association with the user to the same time track object.
Whats the best way to fix this. I've heard about directional association but I can't figure out how that solves the problem
class diagram:
I don't understand your explanation of TimeTrack, but I think that your modeling problem can only be solved by adding an integrity constraint (called "invariant" in the UML) requiring that the time track user is a member of the set of the time track project's users.
This can be formally expressed as an OCL invariant in a constraint box attached to your TimeTrack class with the following expression:
self.project.users->includes( self.user)
Instead of OCL you can also simply attach a constraint (note attached to the related connector) containing something like:
{association can only exist if there is a connection between project and user}
I have been told to create an analysis diagram but it states that only date classes should be added. I thought that is what you use anyway, or am I thinking about this wrongly
"The models include a domain/analysis class diagram (which contains data classes only)"
I wouldn't ever use this terminology but my guess is that the instructor/manager wants your model to contain only the classes that will be later on implemented in the database (i.e. those that represent the concepts that you´ll need to store information about). To me this set coincides with what I´d refer to as domain classes but maybe your instructor has a different interpretation
All of my Visio experience is with LAN/WAN documentation. I recently had a desire to visualize the relationship between objects in the Nagios configuration and I realized I didn't know how to do it properly and moved on to something more important. I was reading the responses to this thread and realized this is something software developers must do a lot.
So this is probably a soft-pitch question, but what is the proper method for documenting object relationships in Visio? Is there a better template to use? What stencil collection is the proper stencil in?
In my probably naive view I imagine an object being a large box with a single "reception" connector and containing multiple smaller boxes, each of which represents an object member and having its own connector. So, each object member field would connect out to the "reception" connector on the object of the member's type. In and of itself those objects are fairly easy to build. The problem I ran into is that the connector lines didn't respect the objects and ran over the top of them, making an awful, unusable mess.
Thanks for any pointers.
You can use a UML static class diagram with << stereotype >> annotations, which is the kind of thing you would do in Rational Rose for using UML for things that aren't necessarily classes and methods, such as databases.
I've been using these UML stencils for diagramming object models and entity relationship diagrams. It is fairly comprehensive. Be sure to take a look at the "tips" document... very important.