I need to know this differences in order to undestand how to use them right.
Which are the differences of DFD (Data Flow Diagram) and Class diagram ?And,
Which are the best diagram to build a software?
Thank you..
A DFD is one behavioral view of a system while a class diagram is a pure static one. A class diagram shows classes with attributes/operations and how they are connected. A DFD shows how data "flow" (i.e. class instances and/or plain objects are interchanged) under certain conditions.
What kind of diagram to choose depends on the objective.
DFD (Data Flow Diagram) is a graphical mapping of data structures and their interrelationships (storage, external sources, etc).
In turn the class diagram shows the entities, objects and their relationships.
I recommend first mastering the creation of class diagrams when building software.
Related
I am a beginner in cobol, and I'm passing an internship in big data batch processing, I am asked to do a class diagram in my project, but I have no classes, I only have tables with millions of records in DB2 that are being processed with cobol language, my question is : is it possible to make a class diagram in this situation ? (forigve my english)
Yes, it is entirely possible. An entity-relationship diagram of a database model is practically a class diagram.
Class diagrams are used with OOP languages. I am not sure how far did OO-COBOL go, but I have a feeling that it is not a common practice to use it in batch processing. Batch processing has always been mainly accomplished with NON-OO COBOL in COBOL shops or using C, C++ or JAVA on mainframes and UNIX, of course you could use any other suitable technology...
Class diagram shows classes (no corresponding non-oo COBOL structure for that) and associations between them. If each class represents 1 physical table and no OO features such as inheritance, a class diagram may be very close to an Entity Relationship diagram. However, a class is a code file in OO (or part of a code file) but in non OO-COBOL, a class does not exist and database columns are coded inside the some program of some name that is never shown on the Entity Relationship diagram.
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.
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
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 am wondering how I could model the act of dragging and dropping in UML (class diagrams)
I've thought linking two classes with a relationship (the view and the element) but sounds like awkward, what do you think?
Are you looking to model the act of drawing UML diagrams (dragging and dropping elements in a class diagram) in UML? Or modelling dragging and dropping as an action in general?
If it's the general case. This sounds like a sequence diagram, or possible an activity diagram (although I think this might be less informative). Not really a class diagram, that's low level and structural not behavioral.