I'm designing an online music website where there are two main objects: User and Music. There are many operations users can do to music,like they can upload,listen to, collect,share and download a music. If I draw an UML class diagram, the diagram would look like
:
So my question is that is it OK with so many associations?
Those are not association, but methods which are to be defined in Music. You probably have just one association between both.
You might want to synthesize some use case cases first:
Based on this you can create a class model:
And detail this with behavioral design:
Having many associations between two classes is allowed by the UML standard. Strictly speaking, you should then add to each association role names to distinguish them when navigating from one class to the other.
The model you have would be acceptable for a model of a problem domain. If this model is intended to be a model of the solution domain, you might have one association with operations representing available actions, or signals representing completed actions.
Since you use the class User, you are probably trying to model the solution domain, though. That suggests you should use operations or signals.
Related
So I have to make a class diagram for a Unity game I made as part of a project.
Trouble is I have to make a class for every script, of which there are 60.
The guidelines given to me simply states: Create a class diagram of your game.
So should I be splitting this up into several different class diagrams or literally just one inevitably disgusting 60 class diagram?
Your guidelines already told you what to do for this project: "Create a class diagram of your game." If this is a class project, create a single horse blanket, make your professor happy, and get a good grade.
However, on a real-world project, you should create many micro-subject-area diagrams for your audience. Review with each person only the diagrams that matter to them. That's how you (and your victims) can survive very large projects.
To create micro-subject-area diagrams, create a set of diagrams, each containing 7 ± 3 classes. Every class has only one fully-defining diagram showing all of its compartments and associations. Everywhere else, the class should appear only with its class name (to help define other classes) and a hyperlink. The hyperlink makes it work like an edge connector that takes you to its fully-defining diagram. (If you use MagicDraw, there is a free plug-in available, called AutoStyler, that automates this.)
It is legitimate to split up class diagrams, as class diagrams are meant to clarify things, which a gigantic mega class diagram arguably does not do. As such, class diagrams should usually concentrate on a few specific aspects that you want to show:
Do you want to provide a detailed structural representation of a given set of classes? If so, only depict these classes with all members, but skip any other classes (e.g., do not draw them as class nodes, but instead just mention their names as member/parameter types where appropriate).
Do you want to provide the class structure related to a particular functionality? If so, draw the relevant set of classes, but skip irrelevant members (e.g. members that have to be there for the sake of infrastructure support, but that are not a part of the actual business logic you are focusing on).
etc.
Now, when there is any expectation of completeness rather than a mere overview, it needs to be clear what parts of the diagram are complete and which ones are abbreviated. Again, this is possible in various ways:
As in the first bullet item above, mentioning a type name without drawing it is a clear indication that there is another type that is not depicted in the current diagram, without making the depicted class incomplete.
Alternatively, you can make use of "natural boundaries by abstraction" in your code: If you use classes from an extensive hierarchy, it may be sufficient to draw only the base class, or a few general base classes, in one diagram, while detailing the actual class hierarchy (without any of the context from the other diagram) in a separate diagram.
Two remarks on your specific question:
In your case, "60 scripts" sounds like various of them may easily fall into the last case, allowing you to separate overall architectural diagrams from a class hierarchy diagram.
You say there are "guidelines". If this is for some kind of competition or for any other kind of evaluation (e.g., for studying), take all this advice with caution: Internal grading guidelines might not necessarily be congruent with what would be practical/useful in an actual project.
tl;dr
Create as many class diagrams as you need
Avoid wallpaper diagrams only
Create wallpaper diagrams, though. But assemble them from existing diagrams.
Try to spot sub-domains (things that belong together) and place them in one diagram
I am a student and we have a Object-Oriented Project that we have to do to pass Object-Oriented course. My problem is to design the project. Teacher wants two different class diagram.Teacher said "One is high level, other one is normal class diagram." I know that high-level class diagram have detailed information such as attributes and methods. Additionally, I think high-level diagram covers normal diagram. What is normal class diagram? What is the difference between high-level and normal class diagram? I think that if we draw a high-level diagram normal diagram is redundant. Why Did teacher want normal diagram? I am confused.
There are typically 5 "levels" of design that one should think of, so that is where the "high-level" comes from. They are usually like this:
Software System - This is where you think of the software in terms of entire packages, or in terms of its subsystems.
Subsystems - This is the part where you ID all of the major subsystems, such as database, user interface, reporting engine, etc. This is the part where you define how each subsystem uses one another, and how they work together.
The first two are probably what your teacher meant by "High Level Design".
Classes - This further partitions the subsystems by classes. For instance, if you had a database system, you might have a class that manages the persistent connections, the metadata, etc. The way each class works with classes in other subsystems are also defined. This is probably what your teacher means by "class design".
Below that, you further divide each class into routines and internal routines, but I assume your teacher does not want you to get that detailed. However, for completion's sake, I will define them:
Routines - Design at this level includes dividing each class into routines. It is the "how" to the "what" answered in level 3.
Internal Routine - Design of the individual routines.
Why and how are dependency relationships used?
I've come across a PiggyBank example where the Analysis Model consists of a class diagram with dependency relationships.
They use two relationships "use" and "instantiate" to describe the relationships between the classes.
I don't agree with the relationship that the boundary class TransferMoneyForm has a "use" to the TranferMoneControl. I believe it should be the other way around.
Can someone exaplain to me how these two relationships should be used. Thank you in advance.
The diagram shown there is not a correct and full UML class diagram. In such all the associations and generalizations should be defined, and what is abstract, what is public or not. To show what descends from what, what is hidden, what will be never instantiated and what fields of one class has types of other classes. Here we see only information about the
functions.
And it is logical. If you'll look at the previous chapter, there is written: "A control class represents a self-contained process..." So, they are talking on processes, not classes, instances and fields.
It is NOT a class diagram. And nowhere is said that it is. It is named "Transfer Money Participants diagram". They do use the elements of the class diagram, but not to the fullest and so create something more common. It is some approximate undefined diagram on some classes, something between class, communication or component diagrams. Maybe, it is the old style of IBM? Experts (What's the best UML diagramming tool?, 1st answer) say, "IBM Rational Software Architect did not implement UML 2.0". )
As for the question, who uses whom... According to Sparx VP UML, a "usage dependency" is a "relationship in which one element requires another element ... for its full functionality". According to wiki, "The client element somehow "uses" the supplier". Here the form hasn't sense without the controlling class, and vice versa. So, I'd say, the use goes in both sides. But more honest would be to create a normal communication or component diagram. The class diagram has NOT an element to say about sending and accepting the messages. And the "use" is definitely not for it. And when they have decided not to use logic, they can put there virtually anything.
If you are making a class diagram and one your class uses function(s) of another one, that is the case to draw a use dependency connection.
I have two private data structures and five functions in my class, How can I represent the relation between the functions and the data structures in class. Eg: Two of those functions uses the First data structure and three other functions uses the second data structure.
Also How can I represent relation between the functions in the class. eg : among the 5 functions two are public and three are private, one public function in the class calls the other three private functions.
If this is not relevant in class diagram then what is the best solution to represent this in UML.
the interaction of functions and fields is not displayed in a Class Diagram.
Therefore you should use a sequence diagramm. But normaly you do not show the interaction of fields within an Object. You display the interaction on the level of function calls between Objects.
Two things. First, there's a good reason UML doesn't provide notation for depicting relationships & structure within a class. Classes are supposed to be cohesive abstractions of data and function. So if you have any significant structure within a class, you should question whether it should be split into 2 (or more) cohesively abstracted classes.
OK. So that's the backdrop. From your description, how about:
Draw one class for each data structure with one attribute for each structure member
Add a method to each class for each function that operates on the data structure
Add an association between the classes that captures their relationship
Place all the bits above in a package to represent the module
The final point - as in all these things - is to use the tool to illustrate what you want. Don't be overly constrained by the rules of the modelling language. The important thing is that the diagram communicates effectively to you & your collaborators. Satisfying the 'language lawyers' should be much less of a consideration.
hth.
I am trying to figure out if it is correct to put in the fields of the particular class a reference to an object/collection that this class is related with.
Let's say I have a class University that aggregates many instances of Student class. When I put on my diagram both classes, I add the relationship of aggregation between them.
And now the question: Can I add in University a field like 'students : Student[]'? Do I have to? Or maybe I must not?
Thanks in advance,
Piotr
Attributes own association properties in UML 2. This is new and it is not always easy to understand the concept. I didn't understand why we need an attribute till I have seen the following demo.
The golden rule is that attributes should be created in order to save association information in the model. I have found an interesting teaching session on association and aggregation in UML 2.
It is a 2m30s flash demo
http://www.download-omondo.com/AggregationAndComposition.swf
The above association creation is for expert level, I mean modeler who wants clean design and clean model as well as perfect metamodel. If you don't care then just create an association at model level and it would do the job but the code generation will not be done. It means that mappings for database will needed to be created at code level later by developers.
To understand the difference between both kinds of associations see this other flash demo at: http://www.download-omondo.com/association.swf
It depends on what you are doing with your model, but generally, you shouldn't have to use an attribute for this, you can use an association instead. Associations are able to contain more information that attributes, such as whether they are composite or shared, which ends are navigable, multiplicity on each end, named endpoints, etc.
One benefit of associations is that one association can actually represent a property on each class it is connected to, while an attribute only represents a property on the class it belongs to.
So, in your case, University has Students, so you'd draw an association from University to Student, naming each endpoint and setting the multiplicity correctly.
Now when you go to generate code from your model, just be sure to take into account associations as well as attributes. This way you won't need to add the properties both as attributes and associations, just as associations. I have a few diagrams I've tested this approach with, generating sql and php code from the xmi via an xsl transform, and it works quite well... if you'd like more details I can dig it up.
There are 3 types of relations : association, aggregation and composition. composition is a specialization of aggregation, aggregation is a specialization of association.
Using one or the other depends on the phase of your analysis. You could just use association in first draft and then refine it later to aggregation or composition, the difference with aggregation is that a student had no meaning out of one University Universe. If there are several universities instances, it would be aggregation rather.
If you use relations, there's no need to and you shouldn't add students[] because it is redundant. And if you do that you lose the semantics of the 3 types of relations.