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.
Related
Can someone explain me the difference between class diagram during analysis and design?
So far, I understand that the class diagram of design would be the real class diagram, with all methods and attributes (ready to become code), but what about analysis? Do I have to do a class diagram for every sequence diagram? Do I have to add methods and attributes at the design stage already ? Or only connection?
The UML class model is produced and refined iteratively as the understanding of the system increases. There's only one model for your system, although different diagrams may outline different aspects and level of details of this model.
Typically you would start with the domain model based on the requirements (e.g. use cases, user stories, statement of work, user interviews, etc.):
Top priority is to get an overview. So the first sketch would identify the domain classes and how they relate to each other.
You would then enrich this initial understanding by outlining in the diagram the key properties and methods that are essential to the understanding of the domain.
You would then enrich the model with more detailed design diagrams as you design your solution. So you would add any classes required for the implementation (e.g.user interface classes, application controllers, persistence layers, etc.).
Design diagrams are used to get a shared understanding about the software structure within the development team. So they should be easy to understand (i.e.focus on important aspects and not necessarily be cluttered with too many details that would anyhow have to be implemented in code and quickly be outdated if you don't have an army of analysts to update the model).
If you'd use an UML tool able to generate code or if you are contractually obliged to provide all the details in UML form, you would further refine the model with a fully detailed implementation diagram. Attention: for scholar work it is frequent that the teacher asks for a design diagram but expects in reality an implementation diagram.
We have 3 major types of class diagram in Object Oriented Methodologies.
Class Diagrams in Requirement (Domain Modeling)
Analysis Class Diagrams
Design Class Diagrams
Main difference of these class diagrams is their Abstraction.
In Domain Modeling, we use Class Diagrams. BUT, we do not use any Inheritance or any Interfaces, or any preforming analysis on the classes. We just write so little attributes of classes (about 3 attributes). we don't write any methods of classes. WHY? because of Abstraction. Main goal of Domain Modeling is modeling the domain. And detect Which classes should be in problem domain of system.
In Analysis modeling, we use class diagram. Classes in analysis is more detailed than classes in Domain. But it is not the final specification.
In Analysis, we determine Analysis Classes. We can use Inheritance between them. We can write their attributes and methods in detail. BUT, this phase is done by System Analysts. (Not System Designers or Programmer). Their profession is both knowing the Business Logics and Software Techniques. So they can write analysis classes in more detailed than Domain. However, they can not write very detailed as System Designers can.
In the other hand, we can use some analysis patterns to determine our Analysis Classes. For example RUP introduce Boundary/Control/Entity pattern. If we decided to use an existing analysis pattern, we can use the guidelines exist in the pattern documentations.
The guideline of Boundary/Control/Entity about the abstraction of classes are in this reference. In this pattern we should write only attributes for Entity classes and write only methods for Control classes and write attributes and methods for Boundary classes.
However, In my idea, we can follow the guideline or not. We can write more attributes and methods for analysis classes. What is happening? If our System Analyst try to write more detailed attributes or methods, what's happening:
I think that 1) our system analyst is not system analyst. maybe system designer. 2) we don't need their details. It is just time consuming for analysis phase. 3) ONLY if our analysis and design team are the same, or we combine analysis and design (like Agile Methodologies) the details in Analysis can be logical and useable.
In Design modeling, we use class diagram, this type of class diagram should be the final specification and should contain all attributes and methods. This classes are not conceptual. we can use all OOD technologies, Design Pattern and etc.
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 read about domain model and its importance and I have the following doubts :
What kind of problems can one resolve with domain models? in other words,for each problem I should build a domain model?
As far as I know, The domain models are represented using class diagrams .there is no difference between class diagram and domain model?
I also would like to understand In which way is vocabulary related to a domain model?
What kind of problems can one resolve with domain models?
Pretty much any problem that you want/need to provide a software solution for is amenable to modelling. In fact: however you do it, you must 'model' your problem domain in some way, shape or form. If you don't capture the rules and policies of the problem in software somehow it's pretty unlikely the end system will meet its intended requirements.
in other words,for each problem I should build a domain model?
It depends what you mean by 'build a domain model'. See above and below...
As far as I know, The domain models are represented using class diagrams .there is no difference between class diagram and domain model?
Class Diagrams are one way to model a domain. Actually, they're one way to model part of a domain. The primary advantage of a Class Diagram is that it exposes the relationships in the problem space explicitly and clearly. There is a body of opinion that says the semantics of a domain arise primarily through the relationships among concepts (classes) - more so than the classes themselves. If you buy into that opinion then it's possible/likely that you'll find a class diagram useful.
Note however that Class Diagrams only capture the structural elements of a domain: Classes, Attributes and Relationships. A CD doesn't capture behaviour. A Domain Model needs both structure and behaviour if it's to model the problem space in any useful way. So you'll need to augment the class diagram with some behavioural description; e.g. state models and/or actions.
There are other ways to model domains too. It can be a set of java/c# classes. The main disadvantage of such an approach is the reduced emphasis on relations. Unlike class diagrams, OO languages don't provide relations as first class constructs. The advantage is that programming language environments (editors/compilers/libraries/language runtimes) provide much better support for defining the behavioural aspects of a domain than most modelling tools.
More generally there's no rule that says a Domain Model has to follow the OO paradigm. It could be a set of functions and types in Haskell or OCAML. Or it could be some differential equations or other mathematical construct.
The key thing is that the model - however expressed - provides a description of the problem space. To be useful that description will not be complete - it will only capture the subset of properties in the problem space relevant to the system requirements. To be useful however it should be correct - the concepts and behaviour that are captured should accurately reflect the world being modelled.
I also would like to understand In which way is vocabulary related to a domain model?
You can think of a Domain Model as a way to produce a formalised and highly structured vocabulary. Actually, it captures some grammar too; e.g. it says that the participants in the 'Ownership' Relation must be a Dog and a Person; not two Dogs, or a Person and a Spoon.
This is what Eric Evans calls 'Ubiquitous Language' in Domain Driven Design. It means that the terminology used in the model should accurately reflect that of the problem being modelled. So if the real world domain experts use the words 'Person' and 'Dog', the model shouldn't use 'Homo Sapien' and 'Canine'. The rationale is simple: if developers (modellers) use the same terms as the domain experts, there's much less chance of misinterpretation. It also leads to more productive and pleasant conversations since everyone is using familiar words with a common meaning.
Summary
A Domain Model is an abstraction. It represents a subset of the concepts, rules and policies intrinsic to the real-world problem the system addresses.
A Class Diagram is one way to represent the structural aspects of a Domain Model. It does not capture the dynamic aspects. These are equally important.
There are other ways to model a domain. They are not limited to the Object-Oriented paradigm.
A Domain Model should be a structured vocabulary for the problem space. It should adopt the terminology used by experts in that field.
hth.
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.
What is the difference between a domain model and a data model?
A datamodel is a design model that only describes data and it's relations. The model contains entities, but they are described in terms of what data they own not how they act on this data or what their responsibilities are.
An domain model on the other hand, is a conceptual model used in analysis of a problem domain. It describes the domain in terms of entities that have relations, data and behaviour. It describes the responsibilities of those entities as relevant for understanding the problem domain.
BTW an excelent and very short introduction to UML is:
UML Distilled: A Brief Guide to the Standard Object Modeling Language
A data model is focused on the DB schema definition, including tables, columns, and relationships.
A domain model is focused on the business domain, including concepts (classes of objects), behavior (methods/logic), and relationships.
In both cases, the cardinality is used for relationships (e.g. 1:1, 1:Many, 0:Many, ...).
That said, you would ideally like the data model and domain model to be closely related, i.e. a Person with name, ... and a MailingAddress, ... relates to a PERSON table with a NAME column and a FK to a MAILING_ADDR table entry. You have to decide where logic is hosted - in the objects in the software system vs. in the DB via procedures, triggers, and such.
I think it's important to provide some clarity here for posterity.
A data model is a design for how to structure and represent information. By structure, I mean concerns like "fifth normal form". By representation, I mean choosing a computer serialization, such as integer, floating point, or string.
The term domain model actually has two conflated meanings.
A model of essential characteristics of real or imaginary things in the world. In this kind of model, classes represent human conceptualizations and instances are things in the world. For example, a "Person" class would have instances including you and me, and an essential characteristic might be that every Person has a mother. This kind of model is often called an conceptual ontology or concept model and is intended to provide meaning.
A model of required information about things in the world, usually with some system in mind. In this kind of model, classes represent information that must be stored about things in the world. For example, a "Person" class would have instances representing required information about you and me, such as first name, last name, date of birth, current height, and current weight. This information often does not include all essential characteristics, such as our mothers, because, for the purposes of a particular system, that information is not required. This kind of model is often called an information model, conceptual data model, or operational ontology.
Both the UML and OWL languages can be used to represent either kind of domain model. Both can be considered analysis models, as they are used to analyze a domain. One is used to understand things in a domain, the other is used to gather requirements to build a particular software or database system for things in a domain. Both are necessary, and, unfortunately, they are usually conflated such that people building an analysis model are themselves confused about what they are modeling!
I think that domain model and data model are now pretty much the same with new top down modelling technologies. I mean that you can model in a class diagram and only add database stereotypes in your diagram. If you use the tool that I use then your ejb3 annotation would be immediately synchronized with your code. The next step is only to use a mapper to create your database. This technology only works with Java