Actually the question in the header. When should I use these properties? I tried to change them but nothing happened. Could someone explain me that?
Target for Key represents HasKey in OWL2.
An HasKey axiom states that each named instance of a class is uniquely identified by a (data or object) property or a set of properties - that is, if two named instances of the class coincide on values for each of key properties, then these two individuals are the same.
An example is:
RegisteredPatient HasKey: hasWaitingListN
General class expressions represent Complex class expressions. They are not often used but you can use them to express complex statements in OWL.
For example:
HeartDisease EquivalentTo: Disease and hasLocation some Heart
Also, take a look at this great example on how to define complex class expressions.
Related
I have a User class that can "measure" some parameters associated to a date and input them in an application. So 1 User -> many parameters of many types associated to many dates (many measurements). The parameters types are fixed and can be both numeric or strings, e.g: weight, height, calories intake, some strings... which are represented as an enumeration.
Now my main problem is: does the fact that the parameters can be of different datatypes (numbers or strings) mean that the general parameter type has to have specialisations for the two subgroups of parameters? Or is the datatype for each type of parameter implied in the type itself? (e.g. a "weight" implies it should be a number)
How can the "Parameter" class be represented in a correct way considering that:
it can be both numerical or a string
there is also a superuser class that can add parameters for a specific user
the parameters the superuser can input are some of the ones the normal user can PLUS some other parameters exclusive to the superuser (say: fat body mass) so there is not a 1-1 correspondence
the numerical parameters have other additional attributes that can be modified by the superuser (for example: limit weight)
the superuser supposedly should be able to add "notes" for some parameters
My confusion stems from the fact that I have no background in OOP programming and i can't find any similar examples online. I just need an input towards the right direction to go to. Is the pictured diagram correct? And why it most likely isn't? The problem as of now would be how to implement the fact that the superuser can also add notes to some parameters.
Do I:
create a single parameter class with the enumeration type as attribute which automatically implies the datatype of the input e.g weight = number?
create two subclasses for each User, e.g. UserParameters and SuperUserParameters, although some parameters overlap?
leave it as is with some adjustments?
other better approach?
I'd like to propose using an improved terminology. Since your app is about (health) property measurements, I'll replace your class name "Parameter" with Measurement.
The following model should satisfy all of your requirements (except the one discussed below):
Notice that the two subclasses UserProperty and SpecialProperty simply define a partitioning of Property. They can be eliminated by adding an enumeration attribute propertyCategory to the Property class, having USER_PPROPERTY and SPECIAL_PPROPERTY as its enum literals.
The only requirement, which is not yet covered, is
the numerical parameters have other additional attributes that can be
modified by the superuser (for example: limit weight)
This needs further carification. If these "other additional attributes" form a fixed set, then they can be modeled as further attributes of the Property class.
I don't think you should do that on UML level at all. You are going into memory management/overlays. And those are implementation details you should not take care of. Rather you are dealing with HeartRate and Weight as distinct objects. They will not have a common "value", which is just some memory allocation. They are what they are and whether you need a string or a number is some property of the distinct business objects.
I have to indicate for the Employee class that each employee can be clearly identified by his personal number. I do not know if I think too complicated, because I have no real idea.
Attributes:
final int personelNumber
...
You don't even need an OCL constraint to express that in UML.
There is a property isID on the Property metaclass that ensures this:
From UML 2.5 specification § 9.5.3 (p. 111)
A Property may be marked, via the property isID, as being (part of)
the identifier (if any) for Classifiers of which it is a member. The
interpretation of this is left open but this could be mapped to
implementations such as primary keys for relational database tables or
ID attributes in XML. If multiple Properties are marked as isID
(possibly in generalizing Classifiers) then it is the combination of
the (Property, value) tuples that will logically provide the
uniqueness for any instance. Hence there is no need for any
specification of order and it is possible for some of the Property
values to be empty. If the Property is multivalued then all values are
included.
The notation for this property is similar to that of other constraints
using
{id} after the name and type of the attribute
You don't provide your metamodel, and clearly wrt to each Employee their personelNumber is single valued and so necessarily unique. Presumably it is within some scope such as a Company that the personelNumber should be unique, so the answer is often something like.
context Company
inv UniquePersonelNumber: employees->isUnique(personelNumber)
Two alternative OCL expressions can be found in the following question:
Why allInstance not for isUnique?
In your case, it would be:
context Employee
inv personalNumberUnique : Employee.allInstances() -> isUnique(personalNumber)
In UML class diagram, is it possible to represent an attribute that can have multiple types? For example, MyClass has an attribute named MyAttribute. How can I specify in class diagram that MyAttribute can assume float or string type value? An alternate option is to write MyAttribute: (https://learn.microsoft.com/en-us/visualstudio/modeling/uml-class-diagrams-guidelines?view=vs-2015), i.e. not specifying the type, but not specifying the type may create problems if people start to use their own types.
Thanks in advance.
One way to do this is to model a union of two different data types. You would define a data type that has two specializations, create a generalization set that is {complete, disjoint}, make the general data type abstract, and use the general data type as the attribute’s type.
You may have trouble convincing a code generator to map this correctly to a programming language, such as C++ or XSD, which can both represent this construct, but the UML would be perfectly clear to any reader.
A UML Attribut or Property can only have one type.
So if you want, for example, to allow both String and Float values you have to type your attribute with an Interface common to both of them like Object for example.
But of course, it will less precise because you allow other kind of values....
When you're dealing with untyped languages (like e.g. Python), none of your attributes have a specific type. In any typed language you decide at compile time which type an attribute can take. I don't know of any language that allows a set of types to be assigned to any attribute.
Assuming you're talking about untyped languages, you would add a constraint to your generally untyped attributes telling something like { must take either type A or B }. Of course, the compiler/interpreter will not help you in checking that constraints.
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.
Through searching I found that in UML, aggregation(assuming that it's used properly) can be used to represent attributes in a class.
For example,
(Assume column can stand alone)
Then, using such example, if I want to replace the attribute: Column[] with map to represent the column's name, would it be correct to use an association class just like below? (In case, I'm not willing to put the column name in Column class as an attribute)
Association classes are used with simple associations. They have m-1-1-n multiplicity. The shared aggregation (as you used) has no defined semantics (and I recommend to simply not use it unless you have a domain specific and documented use for it). It's simply better to put the intended multiplicity on either side of an association.
An association class connects two classes, adding attributes and/or operations. Your example is "unconventional" since Table/Column have a simple relation which would not need an association class. A general example is the Student/Lecture relation where you can put an association class in between to record exam results, times etc.
Yes, I think that is a valid way of modelling the fact that you have some sort of key string that can be used to identify a Column of this Table.
Using a Map is one if the many possible implementations, so it's not a real equal to.
The advantage of modelling using the Association Class is that your model remains at the more abstract functional level and leaves out implementation details.
BTW. I would use a composition instead of an aggregation for the association between Table and Column, as there is an obvious strong ownership relation and life-cycle dependency between the two.
If you want to replace the attribute Column[] with map to represent the column's name and you are not willing to put the column name in Column class as an attribute and assuming that you want to follow UML specification precisely then you'll produce the model shown below:
Map<Key, Value> is usually understood as an associative container that contains key-value pairs Map.Entry<Key, Value> with unique keys. The container is modeled by the directional aggregation from Map<Key, Value> to Map.Entry<Key, Value>.
Map<Key, Value> and Map.Entry<Key, Value> are templates. Clause 7.3.3.1 of UML specification says that:
A template cannot be used in the same manner as a non-template Element of the same kind. The template Element can only be used to generate bound Elements or as part of the specification of another template.
According to clause 7.3.3.3:
A TemplateBinding is a relationship between a TemplateableElement and a template that specifies the substitutions of actual ParameterableElements for the formal TemplateParameters of the template.
Thus we have two bound elements that have TemplateBinding (marked by <> keyword) relationships with their templates:
ColumnNames which essentially is the name for Map<String, Column>
ColumnName which essentially is the name for Map.Entry<String, Column
According to clause 11.5.1 of the UML specification:
An Association classifies a set of tuples representing links between typed instances. An AssociationClass is both an Association and a Class.
ColumnName is AssociationClass representing the link between instances of String and Column classes. We use notation from clause 11.5.5, figure 11.35 to express that.
Finally, the directional composition association between Table and ColumnNames classes tells us that each instance of Table owns an instance of ColumnNames, i.e. set of column names.
Note that while ColumnNames and ColumName classes are usually hidden from the end-user by an implementation, they nevertheless exist.
I used BoUML to draw the diagram.