I know that UML is a general-purpose modeling language, but is it being used as a data model for describing a database like ER? Or is it being used only as a notation for entity relationship diagrams?
I mean: which data model tool would you use when you have to design a database for a company?
is the ER model still being the best choice?
Both can be regarded as equivalent when modeling database schemas. In fact, most database tools offer now both notations as alternatives when modeling the database.
I offer a more (personal) opinion on the differences between the two here but from a practical point of view use the one you prefer (and forget about a purist interpretation of their semantic differences)
Related
Are Entity Relationship Diagrams(ERD's) considered a type of UML diagram or are they a separate thing?
I have another idea. I think we should look in-depth.
When we are talking about ERD (Entity Relationship Diagram), we are talking about Entity Relationship Modeling.
It is firstly introduced by Peter Chen (1976). He has two famous articles on Entity Relationship Modeling (see first and second articles)
He talked about Entity-Relationship Modeling (not Entity-Relationship Diagram). It is ER Model.
There is another paper in 1975 about Modeling the Real World System.
ER Modeling is (see reference, the second paragraph):
In software engineering an ER model is commonly formed to represent
things that a business needs to remember in order to perform business
processes. Consequently, the ER model becomes an abstract data model
that defines a data or information structure that can be implemented
in a database, typically a relational database.
Diagramming Convention Techniques
When we are talking about ER Modeling, there many diagramming convention techniques.
Chen Notation (some links need translation)
IDEF1X Notation
Bechman Notation
Martin notation
(min, max)-notation of Jean-Raymond Abrial in 1974
UML class diagrams
And other notations (see reference)
All of above notations are using for ER Modeling or Data Modeling.
There is no earth-shattering difference between UML notation and other ER notations. They all model the most important elements of data models.
Finally: UML is a set of standard graphical tools to model the whole or parts of a project. We can use UML (Class Diagram) for ER Modeling and name them our ER Models or ERDs. So we can say: this is my ERD in UML Notation.
ERD is it's own thing. It's not in UML specification. You can download specification PDF from the link.
UML is a common notation/language for object oriented modeling and it includes a multitude of diagram types. ERD is a diagram for data modeling (attributes and relationships). Some structural UML diagrams are fairly similar in what you can model, but the concept is different.
Types of UML diagrams:
This was the first search on Google:
Key Difference: UML stands for Unified Modeling Language. ERD stands for Entity Relationship Diagram. UML is a popular and standardized modeling language that is primarily used for object oriented softwares. Entity-Relationship diagrams are used in structured analysis and conceptual modeling
UML, as an object oriented notation, have nothing to data modeling. Lots times I read about attributes as data columns. It is not true. We can put to an attribute simple data or any complicated other object.
For data modeling (database, relational database) we use ERD diagram, for storing data in object systems we can use ORM (object relational model), it is mixed UML/Data model, if we use pattern like a active table or active record.
I have a different opinion to Jarek. There is nothing stopping you modelling data using UML. Remember that UML is not new at its foundations, It represents the evolution of a number of types of diagrams which had already existed (ERDs included), and an attempt to standardise these notations to create a consistent language for the communication of system design.
ERDs are used to model (largely) a static model of a system. They show (unsurprisingly) the relevant entities in a system and articulate the manner in which they are related.
In UML Class Diagrams were born from ER diagrams to represent the relationship between classes. If you consider that (in its simplest form) a class is the combination of data and methods, by ignoring methods you are left with a data model (albeit with a syntax which varies from traditional ERDs).
So ERDs correlate to Class Diagrams in UML if you choose to exclude methods and those aspects of the model designed to indicate data protection.
However UML itself serves a broader purpose, as a family of modelling tools that collectively can be used to model both the static and dynamic nature of a system.
It includes diagrams that facilitate for a more complete model of a system than you can get through describing its entities (or data):
Class Diagrams for static object relationship modelling,
Object Diagrams for dynamic mnodelling of object/instance relationships
State Machine/Diagrams for modelling how a system transitions through states
Sequence and Collaboaration diagrams to demonstrate how components of a system will work together
Activity Diagrams (replacing flow charts) to demonstrate/document imperative flow
and a few others I'll leave you to investigate (check out http://www.agilemodeling.com/essays/umlDiagrams.htm for an overview)
I have a different opinion to Andy. In UML Class Diagrams you describe relationship between two classes. With ERD you can talk about relationships between more than two entities.
This is the reason why the cardinality in Chen-Diagrams are on opposite site compared to UML Class Diagrams. You have to think about number of relations for every single entity.
Let's take a look at one simple example:
In this little example every supplier must be in relationship with at least one delivery. But there can be items not being delivered and projects without any deliveries.
Please help me know as to when it(uml) is necessary. I was told that generally UML are drawn for web based application developement, for desktop based, DFDs and ERDs are used. My university requires all the diagram(uml,dfd,er). please let me know if my information is correct? Thank you
UML Diagram are imporant because it help the person to understand the relationship and dependency between different class present in the code(Class Diagram).
Flow of the program(Sequence Diagram , Activity Diagram).
Help to improve the program architecture etc.
And read about different type of UML diagram you will get more information.
Your needs in using UML depends on your position and your (self)education.
Some companies use UML. So, you would need it to get a job in them. Just now your university requires UML diagrams, so there IS a need in them, isn't it?
If you know UML a bit, you could understand the thoughts of your colleague who wants to share them with you this way.
If you understand the language of a UML diagram, you can use it for improvement of your thinking on the problem. So, you can think into the problem deeper and faster than without a tool. You should be really well acquainted with the tool though, for when inventing something new, you need to think on the domain problem, not on the language problems. But you don't need to know all the rules for this level of use yet.
If you know UML so that you can draw diagrams up to their strict rules, you have two more uses of it.
Translating your knowledge of the problem from one level of abstraction to another and modelling these levels up to the strict rules, you are filtering many misunderstandings in the already accepted model and can practically debug the model before coding. It can save much time and money.
While you are making the diagrams according to strict rules, you can collaborate on the model with your colleagues. It is always better if you can express your ideas more precisely.
As for technology limitations, you can use UML very widely, even out of the IT needs. As for IT, only GUI creation is supported badly. And anonymous classes are almost not supported in class diagrams at all (in behaviour diagrams they work OK).
DFD (datya flow diagram) and ERD (entity relationship diagram) diagram are tools for structural analysis and design, this is way to build structural application (data bases and functions). UML support quite different paradigm: object paradigm - we build application as collaborating objects. DFD and ER (ERD) diagram is not part of UML. We can use ER diagram for data base modeling and join to UML domain model by the ORM (object-relational mapping, implemented e.g. by Hibernate).
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.
Can someone briefly explain the difference between a domain class diagram and a design class diagram?
I found a explanation on Yahoo answers,
but I find it quite confusing.
A domain model is called conceptual model in database modeling, while a design model is called logical model.
These distinctions are also used in model-driven development, where we have a succession of three types of models:
(solution-independent) domain models resulting from domain/requirements engineering in the system analysis, or inception, phase of a development project;
(platform-independent) design models resulting from the system design activities in the elaboration phase and typically based on a domain model;
(platform-specific) implementation models, which may be (e.g., JavaScript or Java EE) class models, SQL table models or other types of data models derived from an information design model.
While system modeling includes both information and process modeling, you seem to be concerned with information modeling only. Here, we can use the terms "domain class diagram" and "design class diagram" for the conceptual information model and the information design model made in the form of UML class diagrams.
The one-to-many relationships between conceptual models and design models, and between design models and implementation models are illustrated in the following Figure:
Considering information/class/data modeling we get the following picture:
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.
See also the Open Access book chapters Information Modeling and Deriving a Table Model from an Information Design Model.
If your focus is on the diagram itself, there are two big differences between diagrams about domain model and diagrams about design model: (At least this is what the Larman book Applying UML and Patterns says)
In UML diagrams which represent domain model, you cannot use arrows. All classes are interlinked with a line, which signifies "relation", and you should use text annotations over the lines to illustrate what relation it exactly is. While in design models, you have to use arrows, all types of arrows: association, inheritance... etc
In design model you have to specify the type of properties and methods etc, while in domain model you only have to write them without anything additional(just like in real world). For example, value: int in design model will be written as value in domain model.
Reference: Applying UML and Patterns 3rd Edition Chapter 9 and 16.
UML has NO such diagrams
Enterprise Architect has Domain Model - look at wiki.
As for "class design diagram", it is simply unknown neither by EA, or by VP UML, or UML itself. I think, the usual class diagram form the UML is meant.
I have learn about Object role modeling but not about Object-relational mapping and I want to know if they are two ways of doing the same thing and what are the pros and cons? To me Object role modeling makes a lot more sense. Could you make a brief but easy to understand comparison if they can be compared. Cheers
Object Role Modeling: software modeling notation to, specially, define domain models. You can think of this language as an alternative to using UML class diagrams to design your database. More info here: http://www.orm.net/
Object-relational mapping: a set of strategies to bridge the gap between object-oriented programs and relational databases. It aims to allow the persistent storage of objects in a relational database structure
Object Role Modeling was invented by a team at Control Data around 1973, and named by Falkenberg. It is a modeling method rooted in linguistic analysis, and was formalised as a first-order logic by Terry Halpin, see http://orm.net. ORM is thus the original user of the acronym. ORM and related modeling languages are distinguished by being attribute-free. These languages contain only objects and object types (kinds of things), facts and fact types (relationships between individual things) and constraints (rules about what things and relationships may exist). No relationship has the master-slave characteristic like entity-attribute - this is a notion that only arises during physical mapping, as it's irrelevant to the underlying semantics of the domain.
Object Relational Mapping (which I always write O/RM) is a name for a method or family of tools that help translate data between relational form and object-oriented form. Both these forms use aggregate or composite things based on attributes (entity/attribute or object/attribute), but the principles for aggregation differ between the two approaches, so the same underlying semantics results in different data structures; hence the need for tools to help automate the translation. Furthermore, in ER or O-O analysis, the need to make early decisions about which things are objects/entities and which are attributes is forced, and this gives rise to a whole class of modeling errors that simply does not occur with ORM.
Of course, both relational and o-o models can be automatically derived from an ORM model, and the mapping between the derived forms is also automatic and painless. I suppose that's not done more often because it would make life too easy.
You are comapring Apples to Oranges.
Object Relational Mapping is all about trying to overcome the impedance msimatch between the object world and relational databases.
Activerecord for example is a ORM that wraps a row in a database.
Hibernate is another popular ORM
Just google for ORM wikipedia explains it much better
http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch