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.
Related
Can someone briefly explain the difference between a Conceptual Class Diagram and a Detailed Class Diagram?
While a "Conceptual Class Diagram" expresses a conceptual (domain) model, it's not clear what you (or your professor) mean(s) with "Detailed Class Diagram": it could refer to a (language-/platform-independent) design model or to an implementation model like a C++ class model or a Java class model.
See also my answer to this related SO question.
The one-to-many relationships between conceptual models and design models, and between design models and implementation models are illustrated in the following Figure:
As an example that illustrates how the derivation chain from concept via design to implementation works, consider the following model of a people/Person concept/class:
Domain models are solution-independent descriptions of a problem domain produced in the analysis phase of a software engineering project. The term "conceptual model" is often used as a synonym of "domain model". A domain model may include both descriptions of the domain’s state structure (in conceptual information models) and descriptions of its processes (in conceptual process models). They are solution-independent, or ‘computation-independent’, in the sense that they are not concerned with making any system design choices or with other computational issues. Rather, they focus on the perspective and language of the subject matter experts for the domain under consideration.
In the design phase, first a platform-independent design model, as a general computational solution to the given software engineering problem, is developed on the basis of the domain model. The same domain model can potentially be used to produce a number of (even radically) different design models representing different design choices. Then, by taking into consideration a number of implementation issues ranging from architectural styles, nonfunctional quality criteria to be maximized (e.g., performance, adaptability) and target technology platforms, one or more platform-specific implementation models are derived from the design model.
A conceptual class diagram is used to understand and analyze a problem domain. A detailed class diagram is a design artifact, where many things may have been optimized away. For example, every dog might bark, but a dog-salon application doesn't care, so it can optimize away that fact.
I don't know of any standard or methodology that defines both these concepts. For example, the UML specification does not mention them. I think every answer will be subjective. I will give my own answer, based on more than 25 years of experience with IT-related modeling.
In a conceptual class diagram, every class is a concept, usually related to the business domain, the real world, e.g. Customer, Order etc. It may also show concepts that cannot be directly found in the business domain, but are needed to model the functionality of a particular application, e.g. BackupCopy. These are concepts the user of the application must understand. See also www.agilemodeling.com
There are other types of class diagram, e.g. class diagrams that model the source code, where every class corresponds to a Java class or a C# class, or class diagrams that model the physical database structure, where every class corresponds to a database table.
Each of these types of class diagrams may or may not be detailed. If a class diagram is not detailed, it typically does not show any attributes, or only the main attributes. If a class diagram is detailed, it shows all attributes relevant for the problem at hand and the data types of these attributes.
The concept of a conceptual class diagram is e.g. explained by Scott Ambler at http://www.agilemodeling.com/artifacts/classDiagram.htm#ConceptualClassDiagrams.
Basically "Conceptual" here means that the content of the diagram is taken from an analytic view point that takes the "concepts" of a domain and describes them.
For "concept" you could also say:
thing
item
aspect
object
topic
The conceptual diagram is basically what you get if you ask people for what problem they'd like to get solved by your software. So you analyze the situation/problem by asking questions that will help you create you diagram:
what are the things that are relevant? - these will be your candidates for classes
what are the features of those things? - these are the candidates for your attributes
how are the things releated to each other - e.g. is one part of another? Does it need the other? - these are the candidates for your relations
what should you be able to do with these things in your system ? - these are the candidates for your operations
In the past this step was called OOA - object oriented analysis. The steps following this are OOD - object oriented design and OOI - object oriented implementation. Many years ago some authors proposed to create three different models for OOA/OOD and OOI. Therefore you'd have different and usually more detailed diagrams for OOD and OOI. For the term "Detailed Class Diagram" i'd guess that one of the OOD and/or OOI views would be meant. Be careful though - some of the diagrams created this way will have patterns or pattern-like ideas as a basis. You'r diagrams would tend to be very repetitive and redundant if you keep capturing such patterns in concrete diagrams for every conceptual diagram. I'd rather recommend to give just one example of how to go from problem to solution and then comment "do it this way for all other concepts that are similar".
I am not sure if this is a good question as I'm unsure if there's any agreement on the subject. However due to the lack of information in the internet I'm compelled to ask anyways.
Let's say I'm making a system that is mainly object-oriented, with its corresponding UML diagrams (use-case, class, colaboration, etc). However, none of the UML diagrams are helpful when dealing with the database, which should be relevant for the developing team so they can know what exists in the database and what does not.
There are two ways to represent a database: Entity-Relationship and Relational (it's unknown to me if there are more, but those two are relevant within the relational database paradigm). ER deals with the representation of the BD in terms of business rules, and Relational deals with the actual, physical implementation. But none are "UML standard" (unless I'm missing something here).
Which modeling should I use, and why? Is ER relevant in terms of UML, or should I stick to relational? Thank you beforehand.
If you want to use UML only, you could use limited class diagrams - without m-n associations and methods. But if you are using some class-table mapping tools, you can use anything, except m-n relationships only.
Nobody had ever said that you can use Class diagram for OOP classes only. You can use them for any more or less formal concepts, if their needs can be covered by the complex of CD elements. I use class diagrams for UI planning and even formal text planning. And tables are very close to classes. So, no problem.
You can use data model diagrams, if you need something that is CALLED data diagram. But they are covered by class diagrams fully. That is the reason they are not supported anymore.
Your task is to make the model understandable for everybody, who can get it in hands. Class diagram is the most widely known UML diagram. A good title and a pair of comments will resolve all possible misunderstandings.
Both are different ER diagrams are relationship of entities and UML diagrams are behaviour of Ojects how they communicate with each other, as per my view point DFD (data flow diagram) is option. It has different levels which is based on number of processes and will better explain about data entities.
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.
If I create a conceptual class diagram such that each class captures 'name' and 'attributes' but not 'operations', have I not basically created what would be otherwise considered an ERD? I'm trying to gain an understanding of what the differences are between creating a conceptual class diagram as I have described versus calling it a ERD? If these are still two different animals, can somebody please explain what the differences are?
The class diagram contains just the classes in your object model with eventual links/relationships connecting diagram elements. However those links don't necessarily correspond to physical relationships like in an ERD diagram, but instead they represent logical connections.
The class diagram is just the object model of your application and does not contain any persistence-specific information. When you think about the class diagram forget about the database or any other storage you may use.
The ERD diagram on the other side, is a persistence-specific diagram which display the entities (tables) existing in a (most often) relational database. It also displays the physical relations (and cardinalities) between those tables and all other database-specific information. The ERD diagram can sometimes look similar to the class diagram, but that doesn't mean is the same as a class diagram.
There´s little difference in the expressiveness of both (if we just focus on the attributes, classes and associations part) if you use Extended Entity Relationship diagrams (the most common case nowadays)
True, they look very different at the graphical level since they use different symbols for the elements but the "semantics" are quite similar. They both allow inheritance (again, I´m talking about EER), n-ary associations, association classes, ...
The ER diagrams I've seen (most frequently ERWin IE notation) have focused on the design for a database. They are concerned with primary keys, foreign keys, have unnamed relationships, and usually have no generalization / specialization.
A good UML conceptual class diagram, on the other hand, is not concerned with keys, reflects the problem domain, and has association-end properties that at least hint at the semantics of why things are related. This helps communicate the domain down to more junior developers so they don't have to guess.
It depends on the situation where you may not like to do the ER-D. But imagine if you have a seperate data layer where the data logic is handled. In this case many details of data shall not be shared with the application layer. And you class diagram shall not go beyond the application layer. I must stress that both the diagrams are not equal. And there are situations where you need to do both, mainly in multi-tier architecture, and there are situations where you may be able to just use class diagram; e.g. single-tier application.
I strongly advocate the view that class diagram doesn't abrogate the E-R diagram.
Design class diagrams are made from conceptual model and collaboration diagrams.
Design class diagrams include:
Classes, associations and attributes
Methods
Types of attributes
Navigability
Dependencies
IMO In Simple terms
Class diagram depicts the details of how will the system work.
ER diagram depicts how the system persists 'state' as a blue print.
Goal:
Detail out state and behavior of the components(classes) of the system.
Design 'efficient', flexile system(less coupling and more cohesion) using Solid principles.
Goal:
Design a blue print of how to 'efficiently' persist the state of the system.
Consider what kind of queries will be made (read vs write), are there any joins required
consequently figure out the columns for indexing
Use Normalization, ACID properties.
PS: notice the both the diagram tries to efficiently do thing in their on respect.
I had some questions regarding the structure and behavior of a model, using UML, and the relationship between the two :
Did you find any limitations for UML regarding the specification or understanding of the relationship between structure and behavior?
I was wondering if you have any practical ideas of how one can optimize the relationship between structure and behavior, using UML.
Do you know any UML tools that help understand better this relationship or represent it much easier?
Thanks
Yes:
A sequence diagram is readable at a high level, showing how a transaction involves a few components; but it's not good (not readable) at the detailed level, showing how a transaction involves dozens of methods (method A calls method B, which gets data from methods D and E, and then invokes method F, etc.).
Looking at a class diagram, you might see a based class with several subclasses; this tells you nearly nothing about the behaviour of the classes (it only tells you that they may have some behaviour in common, or at least a common API, plus some individual behaior that's unique to each subclass).
That's a big question. A quick answer is, "Attach text notes to the objects: diagrams aren't sufficient without descriptive text."
No, I don't really; a UML tool help you create UML diagrams (and generate code from the diagrams), but it's up to you how you use it. There was a neat product described in the book titled Real-Time Object-Oriented Modeling (1994) which was an executable model, i.e. the model itself had behaviour, but I know of no UML tool quite like that. The closest I know of is being able to "round trip" between the model and code (i.e. generate code from the model, and the model from code).
Sounds like a homework problem. Wiki can tell you all about UML.
The limitations of UML are the same as any form of communication. The simpler your language, the fewer things you can communicate and the clearer your communications will become. A shape like a square or circle identifies a structure, a line indicates relationship, an arrow indicates movement, or flow. You could enhance this by defining the meaning of other properties, like direction, boldness, color, number count, different shapes. You could incorporate multimedia layers like audio or video, motion, tooltips- but now we're not talking about UML anymore.
My favorite UML tools are a whiteboard and some dry erase markers.
I think that things have changed, regarding UML's usefulness to melculetz.
In Visual Studio 2010, I can define an association relationship, that will generate composite classes. I can specify the multiplicity and class qualifiers. I can also generate classes from the model.
Presently, I am attempting to visually model the phases of a system, in order to visually define the methods for a state-machine object. That is my attempt to integrate structure and behaviour. Check my blog to see how I get on.
Class Analyser visually expresses the behaviour of class objects. Limitation removed.
I think that the answer is to turn your development methods towards MDA. You will generate more classes, but the payoff is in terms of manageability and re-use (where you template your efforts).
I am still working through my model but, I find VS2010 promises good tools for managing the development process. I have yet to investigate UI modelling, but have heard the rumours. I may have it all wrong but I think that, by working with Lightswitch, I may be able to model the UI also.
UML allows you to specify the signature of a method, and group methods into classes, but it says nothing at all about what code you use as implementation. If that's what you mean by "behavior", I don't think UML addresses it at all at the class level.
It's even worse at the UI level. My impression of UML is that it's woefully inadequate for specifying UIs.
I think the effort required to embed everything into UML is greater than or equal to coding the application, with the added burdens of UML tools being poor IDEs and inability to prove correctness of UML the way you can with unit testing.
UML is way oversold, IMO. I consider it a convenient notation for informal communication between developers, nothing more. It has never been and never will be the object oriented equivalent of engineering drawings.