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.
I would suggest its a usage dependency relationship.
See here for a brief description.
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.
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.
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)
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.
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.
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.
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.
Related
I have class Controller in my java project, which has method like this:
As you can see, in the first line I am getting Singleton instance of ActualModes class and call method getActualModes().
So the first question is, which relatinship I should use in class diagram.
After that I am creating new instane of ModeContext class and then call method executeStrategy. In this case, which relatiship is better ?
It should be like this:
Access to the singleton (note the stereotype which is just convenient and no obligation or general standard) is anonymous and so you just have a dependency. The ModeContext in contrast uses a private (I don't know the scoping rules of the language you used, so I made it pivate) property called context. Note the dot which is saying exactly that.
Disclaimer: UML does not specify a mapping between Java and UML, so every answer to your question is open for debate.
I think both relationships are dependencies, drawn as dashed arrows from Controller to ActualModes and from Controller to ModeContext. The definition of 'dependency' according to the UML 2.5 specification (§7.8.4.1) is:
A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other
model Elements for their specification or implementation.
An example of a type of relationship which is in my opinion less suited, is the association, although its definition (§11.5) is quite broad:
An Association classifies a set of tuples representing links between typed instances. (...) An Association specifies a semantic relationship that can occur between typed instances.
One could argue that there are links between Controller and the other two classes, in the form of variables, but these variables are local method variables, which exist only temporarily during the execution of the method. Associations represent more durable links, e.g. class members - as far as I understand UML and as far as I have seen associations used in practice.
Let's assume I have 2 classes with association relation.
What is the difference between adding attributes to one of the classes and adding an Association Class with attributes?
I understand that association class describes the association relation, but cannot I use simple class attributes instead?
What are the added values of Association Class?
Association and attributes are actually different renderings of the same thing. The difference is more a bit of esoteric nature. An association is visually more exposed than an attribute. So you would use the attribute if it has a more local importance rather than a more system wide in case of an association.
What you should not do is to use both. When using an association and you need to name it then use a role along with the association and do not repeat it as attribute.
An association class (AC) is actually a combination of a class and an association (in UML it inherits from both). This way the pure relation between two classes can have methods and attributes itself. An association class is used if you want to relate two classes with M-N relation. E.g. the AC between Student and Exam describes the results a student has achieved in exams. So you have a Class 1-M AC N-1 Class relation rather than having this information as array attributes inside either of the opposing classes.
As a side note (since you tagged it EA): EA offers a drop down in the roles which is fed from attributes of the class. You should not make use of that. This is some heritage and/or a misinterpretation of the definition. As said: its not wrong, but also not good style.
You say you already have two classes with an association between them. In that case, there is a huge difference between adding attributes to one of those two classes and changing the association into an association class with its own attributes. They are not at all similar.
Unnamed properties already exist at each end of the association and are typed by their adjacent class. Adding redundant attributes is unnecessary and would be incorrect.
An association class allows you to record additional facts about a link between instances of the other two classes, such as the point in time the link came into existence. Association classes are like associative entities in a database.
I think part of your question is also about when to use an association vs when to use attributes. The UML spec doesn't provide any guidance on this. However, common practice is to use an attribute only for types that have no identity, such as the number "5", the string "Hello", or the combination of "7" with an enumeration literal of "pounds". In UML, these types are called primitives and datatypes. If you want a property typed by one of those, use an attribute; otherwise, use an association with named association ends.
This my UML class diagram (URL)
In above diagram, ChildParent (or Child1, Child2, and Child3) can only be initialized in MainObject->create_new_object() and store it in class Library through ObjectData->lib->add_object(key, newObject).
So, how to define UML class relationship between ChildParent, Library, and MainObject?
Thank you
Relationships between classes are structural, not behavioral. The MainObject is creating it, but it is not controlling its lifespan nor does it own it in any way. After creating is it handed over to the ObjectData, transported to the Library and stored there. There is a behavioral relationship between the MainObject and the ChildParent object, but there is not a structural relationship between the two of them. I should not depict any relationship between them.
The Library is storing it. This is a typical whole part relationship and structural. What is a library without books? Therefor would I make use of the aggregation type of relation. It is not the composition, because the Library does not control the lifespan of any ChildParent or Child object nor does it imply that the ChildObject will be destroyed when the Library object is destroyed. That might happen, but given the presented data is that not clear to me.
EDIT as a reply to a comment:
Class diagrams show the structural relationships between classes, not their usage. When a class implements an interface, then will you see that relationship in the diagram. In the code (the behaviour) might you not see this relationship, because the implementation is hidden in a factory method or provided by a IoC container or it might even be a relationship that is never used.
What is the relationship between a class (the caller) that is picking a class (the callee) from a library and between the caller and the library?
It is obvious that the caller and the library have a behavioral relationship. If the module changes, can the caller get his callee from some other class. Therefor will the library and the caller have no relationship in the class diagram.
There is a structural relationship between the caller and the callee. The caller needs the callee. Your comment does not specify the exact relationship between them, but there is a relationship. The weakest form is the dependency relationship. An example in connection with a library is that a person is lending a book from a library. When he starts to read the book, is the callee used. It does not belong intrinsically to the person as a whole, but it does belong to a certain method of the person class.
There are a lot of ways to implement a library. It can be for instance a wardrobe. What is the relationship between a person in the military and his uniforms? He needs to wear some uniforms in certain situations, yet in other situations are those uniforms forbidden to wear. Wearing an uniform is a part of the class military. You can not be in the military without wearing an uniform in the time of duty. The moment you are out of the military are you not allowed to wear the uniform anymore. Hence has a military a compositional relationship with that uniform from his wardrobe.
There are more types of relationships possible between the caller and the callee. You can not say it at forehand. You must answer it the same way as any other relationship. The first question is very clear: is this a structural relationship or not? Keywords like 'is a' and 'has a' depict a structural relationship. Keywords like 'uses', 'asks', 'picks from' show a behavioral relationship. Have you concluded that it is a structural relationship, then should you find out what the dependency between the two classes is.
I am writing a system which generates code for a number of classes and I need to document it with a UML diagram. The classes will follow the same structure but they will have names set by the user. Is there a way to specify that CCodeGenerator generates the code for these classes?
Also, I currently have a relationship between my CDataDefinition class (which defines what should be included in each of the generated classes) and the CCodeGenerator, is there a way to denote that the multiplicity of the relationship between the generated classes and the generator is exactly equal to the number of CDataDefinition instances?
These classes will be used in another system which will also need UML class diagrams made for it. Is there a way to show that a class in this project (CEditior) uses them?
Example of operation:
I have 3 CDataDefinition objects which define classes X, Y, and Z. My CCodeGenerator instance will create 3 classes (C# code in .cs files) from these.
CEditor in a separate solution will then interface with these 3 classes.
If you read some of the introductory information on MOF, you will see that in the UML family an instance of a metaclass in one layer is a classifier in the next.
In your case, a class in the code generator describing the class in its output will be a metaclass (CDataGenerator), and the classes in the output represented by instances of the metaclass.
There is no way in plain UML for associations other than 'X is of type Y' to cross between the layers.
You may be able to model such a relationship using MOV QVT (query, view, transform - i.e. a language for mapping one model to another), but I don't know current state of tool support for that, and if you had a QVT tool you probably wouldn't need to be writing a code generator.
You need to build a template class (CDataDefinition) that will represent the structure of a class that can be created by CCodeGeneratorWhen you're creating actual class you do the binding so all you have to do is show that CCodeGenerator has an operation (let's say) classGenerator(name:String) and then you can show that this method creates a class as a proper binding on CDataDefinition.
Take for example:
CreateOrderTicket(ByVal items As List(Of OrderItems)) As String
Where would you put this sort of logic given:
CreateOrder should generate a simple list ( i.e. Item Name - Item Price )
PizzaOrderItem
SaladBarOrderItem
BarOrderItem
Would you recommend:
Refactoring common to an abstract class/interface with shared properties a method called CreateOrderTicket
Or,
Creating a common service that exposes a CreateOrderTicket
We obviously would not want three createOrderTicket methods, but adding methods, inheriting, overloading and using generics seem like a high cost just to abstract one behaviour..
Assume for the sake of a simple example that (currently) there is no OrderItem baseclass or interface..
Help!! :)
p.s. Is there a way to overload without forcing all inheriting objects to use the same name?
Abstract base class sounds like the best option in this situation. Of course it all depends on what kind of shared behaviour these items have. Without knowing more, I'd guess all of these order items have Name and Price for example - and in future you might add more common stuff.
Without a shared base class which contains the Name and Price properties, you'll probably have troubles implementing a CreateOrderTicket method which takes a list containing more than 1 kind of orders.
Also I don't think inheriting from an abstract base class would be that high cost as technically the objects already derive from the Object base class. (Though I don't think this is completely equal to a custom base class.)
VB.Net can implement methods from an interface using a different name than the one specified in the interface but don't think the same goes for overriding abstract functionality.