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.
Related
I'm working on sequence & class diagram for education website, should all objects in sequence diagram be a class in Class diagram?
For example in sequence diagram for registration process I need an object called "Data Base" which needed for saving information of user, should "Date base" be a class in class diagram? and what can be its functions? Is it just load & save?
I think it depends on the level of formality, abstraction, and the purpose of your UML model.
Martin Fowler talks about UML as Sketch, UML as Blueprint, and UML as Programming Language.
The terminology has gotten some good usage; and I think 'UML as Sketch' in particular has emerged as a popular mode, with the goal of human-to-human communication about the design of a system; not necessarily a formal engineering specification (i.e. a blueprint), nor suitable as an input to a code generator (i.e. a programming language).
If you want to use UML in Sketch mode, which is perfectly valid, then it's not a requirement for your sequence diagrams to use only the classes defined in your class diagram. In fact, some of the objects/lifelines in a sequence diagram aren't class instances at all:
They may be "actors" defined in a use case diagram (or not). Actors are often people, and as such are represented as stick figures. "End user" is a common actor to include in a sequence diagram. Plenty of examples here.
They may be external systems, like a database, that are not defined in your class model. Your system might have a class, or set of classes, to abstract the database, i.e. a "data access layer" or DAL. But then again, your system might not have a DAL; and even if it does, you might still want your sequence diagram to show the interactions across the boundary, between the DAL and the actual database.
Using UML as a sketch, the methods implemented by external actors or system components are really up to you. You could show a database query as execute query, or something more specific, like an actual SQL statement. The "correctness" of your diagram is in its ability to communicate effectively with your audience, at the right level of detail and formality.
Yes, the Database would be a class in Class Diagram and its functions can be validation() , generatingErrorMessage() 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".
Can someone give me an example of when is better to use State Diagram and when Class Diagram. Tnx in advance!
For what type of software system would you use state machine diagrams to model functional requirements?
For what type of software system is data modeling via UML class diagrams suitable?
A class diagram shows classes in their relation and their properties and methods.
A state diagram visualizes a class's states and how they can change over time.
In both cases you are talking about diagrams which are only a window into the model. The class relations define how the single classes relate to each other. A state machine can be defined for each class to show its states. In embedded systems you use state machines almost all the time but there are also state machines for business applications (you can do this if that).
This question reveals a very common misunderstanding. There are only thirteen types of diagram in UML. They're not used to describe different types of system, but to describe different aspects of the system you are documenting. Which you pick in any given situation is more a question of style, what you want to emphasize.
It is better to use state diagrams if you want to focus on how the system can go into different states in response to various events. Activity diagrams are better if you want to focus on activities being carried out in some order, sequence diagrams are better if you want to show messages being sent between entities.
The above are all types of diagram which show behaviour. Class diagrams are a different type of beast altogether, and show how structures of things fit together (as do package diagrams and component diagrams).
It might be worth pointing out that while UML does not include a "requirement" element type, the related modelling language SysML does. If you want to express a number of functional requirements on the form "the system shall" in a model, SysML is a better fit.
A state diagram shows the behavior of the class. A class model shows the relationship between two or more classes. It includes its properties/attributes...
A state is an allowable sequence of changes of objects of a class model.
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'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.