I have a logical data model and multiple physical data models for different systems, all documented in UML. I want to show how the data in the physical models trace back to the logical model so that when changes are made to the logical model we can readily determine all of the physical models that are impacted.
Are these relationships best represented as a trace or a realization? I suspect the answer is "trace", but wanted to see what others thought prior to investing too much time in this and being wrong. Does a trace or realization relationship offer extra semantics over the other that would be useful in this context?
My interpretation so far (intentionally quoted): "I usually make them <<trace>> dependencies. A Realization is between an interface or an abstract class and a 'regular' class. The physical model is derived from the logical model, not 1:1 realized. In most cases you make modifications on a physical level which are not foreseen in a logical model (de-normalization and all sorts of optimization you need on a DB level). Somehow this is sort of a realization."
However, and this is the pure truth, this is what the UML spec says on p. 54:
7.8.14 Realization [Class]
Realization is a specialized Abstraction relationship between two sets of model Elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.
So you can actually use a realization here. The <<trace>> is more informal, but not necessarily wrong.
These relationships are best represented as a trace, i.e. a dependency relationship with stereotype <<trace>>. The trace is meant to relate elements in different models, which is exactly your situation.
The UML 2.5.1 specification defines the trace stereotype as part of the 'standard profile' (section 22.3), as follows:
Specifies a trace relationship between model elements or sets of model
elements that represent the same concept in different models. Traces are
mainly used for tracking requirements and changes across models. As
model changes can occur in both directions, the directionality of the
dependency can often be ignored. The mapping specifies the relationship
between the two, but it is rarely computable and is usually informal.
Although the UML specification defines the realization relationship broadly enough to fit your purpose as well, the examples in the UML specification (e.g. figure 7.21) and the way I have seen this relationship been used in real world projects lead me to the conclusion that this type of relationship is primarily intended to be used to relate elements within the same model, in particular interface elements with classes that implement these interfaces.
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 have a short question:
Should I name attributes of types like a List, Arrays, Vectors or Pointers to objects (not primitive type) in the UML diagram or the only association/aggregation/composition arrows are enough?
Example: which of these diagrams is correct?
or
In UML, your second diagram would be correct if you wrote the property names at the far ends of the associations. While UML properties are allowed to be unnamed, it is not a good practice. Use association ends to indicate why the relationship exists. Sometimes more than one association must exist between one pair of classes, but for different reasons. How would you tell them apart?
The first diagram shows two properties of each type. One is named and another (at the end of each association) is unnamed. That is incorrect.
This really depends on what you're trying to convey in this architectural drawing.
The purpose of the drawing is to help reason about the structure of the software. It should not be used to represent all of the details of implementation. If you put too much detail in it, it becomes cluttered, and it is hard to keep it consistent with the source code as changes occur.
The UML drawing should be more abstract than the implementation. It should hide details on purpose, so that it conveys the external view of classes, and not how they are implemented internally. You generally don't want users of classes to assume too much about their internal implementation, therefore you don't want to expose it too much.
Also, an architecture is typically represented by several drawings - not one. Try to have each drawing focus on one level of abstraction. If you have a few high level classes that represent the main logic of the application, and many low level classes, it makes sense to have a drawing of just the high level classes separately.
I found a definition for association in UML as below.
An "association" in UML is defined as a kind of relationship between
classes,which represents the semantic relationship between two or more classes that
involves connections (links) among their instances .
I am not clear what is semantic relationship. Can anyone explain it with example with comparing it with non semantic relationship?
Associations in plain text
An association is a semantic relationship. The UML clause means that there is a structural relationship between instances of the associated classes independently of any specific implementation. "Semantic" underlines that the relationship is between the instances themselves, and not just "accidentally" for an operation:
Use associations primarily where there are structural relationships among objects. Do not use them to show transient relationships such as parameters or local variables of procedures.- Booch, Rumbaugh & Jacobson in Unified Modeling Language User Guide, 2nd edition
More arguments
What is "semantic"?
The term "semantic" is borrowed from linguistics and refers to the meanings behind the words. Linguists and map words (e.g. "Car", "Driver") to their meaning (e.g. a real car, a real person), and analyze the relation between words with a view of this mapping:
So, applying this to UML (modelling language) if you'd have the classes Car and Driver, you CAN model the semantic relationship as an association between the two classes.
What is not semantic?
Not all relationships are of semantic nature. You can have dependencies, which can express a technical relationship:
a transient relationship during an operation: with a factory pattern for example, a DriverFactory would «create» a Driver instance. Both instances the factory and the driver are related only at the exact moment of the creation operation. But the two instances are completely independent the nanosecond after.The same applies if the implementation of an operation needs to create a local instance of another class. Both classes are not associated, since we could imagine another implementation that works without such an instance.
a structural dependency: Maybe an operation require some other classes as parameter. Since the parameters themselves are transient, there is no association. But nevertheless, teh class needs to know about the other class.
For the records, I'm grateful to this public domain contributor for the nice car and driver and to 18f for advice on inclusive communication.
The subject of Semantics is sense. If one thing has something that is connected by sense to another thing, it is the semantic relationship. That definition is terribly wide. And, applied to UML relationship, incorrect. It is incorrect for two reasons.
First, UML covers not only Class-Instance languages, such as Java or C++, but pure object languages with heredity created by Prototypes as well. And this second variant is not covered by your definition at all.
Second, in UML you can have class A connected to class B through some complex AssociationClass, that is shown by a box with arrows, not arrow only. And it still will be named an association and it IS a semantic relationship, too. But a the semantic relationship goes from A to B through two classes, it is still a semantic relationship, but it is not an association in UML.
If you are trying to be deep in subject, better read the UML documentation: "An Association classifies a set of tuples representing links between typed instances." (UML 2.5, pharagraph 11.5.1). Notice: ANY link between two instances can be shown as an association. Maybe the book you are reading is wholely not so bad, but in the very place that you have cited the author merely tries to use pretty words not understanding their meaning and not even trying to be understandable to readers and to be CORRECT.
A model says something about the things being modeled. This is its semantics. Almost all elements of UML have semantics, defined in the sections titled "semantics". One exception is the comment. Adding a comment to a model doesn't influence its meaning.
Then why does the UML say this explicitely about associations? The reason is, that an association may or may not say something about the structure. If it doesn't, it is purely semantic.
For example it could tell us, that a Car can have at most one Driver. It doesn't necessarily mean that the car has an attribute of type Driver.
If we want to model that the two associated classes own attributes typed by the other end of the association, the notation will show this by small dots on its ends. Many people are not familiar with this notation and interpret associations without a dot in the same way. However, without the dots attributes are owned by the association itself and the structure of the classes is not influenced.
By the way, a class being the type of a parameter of an operation or having a dependency also means a semantic relationship.
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.
Im a bit uncertain about the relation between the Unified Modeling Language (UML) and the different modelling perspectives (conceptual, specification and impelementation) endorsed by (R)UP among other OOA/D methodologies.
From what I understand the same type of diagram using the same notation can have different meaning depending on the perspective* being used. For instance the class diagram can represent an abstraction of real world systems / phenomena in the conceptual perspective and when perspective is later changed to specification/implementation the class diagram is used to abstract constructs of a computer program.
Questions:
1) It is my understanding that certain rules exist for a UML class diagram in general. For instance that a class can extend another class but that it can't extend an association. Where are the entities of the class diagram and the rules about how they can relate defined? Does it all take place at the M2 layer in the UML metamodeling architecture
(see wikipedias illustratio of metamodel architecture)?
2) A related question. The way I see it, the general rules for a specific diagram span the modelling perspectives (again, it is absurd for a class to extend an association), but the different modelling perspectives will superimpose certain meaning to a particular type of diagram. For instance an association in the class diagram of the domain model (conceptual perspective) will inherently be bidirectional whereas it can be either bi- or unidirectional in the class diagram of the design model (specification / implementation perspective).
In the scenario just described the rule superimposed limits the properties of an association. Is it a correct assumption that rules superimposed by perspectives will always be a subset/limitation of the rules defined by the uml metamodel and never a superset?
Are these rules/limitations defined by the perspectives formalized (in a way similar to the metamodel) or are they mere conventions described in the OOA/D litterature?
* Perspectives are explained in paragraph 10.8: http://books.google.co.uk/books?id=r8i-4En_aa4C&printsec=frontcover&hl=da&source=gbs_v2_summary_r&cad=0
1) Your first question is quite clear. The rules that you are looking for are called a "metamodel". And yes, they are documented as what the OMG (the creators of UML, basically) call "MOF" or "meta-object facility". It is an OMG standard.
2) Your second question is a bit more confusing. I'll try to answer here. Diagrams are just views on an underlying model. The model is overarching and all-encompassing, if you wish. But diagrams are not. The perspectives that you mention are related to diagrams. But the model that underlies is multi-perspective, in the sense that all the elements form a connected mesh, without isolated "islands". Does this make sense? :-)