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.
Related
this question is regarding Object Oriented Analysis and design ,UML
in object oriented analysis final result is the class diagramme of system am i right?
in object oriented design final result is implement the class diagramme in code am i right ?
what is the use of UML diagramms in OOAD?
in object oriented analysis i have seen use these UML diagrams - use case diagram,sequence diagram to create the class diagram
are above diagrams are the only ones that used in analysis(create the class diagramme)?
in object oriented design i have seen used these UML diagrams - class diagram , sequential diagram to used to implement the code(code of the classes)
are above diagrams are the only ones that used in design to implement class diagram in code?
or depending on need other type of UML diagrams are use in object oriented analysis and object oriented design?
in object oriented analysis final result is the class diagramme of system am i right?
No. The result of the analysis is a model that represents the problem domain. Any diagram used is just a means to reflect the model to its readers.
in object oriented design final result is implement the class diagramme in code am i right ?
No. The result is an architectural model which is based on the analysis model. You might be able to generate code from this model. At least a coder can take this model to transform it to code.
what is the use of UML diagramms in OOAD?
UML diagrams are used to visualize the model of the problem domain. You can live without the diagrams, but they support communication between humans.
You will use different diagram types depending on what part(s) of the model you will shed light on.
UML is the toolbox used by OOAD to express the different design phases in a common and understandable language.
Has you know the 3 main phases of the OOAD involve different kind of UML diagrams
Object-oriented Analysis (OOA): Use cases and object models ( class diagram, package diagram).
Object-oriented Design (OOD): Software architecture using design patterns and architectural patterns ... expressed using UML.
Object-oriented Modeling (OOM): used by OOD and OOA. It is separated in two types of analysis:
Structural diagrams: static representation diagrams use cases, packages and classes diagrams
Behavioral diagrams using dynamic diagrams like sequence diagram, collaboration diagram etc.
Object-oriented modeling (OOM) is a common approach to modeling
applications, systems, and business domains by using the
object-oriented paradigm throughout the entire development life
cycles. OOM is a main technique heavily used by both OOA and OOD
activities in modern software engineering.
See the dedicated Wikipedia page for details.
I need insight on how much UML to teach. I'm an adjunct for a "2-credit 100-level introductory course" on systems analysis and design (a contradiction in terms to me). The text is written for the typical 300-level 3-credit class. This chapter covers ~7 UML diagrams, it's already extremely simplistic, and I have to strip it down further. I have one week, or two class hours, to cover it.
I've concluded I can either trash the book and cover class diagrams well, which would introduce them to a lot of basic OO concepts, or I can simply aim for basic recognition of these 7 diagrams (not even expecting them to create any). But I feel like basic recognition would so totally skim the surface as to be useless for these brand-new programmers and the diagrams would run together meaninglessly. Advice greatly appreciated.
The 7, by the way, are: object relationship, use case, class, sequence, state transition, activity, and business process modeling.
There are several UML elements that map easily to code and are therefore straightforward to use as design elements.
Package diagram (translates to namespaces).
Class diagram (translates to classes in OO languages).
State machine (translates to any number of state-based implementations).
Sequence diagram (shows chronology of method invocations).
I would say that this is the minimum useful set of UML elements to teach. If you have time, I would also encourage people to learn use case diagrams, although many people find text documents just as effective for that type of analysis.
I would recommend to focus on class diagrams. They are the most useful type of UML diagram for analysing, designing and documenting (the information, or state, structure of) a software system. You could show how class diagrams define
the properties of an object type, both data-valued attributes and object-valued reference properties (representing unidirectional associations).
if a property is single-valued or multi-valued (by its multiplicity)
other property constraints
inheritance relationships in class hierarchies
You could show how classes can be used for conceptual information modeling (also called domain modeling) in the analysis phase, where they define the real-world object types, and for design modeling in the design phase, where they define platform-independent computational constructs to be implemented in some target programming language.
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'm currently working on a project for my university and one teacher told me I was wrong to think that there could be classes in a UML class diagram (thinking of it as a design diagram) to which there would be no equivalent in a data model. He then pressured me to provide a counter-example to prove my point but I just couldn't think of one.
I checked a few books I had about UML like "Learning UML 2.0," "Applying UML and Patterns" and UML 2 for dummies, but I couldn't find any information regarding which classes appear on a class diagram. I asked him about implementation classes but he told me that they shouldn't be included in a class diagram. So I'm at a loss here.
I also checked this questions before posting:
Differences between a conceptual UML class diagram and an ERD?
Generate UML from a conceptual data model
how to relate data with function in uml class diagram
But they don't really solve the question I have.
Thanks for any insight you might have.
Both your teacher and you are unnecessarily distracted by the differences between UML and conceptual data modeling (which I take to be tantamount to ER modeling). The real issue you and your teacher are discussing is the difference between analysis and design, regardless of the model used.
A UML model can be created that diagrams the problem as stated or that diagrams the solution as designed. In the first case, implementation classes should be omitted, because they do not pertain to the problem domain. In the second case, they should be included. The first case is analysis. The second case is design.
The same ambiguity exists with regard to ER diagrams. Some people, including myself, use ER models and ER diagrams only to represent the data requirements inherent in the problem itself. This is what is most often meant by "conceptual data modeling". In this framework, the only entities that should appear are entities that have a perceived reality in the subject matter itself, and are not merely constructs inside the database or the application(s). This is analysis.
But there are plenty of other people, perhaps a majority, who use ER diagrams to pictorialize the design of a schema of tables. In this framework, foreign keys are included, and junction tables are elevated to the status of entities, even though they are not subject matter entities. There's nothing inherently wrong in this, so long as the distiction between analysis and design is kept clear.
Unfortunately, the distinction between analysis and design is very often obscured beyond recognition. There are dozens of instances of this right here in SO.
So, if a confusion between analysis and design is allowed to creep into the discussion between you and your teacher, the discussion could end up going in almost any direction.
"one teacher told me I was wrong to think that there could be classes in a UML class diagram (thinking of it as a design diagram) to which there would be no equivalent in a data model. He then pressured me to provide a counter-example to prove my point but I just couldn't think of one."
He is right. In the stage of conceptual analysis/conceptual design, those rectangular boxes in a UML class diagram depict "concepts". And whatever the "concept" happens to be, you can always also draw an E/R diagram around it to illustrate (the nature of) that concept, other concepts that relate to it, and what the nature of those relationships is.
From my understanding of UML, it does NOT define what should be in a diagram. I found this example in the IBM site: (image did'nt lode, so here is the link: http://www.ibm.com/developerworks/webservices/library/ws-RESTservices/)
Surely, a servlet is not part of a domain model.
A UML class diagram us used to model classes, which are entities that have attributes and methods. IMHO, it doesn't matter if they are part of the domain model or are functional classes that support the application. If you need to show them to the customer, they must be there.