As i read through UML specification that:
class has a set of attributes/operations
and data type has a set of attributes/operations
1)with regards to attributes/operations of data type
what this means?
because i don't know how such a data type has attributes and operations?
2)What’s the main difference between a class and a datatype?
according to UML 2.4.1 specification
A data type is a special kind of classifier, similar to a class. It
differs from a class in that instances of a data type are identified
only by their value. All copies of an instance of a data type and any
instances of that data type with the same value are considered to be
equal instances. Instances of a data type that have attributes (i.e.,
is a structured data type) are considered to be equal if the structure
is the same and the values of the corresponding attributes are equal.
If a data type has attributes, then instances of that data type will
contain attribute values matching the attributes.
1)Attributes/operations of data type have the same meaning than attributes/operations of classes i.e. attributes represent the structure of your data type and operations represent the method available on your data type.
2)The main difference between a class and a datatype is that it is not possible to have two instances of a datatype with the same values (these instance would be one unique instance).
Hoping it helps,
RB
In the Object Oriented
(OO)
approach
,
systems
,
including software
,
are
made up of numerous
objects
that work
together by exchanging information in
the form of data values and ‘messages’
. An object is a specific instance of a
Class
like your dog (an object) is specific instance of the class of all dogs.
Classes define what an object is like, and
objects are practical instances that can be used and manipulated.
As a definition, a class defines what properties will
be used to describe every object based on this class. Within the object each of these properties will have a value that
contributes to its description. Two objects of the same class will have the same properties, but they will have at least
one property that
has a different value in each of the objects
–
if all the properties have the same values in both of the
two objects then they are the same object.
A data type refers to the attributes of an object and what type of data each attribute is, such as string, boolean, integer etc.
Operations or methods is what an object can do such as for a dog:
growl();
bark();
fetch();
etc.
Have a look at this explanation of a Class Diagram, it will make more sense.
Related
C# 9 introduces record reference types. A record provides some synthesized methods like copy constructor, clone operation, hash codes calculation and comparison/equality operations. It seems to me convenient to use records instead of classes in general. Are there reasons no to do so?
It seems to me that currently Visual Studio as an editor does not support records as well as classes but this will probably change in the future.
Firstly, be aware that if it's possible for a class to contain circular references (which is true for most mutable classes) then many of the auto generated record members can StackOverflow. So that's a pretty good reason to not use records for everything.
So when should you use a record?
Use a record when an instance of a class is entirely defined by the public data it contains, and has no unique identity of it's own.
This means that the record is basically just an immutable bag of data. I don't really care about that particular instance of the record at all, other than that it provides a convenient way of grouping related bits of data together.
Why?
Consider the members a record generates:
Value Equality
Two instances of a record are considered equal if they have the same data (by default: if all fields are the same).
This is appropriate for classes with no behavior, which are just used as immutable bags of data. However this is rarely the case for classes which are mutable, or have behavior.
For example if a class is mutable, then two instances which happen to contain the same data shouldn't be considered equal, as that would imply that updating one would update the other, which is obviously false. Instead you should use reference equality for such objects.
Meanwhile if a class is an abstraction providing a service you have to think more carefully about what equality means, or if it's even relevant to your class. For example imagine a Crawler class which can crawl websites and return a list of pages. What would equality mean for such a class? You'd rarely have two instances of a Crawler, and if you did, why would you compare them?
with blocks
with blocks provides a convenient way to copy an object and update specific fields. However this is always safe if the object has no identity, as copying it doesn't lose any information. Copying a mutable class loses the identity of the original object, as updating the copy won't update the original. As such you have to consider whether this really makes sense for your class.
ToString
The generated ToString prints out the values of all public properties. If your class is entirely defined by the properties it contains, then this makes a lot of sense. However if your class is not, then that's not necessarily the information you are interested in. A Crawler for example may have no public fields at all, but the private fields are likely to be highly relevant to its behavior. You'll probably want to define ToString yourself for such classes.
All properties of a record are per default public
All properties of a record are per default immutable
By default, I mean when using the simple record definition syntax.
Also, records can only derive from records and you cannot derive a regular class from a record.
I'm on Enterprise Architect 14. I have a component diagram containing an interface User and two classes Employee and Customer, which both realize interface User.
Furthermore I created two instances, one of each class and specified the values of the attributes via Features & Properties > Set Run State....
Next I created a component with 2 attributes, one of type Employee and one of type Customer. Then I created an instance of the component.
Now I would like to set run state of the component instance by assigning ArbitraryUser to the Employee attribute and ArbitraryCustomer to the Customer attribute of the component instance. According documentation this should be possible (see here).
At run-time, an Object instance can have specific values for its attributes, or exist in a particular state. To model the varying behavior of Objects at run-time, use instance values selected from the 'Select ' dialog and run-time states or run-states.
However I could not figure out how to do so. Can someone help me?
AFAIK that is not possible.
I'm not sure what the quote from the help really means, but I've only ever been able to type a value for the run state.
An partial alternative would be to use associations rather than attributes to model such relations. Then you can create a link as an instance of the association to relate instances of Employee or Customer with instances of a ArbitraryComponent.
This solution doesn't work for datatypes, but it seems a bit far fetched to start modelling instances of datatypes.
All the examples for storing multi-field data require specifying a value class. However, I do not know the fields or their types until run-time. I would like to be able to create a region with a dynamic set of field values. For example,
put --key=101 --value=('firstname':'James','lastname':'Gosling')
--region=/region1 --value-class=data.Person
However, the data.Person class does not exist.
Furthermore, I would like to be able to query on the firstname field (or any other field of the value).
How can I do this with Geode?
You don't need a domain class to store data in Geode. You can store json natively in Geode. OQL queries make no distinction between PDX serialized objects and json values. In fact, when you store a json value in Geode, beneath the covers it is converted into a PDXInstance. You can read more about PDX Serialization in the documentation.
You can use PdxInstance.
Example using Java:
region.put(101, cache.createPdxInstanceFactory("data.Person").writeString("firstname","James")
.writeString("lastname","lastname").create());
Let's take 2 UML class model entities: One represents an actual Order and another represents an Orede Type. Any Order corresponds to one Type. A 2-way-naviglabe many Orders to one Type relation is meant. Order Type instances are, for example, "Request availability", "Request price", "Preorder", "Buy", "Cancel", "Request support", etc. Order Types are to be addable and editable in the resulting application. Should I model Order Type as Class or as Enumeration? From the data perspective I can't see the difference actually.
I would prefer an enumeration. Classes should define properties and behaviour. In this case the type represents only a value with no need of methods.
Conclusion:
The usage of a class would surely possible but not necessary if you only want to represent values. Also, it would create a lot of extra coding work. You would have to write and maintain a bunch of classes that only represent one value when you could use an enumeration, which is surely the best and shortes way to represent typed values.
I want to visualize an situation with a few different objects, their relations and the values of their instance variables. Any idea which diagram type fits best for that?
Object diagram.
It's like a class diagram except the attribute boxes have values.
Also, the lines between objects are "links" not "associations". They're the actual link (FK, object reference, whatever) not the class of the link.