I have one class diagram and one object diagram. Is the object diagram valid according to the given class diagram?
Can I say it is invalid because :C has no alpha link with any S type object?
Or it is valid because :C and :T have already an alpha link if they have a beta link because C and T are subclasses of the A and S classes respectively?
The instance specifications are invalid (or at least incomplete) because the instance of C has no alpha link to the instance of T.
However, if you were to draw a generalization relationship between the beta and alpha associations, that would make the instance specifications valid as they stand. A generalization between the associations would imply the unnamed end of type T is a subset of values for the unnamed end of type S. §11.5.3.1 (Associations) in the UML 2.5 spec says, "specialization means that a link classified by the specializing Association is also classified by the specialized Association."
BTW, please always name the ends of your associations. This answer would have been easier to express if I could have mentioned the association ends by name. Having names for these also reduces confusion when communicating with other people on a team.
Related
While I googled to understand the Unary associations, I got the following two explanations:
the first is:
A unary relationship is when both participants in the relationship are
the same entity. For Example: Subjects may be prerequisites for other
subjects, or one employee manages many Employees.
and the second is:
Class B knows about ClassA.
Class A does not know about ClassB.
Now lets look at the following example:
You can see the Person and Address relationship below. We call this
relationship as has-a relationship since person has a address. So
Person knows the address but address does not know anything about
person
Am I misunderstanding something?
Common language
The arity of an association is about how many classes are associated. This is an ambiguous concept since some understand different classes, whereas others understand instances.
When applied to unary, the first interpretation would mean reflexive association (or self-association, i.e. a class associated with iteself), whereas the second would mean a class associated with nothing (not very useful: any class could be associated with nothing else).
UML perspective
Fortunately, the UML specifications are much more precise than the common language:
An Association specifies a semantic relationship that can occur between typed instances. It has at least two memberEnds represented by Properties, each of which has the type of the end. More than one end of the Association may have the same type.
So in UML there is no "unary association". It's binary, ternary, or n-ary (terms used in the specs). There is no special term in UML for a binary association with the same class at both ends. But reflexive or self-association are terms which are more popular than unary.
E/R modeling
The term "unary" is popular in the context of entity-relationship modeling, to describe a relation in a relational database. Relations correspond more or less to an association in UML, and entities to classes, but there are some subtle semantic differences. E/R has its foundation in the set theory. And if a relation is between the same entities, it means in fact that only one set is involved. This is probably why unary is more popular in this context.
Merriam-webster defines Unary as
having, consisting of, or acting on a single element, item, or
component
So the first explanation is correct one since this type of association acts on a single class. The term Unary however is not used in UML and might be confusing.
UML uses the term binary to indicate that an association has two ends, and ternary or n-ary to indicate an association has multiple ends.
The Unary association you are talking about is actually a binary association to itself, also known as reflexive association.
Not to be confused with a Unidirectional association, which is an association that is only navigable (has an arrow) to one side.
Suppose an abstract class X and its subclasses Y and Z. How do I represent in UML class diagrams that Y and Z should be singletons. Is it possible to represent that all X subclasses must be singletons?
To specify that all subclasses of X are singletons, you can write a constraint in between braces: { every subclass of X is a singleton }. This constraint should be put in a constraints compartment in the class rectangle.
The UML 2.5 specification, §7.6.4 defines the notation for constraints in general and §9.2.4 specifies how to show the constraints of a classifier:
If a Classifier owns Constraints, a conforming tool may implement a compartment to show the owned Constraints listed
within a separate compartment of the owning Classifier’s rectangle. The name of this optional compartment is
“constraints.”
Alternatively, you could give a singleton indication on each and every subclass of X. From your wording, I assume that that is not what you want. Anyway, the latest version of UML (2.5.1) does not have a standard way to indicate that a class is a singleton. Some people indicate it by writing 1 in the top right corner of the rectangle. However, that is not valid UML. You may use that for parts, but not for classes. Instead, you could invent your own stereotype ≪singleton≫.
There is another StackOverflow question about this topic.
Here's another possibility: you can adorn the class with a <<singleton>> stereotype. I always used it that way and the coder knows how to handle that. It's no UML standard, but see the last sentence.
§11.4.4 of the UML 2.5 spec says:
A usage dependency may relate an InstanceSpecification to a
constructor for a Class, describing the single value returned by the
constructor Operation. The Operation is the client, the created
instance the supplier.
If you create a GeneralizationSet that has the meta-property isComplete=true (to say that all possible subclasses are accounted for), and you connect one InstanceSpecification to each constructor by a usage dependency, the model means that every class is a singleton.
I am looking for a way to modelize ethereum smart contracts interaction using a modeling language like UML.
I have the following serivce Contract:
contract ServiceContract {
constructor (address _storeC, address _quizC, address _signC) {
StorageContract storeC = StoreContract(_storeC);
QuizContract quizC = QuizContract(_quizC);
SignatureContract signC = SignatureContract(_signC);
}
function storeData (bytes32 data) public {
storeC.save(data);
}
function getAnswer( bytes32 question) public constant returns (bytes32) {
return quizC.get(question);
}
function sign (bytes32 data) public returns (bytes32) {
return signC.sign(data);
}
}
I modelized it with this class diagram, is it correct?
[Edited for extra clarification]
Modelling a system is describing it in a formal way using a modelling language, and in some cases following some common guidelines. In this case you suggest the use of UML (See UML Specification).
UML diagrams can be divided into three categories:
Structural: The common structure, the values, the classifiers and the packages are in this category
Behavioral: The common behavior, the actions, state machines, the activities and the interactions are in this category.
Suplemental: The use cases, the deployments and the information flows are in this category.
As a modeler you decide which diagrams do you you need for what target you want to apply.
In your question you say that you are looking for a way to modelize an interaction. That is within the behavioral category. However you provide a sample code and a proposed class diagram, which is within the structural category.
That being said, is it your proposed diagram correct? I would say that it is inaccurate and incomplete (but not necessarily incorrect). Let me explain this a bit further.
In your proposed diagram you have four classes: ServiceContract, StorageContract, QuizContract and SignatureContract. You have drawn a relationship between the classes that is known as a dependency. And this dependency is of a specific type: usage (represented by the «use» keyword). What does this mean in UML?
A dependency in UML is defined as a relation where "the semantics of the clients are not complete without the suppliers" (Section 7.7.3.1 of the UML specification). Moreover, a usage dependency is defined as a relation where "one NamedElement requires another NamedElement (or set of NamedElements) for its full implementation or operation" (Section 7.7.3.2).
Hence, if we apply those defintions to your proposed diagram, you may read the relation between the ServiceContract and the StorageContract as "ServiceContract uses StorageContract". But nothing else. With this diagram you don't know how ServiceContract uses StorageContract, if it uses more than one instance of StorageContract, and so on.
Since you know how those classes are related, you should use a more accurate and complete diagram.
The first step is to use an association instead of a dependency. In UML an association is defined as "a semantic relationship that can occur between typed instances". And you know the semantic relationship between the classes that you are modelling in your class diagram. Therefore it makes more sense to use an association.
An association is represented with a solid line (indeed the UML specification says that it may be drawn as a diamond, but for binary associations it says that normally it is drawn just with a solid line). So let's start changing your diagram to the new one. In the next figure you can see the four classes with the association relationship (still incomplete):
Now that we have the association, we need to define it further. Has the association a name? Can the association be read in both ways? Do we know the multiplicity values for each end of the association? Do the ends of the associations have contraints?
In this example we don't need a name for the association, it seems that it can be read in both ways, and also that the multiplicity values are exactly 1 for all the ends. Then we do not to add anything to the diagram related to these questions. But what about the constraints?
Let's take a look at the source code. When you put this:
contract ServiceContract {
constructor (address _storeC, address _quizC, address _signC) {
StorageContract storeC = StoreContract(_storeC);
QuizContract quizC = QuizContract(_quizC);
SignatureContract signC = SignatureContract(_signC);
}
}
you can express it as "the ServiceContract has (owns) a property named storeC that is of a type of StoreContract", and so on. An ownership in an association is represented by a small filled circle (called a dot), at the point where the line meets the Classifer that is owned. Also you can add the name of the property that holds the ownership (Section 11.5.4). At this point the diagram is like this:
(See the answer from Thomas Kilian)
Since we cannot infer the visibility of the properties from the source, we can just let it as undefined (otherwise we can use a + sign before the name of the property for a public property, a - sign for a private property, a # for a protected property, and a ~ for a package).
Also we can show the properties within the Classifier for ServiceContract instead of at the end of the owned Classifier in the association. This will look like this:
Both styles are allowed by the UML specification (Section 9.5.3), and it also does not enforce any convention. However it mentions the convention for general modelling scenarios "that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not".
This diagram is correct in the sense that it complies with the UML specification, and that it describes a system in which you have:
A Classifier named ServiceContract that owns three properties:
A Property named storeC whose type is a Classifier named StorageContract.
A Property named quizC whose type is a Classifier named QuizContract.
A Property named signC whose type is a Classifier named SignatureContract.
And remember, it is your choice, as a modeler, if this is enough for your target or not.
From the source I can say that the previous diagram is still incomplete and inaccurate. Why?
Because the source includes three Operations (the functions) that are not represented in the diagram. This can be improved in terms of completeness.
Because you cannot say from the diagram if the Classifiers that are owned by the ServiceContract are owned to group together a set of instances of the owned Classifiers or not. And given the case, if the owned Classifiers share the same scope or not. This can be improved in terms of accuracy.
First we are going to add the operations (the functions) to the diagram:
[NOTE: You may also add the _constructor_ to the operations.]
I guess that the functions are public, so I have included the + modifier at the beginning of each operation name.
Now for the accuracy, it seems to me that the ServiceContract groups together the StorageContract, the QuizContract and the SignatureContract in order to provide a common Classifier to access to certain operations (functions). If that is the case, then we are talking about aggregation. In UML aggregation is defined as an association where "one instance is used to group together a set of instances" (Section 9.5.3).
An aggregation can be of two types: shared (or just commonly known as aggregation from previous versions of the specification), and composite (or just commonly known as composition from previous versions of the specification).
The UML specification provides a more or less specific semantics for what it means for an aggregation to be of the type composite: "the composite object has responsibility for the existence and storage of the composed objects".
Let's say that in your case the existence and storage of the StorageContract, the QuizContract and the SignatureContract is responsability of the ServiceContract. Then in that case you have a composite aggregation, that is represented by a black diamond:
And it is read as "ServiceContract is composed by an owned property of classifier type StorageContract called storeC", and so on.
Keep in mind that using a composite type of aggregation you are saying that the ServiceContract object is responsible for the existence and storage. That means that whenever an instance of the ServiceContract is removed/destroyed, the associated StorageContract, QuizContract and SignatureContract must be destroyed also.
If that is not the case, and given that still the assocation matches the aggregation definition, then the only other option available is that the aggregation must be shared. The UML specification explictly does not provide a precise semantics of what a shared aggregation is, leaving the application area and the modeler with the responsability of giving those semantics.
So, if the StorageContract, the QuizContract, and the SignatureContract exist independently of the ServiceContract, and if you agree that the ServiceContract aggregates those objects according to definition given in the UML specification, you must use a shared aggregation.
A shared aggregation is represented by a hollow diamond at the end of the association of the Classifier that aggregates other Classifiers. And this it's how it looks:
And this diagram can be read as:
There are four Classifiers: ServiceContract, StorageContract, QuizContract and SignatureContract.
ServiceContract aggregates three owned properties:
storeC, of type StorageContract.
quizC, of type QuizContract.
signC, of type SignatureContract.
ServiceContract has one constructor that requires three arguments:
_storeC of type address.
_quizC of type address.
_signC of type address.
ServiceContract has three public functions:
storeData, that requires one argument of type bytes32 called data and returns nothing.
getAnswer, that requires one argument of type bytes32 called question and returns a bytes32 data type.
sign, that requires one argument of type bytes32 called data and returns a bytes32 data type.
Keep in mind that maybe for your desired target this final diagram is too detailed. It is your responsability as modeler to decide wether to include some details or not into the diagram.
You simply have associations to these three classes:
(I just drew a single relation)
The role name to the right tells in conjunction with the dot that it's a owned property of the class to the left. Not sure about the visibility (if that's private per default replace the + with a -).
While it may be goodness to spend some time to learn what exact arrow should used for particular Solidity relationship in UML (inheritance, composition etc), general trend is to let standard tool to care about this.
There is sol2uml UML generator https://github.com/naddison36/sol2uml
that is already used on https://etherscan.io
e.g. for USDT
https://etherscan.io/viewsvg?t=1&a=0xdAC17F958D2ee523a2206206994597C13D831ec7
(See image below)
So don't spend time manually drawing lines, use wiser tools to do it quicker for you.
I have this class/object diagram:
I don’t understand why that object diagram is invalid according to the given class diagram.
In the object diagram, one C object has two links with two T objects, alpha relationship with a T object and beta relationship with another T. So I don’t think it violates the multiplicity constraints.
Could you please explain me why the object diagram is invalid?
Yours is the most interesting question I've seen here in a long time. It is pretty tricky!
The simple reason your instances are incorrect is that every instance of type T must be associated with one C. The top instance of type T in your diagram violates the constraint in association beta. (The multiplicity on the left end of the association.)
There are two faults in the object diagram.
There is only a formal fault in the object diagram, the lines in the objects diagrams between the instances are links, i.e., instances of the associations shown in the class diagram. As the links are instances, the same rules for instance naming apply as to class instances. So change alpha to :alpha and underline it, it is correct. Same for beta.
Further the links are not correct, as there is an beta link from the uppermost T instance missing. Each object of A, and as C is a specialization of A, also C (and B) objects need an alpha link to an S instance. As S is a generalized T, an alpha link between A (or one of its specializations) and S (or one of its specializations) is needed. Further each S (or T) might have arbitrary alpha links to A objects.
Each C object needs to have zero or one beta links to T instances. In the other direction, each T instance needs exactly one C instance via a beta link. This is missing for the uppermost T instance.
Leaving my prior answer below, but thinking twice, the answer is that your class diagram is incomplete.
The two alpha and beta associations have no association-end names. The fact that they have different multiplicities leads to the conclusion that they must be different associations. With names it would look like this:
Expanding the inheritance will make this:
Based on this assumption, my original answer stands like this:
The reason is that a :C has two associations alpha and beta each to another :T object. Not a single alpha to one and a single beta to another. So you need to add a beta to the alpha and vice versa.
Edit And yes, JimL. is correct. Having two alpha-links violates the constraint from the class diagram. So actually you can only have one T linked to C. Which again makes the class model very strange.
The C class has a beta-association to T. C inherits from A and T inherits from S. Since there is a alpha-association from A t0 S this is also inherited. So you have:
hi every body i'm trying to understand UML but there are some questions about it
In UML what is the significance of tagging a class with the stereotype <<abstract>>?
and how to express this constraint as an invariant,
A stereotype "abstract" does not exist - an abstract class should be depicted using italic font. Abstract means that a class cannot be instantiated. It needs a subclass to do so. So as a pseudo-code constraint this would mean
for all instances i of MyAbstractClass holds: i.actualClass != MyAbstractClass
or in ocl for MyAbstractClass holds
self.allInstances()->forAll(i: MyAbstractClass | i.classifier <> self)
As the word 'abstract' was not displayed in your first question version, I expanded on stereotypes in general:
First of all: When learning UML, stereotypes should not be the first things you look into. They are rather complex.
Stereotypes or keywords (both denoted with <<MyStereotype>>) do not have a general meaning. It is defined by the specific stereotype. Commonly you cannot express a stereotype as an invariant instead.
But some other aspects of UML can be shown the same way: A class from the UML Metalevel is marked with <<metaclass>> even though it does not have a stereotype or even is of different actual type. The Stereotypes themselves are shown with a <<stereotype>> marker (even if they are instances of a special class).
An example for a custom stereotype could be "Service". You could mark classes with it which represent a Service. There could be a constraint which tells you that a "Service" must implement a special Interface. In this case you could express this constraint as a (boring) invariant. But probably it is even just a marker. In the latter case you can use a keyword as replacement.
I realize this thread is a couple of years old, but I came to it when it was referenced by someone else, as supporting the assertion that the «abstract» stereotype isn't supported by the UML spec. That assertion isn't quite accurate, and I'd like to explain why. I'll start by clarifying what abstract classes are.
Abstract classes are definitions of classes that don't include complete implementation. Therefore, abstract classes can't be directly instantiated; they have to be specialized (inherited). Abstract classes are notated by italicizing the class name and the methods that are abstract, and additionally by optionally adding an {abstract} property to the class name and/or to the operations (methods, we usually say, but methods are actually the "method" by which the operation is implemented) that are abstract.
Interfaces are actually a specific type of abstract class: a class with zero implementation. Their notation is different from other types of abstract classes (don't italicize, use the «interface» keyword, and notate all the specialization arrows with dotted lines). So, as Christian says here, there is standard notation for abstract classes--at least, there is in class diagrams.
Now, while it is true, as Christian also says, that the «abstract» stereotype doesn't exist, it is also true that you can create it if you want to, and that doing so is supported by the UML spec. It's unlikely that you'll have a reason to (at least in class diagrams), but you still can.
A stereotype is an "extensibility mechanism" for UML (there are three: stereotypes, tagged values, and constraints). It allows you to more specifically define some sort of element. Stereotypes are applied to classes (metaclasses actually, metaclasses are classes whose instances are also classes). A number of stereotypes are pre-defined "Standard Stereotypes" (in UML 1.4 they were called "Standard Elements"). Examples of these are «metaclass» (again, a class whose instances are also classes) and «file» (a physical file in the context of the system developed).
Stereotypes are a type of keyword. The spec (Superstructure 2.0, Annex B, p. 663) has this to say about keywords:
UML keywords are reserved words that are an integral part of the UML
notation and normally appear as text annotations attached to a UML
graphic element or as part of a text line in a UML diagram. These
words...cannot be used to name user-defined model elements where such naming would result in ambiguous interpretation of
the model. For example, the keyword “trace” is a system-defined
stereotype of Abstraction (see Annex C, “Standard Stereotypes”) and,
therefore, cannot be used to define any user-defined stereotype.
In UML, keywords are used for four different purposes:
To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form...
To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form...
To specify the value of some modifier attached to a UML concept (meta-attribute value)...
To indicate a Standard Stereotype (see Annex C, “Standard Stereotypes”)...
Keywords are always enclosed in guillemets («keyword»), which serve as visual cues to more readily distinguish when a keyword is being used...In addition to identifying keywords, guillemets are also used to distinguish the usage of stereotypes defined in user profiles. This means that:
Not all words appearing between guillemets are necessarily keywords (i.e., reserved words), and
words appearing in guillemets do not necessarily represent stereotypes.
In other words, you can create any stereotype that you want, so long as it isn't a keyword. Since "abstract" is not a keyword, it follows that you can create an «abstract» stereotype.
In order to do so, however, you would have to go to some trouble, more trouble in UML 2.0 and above than in UML 1.4. UML 1.4 simply stated that a stereotype was an extension mechanism for the UML spec. One could simply define the stereotype, apply it to whichever part of the UML metamodel one wanted, and document the change. UML 2.0 wanted to formalize the relationship of a stereotype to a UML metaclass (any item on a UML diagram is a metaclass, and part of the UML metamodel). So, they came up with Profiles. This sample diagram shows how profiles work:
Now, that black arrow may look a bit strange, since you don't see it in any context but this one. UML 2.0 introduced the concept of an Extension, which it defines as "used to indicate that the properties of a metaclass are extended through a stereotype." This black arrow indicates an extension.
I'll quote Tom Pender (The UML Bible, Wiley Publishing, 2004) for an explanation of this diagram, since he does a better job than the spec (and I certainly can't improve on it):
It shows that a Component is extended by a Bean stereotype, which is required. The Bean stereotype is an abstract type, with two subtypes - Entity and Session. Each instance of Component, therefore, must be extended by an instance of either the Entity stereotype or the Session stereotype. Remember that a stereotype is a kind of class that can have properties - in this case, a Session stereotype has an attribute named state. This corresponds to a tagged definition whose value specifies the state of the Session. The tagged value is an enumeration, StateKind, which has either a stateless or stateful value.
The Component has a constraint on it, displayed in the note attached to the Component symbol, which states that a Component cannot be generalized or
specialized.
The diagram also shows that an Interface metaclass is extended by the Remote and Home stereotypes. The EJB package has a constraint, displayed in the note that sits in the package, that states a Bean must realize exactly one Home interface.
So, you can indeed use an «abstract» stereotype if you have reason to go to the trouble of creating it. The main reason that anyone might want to is to represent an abstract class in some place other than a class diagram.