UML class diagram relation type question

Question

I have a data class with the following methods:

• ExecuteUDIQuery(string query)
• ExecuteSelectQuery(string query)
• ExecuteSP(string anme, string[,] params)

I have a lot classes which use the data class. Now i want to create a class diagram, but i don't know what kind of relation the classes have with the data class. Is it a composite? Is it 1:1 or .. ?

An example of a class which use the data class is the Staff class. This class has a method Load(), which will load a staff object with the Id of the staff member. This method contains a query which is passed to the ExecuteSelectQuery(string query) method of the Data class.

EDIT: The data class isn't static. However, i have my doubts. I actually don't know what to. The point is, the only thing it does is executing queries and returning the results.

Answer 1

I would suggest its a usage dependency relationship.

See here for a brief description.

Answer 2

The difference between aggregations, composites and 1 on 1 relations are a bit vague and somewhat arbitrary.

I use the aggregation (open diamond) if one class owns the other class (is responsible for the lifecycle.

I use 1 on 1 relationships in all other cases.

Answer 3

Is the class instantiated by the classes that use it or are the methods static? If they are static I would represent this as an unqualified dependency (dotted arrow pointing from the classes that is using the data class to the data class)

If the classes that are using the data class create their own private instance of that class this would be a 1:1 composition (assuming that the data class instance's lifcycle is tied to the object that is using it)

Answer 4

I cannot refrain from commenting your overall design, I would try to move the Load method out of the Staff class, so that this class is not dependent on the Data class directly.

Within the scope of your existing design I would suggest the following: If the staff class contains an instance variable of the data class, then it is an association. If the data class is instantiated just to retrieve the instance, it is just a dependency of a given type, like @toolkit says.

Answer 5

Not enough data.

Give us some class outlines or something. From what I can see, I wouldn't have actually called this a data class (it looks more like a data accessor) which sounds like it might be a singleton (many:1, aggregation or association), or if instanced will be a 1:1 component.

Answer 6

I would query the naming of your classes. a class name should normally be a singular noun. Examples;

• Window
• Person
• Transaction

Data is a plural, and in any case I think it should be Database.

Similarly for Staff - once again a plural, I think it should be MemberOfStaff. Unless of course it is a list of members of staff, in which case I would call it something like Department, Project or Division - whatever your problem domain indicates.

You will find that coming up with good names for classes is suprising ly difficult, but it is well worth the effort.

Answer 7

Now i want to create a class diagram, but i don't know what kind of relation the classes have with the data class.

Nor do we - you've only described the Data class, and not said how Staff gets the Data it uses.

If Staff holds on to one or more instances of the data class, then there is either an association between Staff and Data, or Staff has an attribute of type Data (if Data has value semantics).

If the Data instances are referenced by multiple Staff instances, and their lifecycles are dependent on being referenced by Staff instances then this may be shown as an aggregation relation. If the Data instances are not shared between Staff instances and their lifecycles are dependent on being referenced, then this may be shown as an composition relation.

If X doesn't keep hold of the Data instances it uses, then a usage relationship is appropriate.

Answer 8

Dependency and Usage are the two weakest kind of "connectors". You might consider stereotypes, keywords to refine the relationship. You might find that instantiate,call,create,send stereotypes work. Without more information though the correct answer seems to be usage.