I was wondering if any analysts/architects have a solution for the hundreds of CRUD operations I would have to add to nearly every class in my UML diagram.
Do you let each class inherit from a base class that implements the CRUD operations?
Best practices and design patterns about this are very much appreciated!
It is very simple. Don't add them to your diagrams. What value would they add?
The value of UML diagrams should be in explaining complex situations. Important is to decide how much you can eliminate, not how much you can add.
I'd use a stereotype to mark the classes and, if and only if you are going to do code generation, I'd make them extend a base class at the "detailed conception" phase (just before the implementation). But if you're not going to generate code (i.e. if you're not doing MDA and I hope for you you are not), I wouldn't even bother adding the inheritance relation. As Stephan mentioned, the real question is: what are you going to do with this information? What value does it add?
Related
So the question is simple. I just do not find the answer on the internet. I think private methods are useless in diagram, not telling much. But maybe I think wrong.
Private methods are an implementation detail of the class, not its public API.
No:
If you are using the diagram to show the external interface of the class, or some subsystem that the class is part of, then there is no reason to include them. They will just add visual noise and confuse the reader.
Yes/Maybe:
On the other hand, if you are trying to communicate the internal design of the class itself, or its tightly coupled collaboration with another class (think of friend in C++), then it might be appropriate.
Opinion:
UML is not* a 4GL programming language. You use it to convey an idea, design, architecture. You only add information that serves that purpose. It does not have the concept of being "complete". Like text in a book, you only use words necessary for the purpose of conveying the message.
If it is used as part of system documentation, and it needs to show all members, then we just generate it afterwards.
UML is not the goal, it is just a modelling language to communicate with people.
So if it serves the purpose you add it, otherwise you leave it out.
*) some attempts have been made at that, but have not been very succesful (togetherJ springs to mind)
It depends what you're modelling.
In general UML provides a mechanism to show operation (and attribute alike) visibility. As private feature can be depicted on a diagram it is clear that you can present it on a diagram. However if you show it or not depends what you're modelling.
If you're modelling the internal behaviour of the class then yes.
If you're modelling just its external appearance you don't have to (but you still can).
Yes you should include them. It gives a bit more detail into how the class will work. IBM actually have a special notation for private methods - https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/
I would like to know which diagram from those two should be created first when designing large IT system.
In every article I read about UML, the component diagram is mentioned as almost last.
I think that, when designing a larger system is better to divide it to smaller parts/modules on the component diagram and then for every component create a detailed class diagram. Is that correct?
How it look in practice from your experiences?
Do you know of any article/tutorial that shows from beginning to end, the design of system using UML?
There is no mandatory order for UML diagram design - in fact, you will often find yourself creating several simple diagrams of different types, and refining them later. The process is generally iterative but doesn't have a follow a particular order.
That being said, some UML diagrams provide a more abstract view than others, and it may sometimes make sense to start with the most abstract views and work your way down to the most specialised ones. Use case diagrams typically come early, while object diagrams or state diagrams often come later in the design process, once the original, abstract solution has been refined.
You will also want to take a look at consistency between your diagrams: indeed, with several views you will introduce redundant elements, and it is important to make sure that they do not contradict each other. For example, if you have a sequence diagram and a class diagram, any call message in the former should correspond to an operation in the latter. See Alexander Egyed et al's work for automated consistency management and correction in UML models.
I model a system as my school assignment. I use database and Hibernate. I have many persistent Serializable objects. But showing that on a diagram that has approximately 20 classes makes it illegible.
As far as I came up with a solution to split general diagram showing relationships between persistent classes and the one with interface realization. Is it the best solution or maybe there is yet better way?
20 classes does not make it illegible, just large. Splitting the diagram is fine. UML is a modeling language and diagrams are just views so that is not a problem. (However, some implementations are just views, or semi-models like Visio) I would split across data domains, show the path which is important all on one diagram. Focusing on showing the "use", interface, implementation all on one page. Unless the layers are the focus. Split on data domains, clusters of usage, and if it is all one-to-one your solution is fine. In the future a diagram example might help.
I would offer the suggestion of making use of packages and perhaps composite structure diagrams.
can somebody please explains what is a high level class diagram. As far as I know class diagram shows the association between the classes but what about high level class diagram??
Ok, I knew what this means, a Class Diagram contains many details. A high-level class diagram is a simple class diagram reflecting only initial domain knowledge
What's the context? Class diagrams in themselves are pretty "high-level", in that they only show classes and methods rather than algorithms and other implementation details. It might just be an adjective. Or, you might be looking for something more like a block-level diagram which shows components of a system and how they interact.
I often use the term "high-level", or more usually, "top-level" diagram for the very highest level class diagram I make for a system. Usually this will show as many of the most important packages as will reasonably fit, along with some classes that give the best idea of what functionality the classes in that package provide. From there I can do class diagrams of each package, and so on.
Depending on the type of system and what your supervisor want to see, you may be better off creating a component diagram.
I'm drawing some UML in which a concrete class inherits from an abstract class which defines a pure virtual method. Is it required to show this method in the concrete class as well? It's implied by inheriting from the abstract class.
Nope, you don't need to. in fact, in general, don't put any more in the UML than you must have to clarify what you're saying, unless you're (god forbid) trying to generate code from it.
The best guide I know of for UML is UML Distilled by Martin Fowler.
The funny thing about UML is that it has a pretty loose and varied definition. Most things that are called UML are actually not much more that block diagrams. There is a lot of ambiguity in any UML implementation.
I would say that if you are doing this for a presentation or architectural diagram, you can take care of a lot of the possible ambiguity with 'words'. If you will be generating code from it using some application, you should check the docs of that particular application.
It's implied and in fact, many CASE tools would show you the inherited method as part of the list of the methods of the subclass when clicking on the class at looking at its properties (and some CASE tools even have the option of showing also the inherited methods in the diagram)