I am not sure which relationship between classes would be adequate for a class which returns a created object or gets an object as parameter(see uploaded picture). I guess that aggregation/composition is wrong since Class1 does not own the object/does not have it as an attribute. Also I think that an association is wrong since Class1 does not refers to a pointer.
Thank you in advance for any answers.
That would simply be dependencies:
An association is created in case you have a stronger relation between classes. That is either one is holding a more permanent relation (in form of an attribute) rather than a temporary one like in using them as passing parameter or return parameter. From an UML point of view an association is basically a stronger form of a dependency.
Note that the untyped attributes you sketched are of no interest in this context and I just left them out.
According to a comment of #www.admiraalit.nl: If Class1 creates new instances of Class3, the dependency may have the ≪create≫ stereotype, see table 22.1 of the UML spec. v2.5.1. In that case the dependency would be a usage (chap. 7.8.23) which is just a bit stronger
a class which returns a created object or gets an object as parameter(see uploaded picture)
you mean for a class having an operation returning ... and an other getting ...
I guess that aggregation/composition is wrong since Class1 does not own the object/does not have it as an attribute
you are right
Also I think that an association is wrong since Class1 does not refers to a pointer.
whatever by pointer or by value (which is target language dependent) an association is not right because there is no attribute in Class1 whose type is Class2 or Class3
The only possible relation between Class1 and Class2 or Class3 seems to be a dependency, but to have them does not have a real plus value, the profile of the operations already give that information
Related
I am having trouble understanding my professor's lecture notes because my brain seem to treat objects, attributes, variables and class instance as interchangeable. I really appreciate any help in distinguishing these 4 terms. Thank you!
this would be helpful for u Visit https://www.quora.com/What-is-the-difference-between-instance-variable-and-class-variable
Class variables are declared with keyword static and Instance variables are declared without static keyword.
Class variables are common to all instances of a class. These variables are shared between the objects of a class. Instance variables are not shared between the objects of a class. Each instance will have their own copy of instance variables.
As class variables are common to all objects of a class, changes made to these variables through one object will reflect in another. As each object will have its own copy of instance variables, changes made to these variables through one object will not reflect in another object.
Class variables can be accessed using either class name or object reference. Instance variables can be accessed only through object reference.
https://qph.fs.quoracdn.net/main-qimg-c4b92e80a8500c11fe705c1bafc3ed26
You don't mention the programming language at question.
Usually a class is a model or template that declares
how a certain category of objects look like.
You give a class a name and you mention if it inherits
members from another class or not.
You define also the class members.
These can be variables that hold data (object state)
and methods (class defined functions) that define
the object behaviour.
When you instantiate a class using the declared model
, you get an object, that is a concrete class instance.
This is a concrete entity, think of it as a new variable in memory,
whose data type is the class (instead of for example
integer or string data types), whose value is its state
in a defined moment in time (the state being the
combination of all of its data member variables values
at that moment). This object has to have an identity,
because it exists in memory and it is a different entity
from the other objects you can instantiate from this or
any other class. The data member variables hold specific
values for each instance. These are not shared between
instances.
Now the member methods can be shared between instances
because they have no state, so they are equal for every object.
They are called with some arguments
and they do some action that changes the object state, or
is at least tightly related with the concrete object.
But they are common to every object. The methods usually
know what concrete object they act upon by means of a special
name like 'this' or 'self', that references to 'itself'.
Objects are usually assigned to variables upon creation,
storing a reference to its identity that allows the
remaining code to manipulate them.
You use these variables to refer to the concrete object
outside the code of the classes, and use 'this' or 'self'
to refer to it from inside the classes.
Frequently you access object members qualifying with the
object name. Like in 'player.run()', or 'player.total_score'.
That is if player is a variable to which you assigned a
class Player instance. This can look like player = new Player
or player = Player().
Attributes is just another name given to data members.
Sometimes attributes and also methods can be public or private,
meaning code outside the class can use them, or only
the class code can have access.
Sometimes you see data members or attributes referred as
properties. When you access an attribute, you are accessing
a property. In some languages like Python, property can mean
something a little different but close related anyway...
Now also depending on the language things can be like described
(C++, Java) or you can have everything being treated as objects,
including the class definitions (Python).
You should also search the internet or SO about
inheritance, overriding, class diagrams, and other things class
related.
This is all no more than the ability of defining your own data types
beoynd the language builtin types.
You can think of variables as names for boxes (memory containers in a certain address) holding values. But sometimes you want to manipulate
not the values but the addresses themselves. This time you say you have
references (to addresses). Sometimes variables are just names for those
references. References are also known as pointers. But you could do math with pointers (increment, decrement, add a fixed value to...) that you usually don't do with references.
I want to make sure that my understanding of the concepts of class, object, and instance are accurate so if I am wrong, please provide feedback.
The class is "Human", with specifications such as height, weight, age, etc. Their methods are run, eat, talk, walk, and other actions.
These are the objects of the class "Human": Sally, Paul, Ray, Bob, with different values for the specifications.
One of these objects for example Sally, is an instance.
Did I get these right?
If you add 'name' as a member variable of the class Human, then it would be correct to say that the object with the name 'Sally' is an instance of the Human class, though if it's at all possible that you could have two different humans named "Sally," you'd be wise to add an 'id' member variable which would be guaranteed to be unique.
The values of the member variables are not required for an 'instance,' though. You can create a new 'instance' of the Human class in which none of the member variables have values. It's still an instance of class Human and you could still call it's class methods (which might or might not work depending on how they're written and what they do).
Is the following format wrong if I add a pointer to an object of a class, as data attribute of class in Class diagram in UML?
could not find anything about using objects in class diagram, is
underlining the object correct within the class attributes?
I think you may be mis-understanding classes, objects and attributes. Apologies if it's me doing the mis-understanding. So. Here's the short answer:
it's absolutely fine and normal for the type of an attribute to be a Class. In other words, you're not restricted to using primitive types like int, long, char etc.
The consequence is, as you say, that the values of those attributes at run time will themselves be objects. Specifically, instances of the classes Ability, Move and See.
More specifically, each instance of Agent (i.e. each Agent object) will hold references - or more precisely pointers - to 3 other objects: one instance each of Ability, Move and See.
So, assuming that's right, what you have is correct - except for the underlining.
Underlining an attribute or operation says it sits at the class level - not the instance level. It's the equivalent of static in java. Think of declaring constants in class scope, or constructors.
If I understand your model that's not what you want. You want each instance of Agent to hold (a pointer to) its own instances of Ability, Move and See. You don't want all the Agent objects to share the same 3 instances. Assuming so, you don't need the underline.
Hope I understood and that helps.
I am totally new to the domain of semantic web and need to create an ontology.
I did a lot of research, but still didn't find a clear solution to the following problem:
Basically, I want to describe semantically, that a certain class contains certain objects and attributes. But it's not 100%ly clear to me how to do that.
Example: I want to describe the class "device". Now this class contains an object "application", and an attribute "ID".
I got as far as mapping the object "application" to an ObjectProperty "hasApplication", and the attribute mapped to a DatatypeProperty "ID". So far so good, but now how do I bind them to the class?
There were two main ways I found:
Either you include the class name as domain in the definition of a property.
Or you include the properties into the class definition via owl:Restricion/owl:onProperty.
But in my opinion, both ways do not capture accurately my semantic intention, because in the first case, I understand it as, that if ever an object uses the defined property, then this object has to be an instance of the class defined in the domain, BUT that does not necessarily mean that every instance of this class must have this property.
Similarly, in the second case, binding a property to a class via owl:Restriction/owl:onProperty, imposes that I put a restriction on this property, i.e. cardinality or range of values. But that is not my intention, I do not want to describe "This class has this property with this restriction.", but simply "This class has this property."
Hope you guys can clear things up a bit. :S
Going with your example, you have a class Device, and you have a class Application and an ObjectProperty for relating them. In OWL Manchester syntax:
Class: Device
Class: Application
ObjectProperty: hasApplication
It's a bit misleading to think about Applications in terms of 'object contained in the Device class'. Think of them rather as objects related to that class.
Now, you can make the relation between Devices and Applications globally available by setting the domain and range of your property:
ObjectProperty: hasApplication
Domain: Device
Range: Application
However, this may not quite be what you're after, since this only says that if a hasApplication relation occurs anywhere, its subject and and object can be inferred to be of type Device and Application, respectively. It does not say that all instances of Device must have a hasApplication property.
To express that all instances of Device must have a hasApplication property, you can use an OWL cardinality restriction:
Class: Device
SubClassOf: hasApplication min 1
This tells us that any instance of Device must have at least 1 hasApplication property.
As we know, Scala generates getters and setters automatically for any public field and make the actual field variable private. Why is it better than just making the field public ?
For one this allows swapping a public var/val with a (couple of) def(s) and still maintain binary compatibility. Secondly it allows overriding a var/val in derived classes.
First, keeping the field public allows a client to read and write the field. Since it's beneficial to have immutable objects, I'd recommend to make the field read only (which you can achieve in Scala by declaring it as "val" rather than "var").
Now back to your actual question. Scala allows you to define your own setters and getters if you need more than the trivial versions. This is useful to maintain invariants. For setters you might want to check the value the field is set to. If you keep the field itself public, you have no chance to do so.
This is also useful for fields declared as "val". Assume you have a field of type Array[X] to represent the internal state of your class. A client could now get a reference to this array and modify it--again you have no chance to ensure the invariant is maintained. But since you can define your own getter you can return a copy of the actual array.
The same argument applies when you make a field of a reference type "final public" in Java--clients can't reset the reference but still modify the object the reference points to.
On a related note: accessing a field via getters in Scala looks like accessing the field directly. The nice thing about this is that it allows to make accessing a field and calling a method without parameters on the object look like the same thing. So if you decide you don't want to store a value in a field anymore but calculate it on the fly, the client does not have to care because it looks like the same thing to him--this is known as the Uniform Access Principle
In short: the Uniform Access Principle.
You can use a val to implement an abstract method from a superclass. Imagine the following definition from some imaginary graphics package:
abstract class circle {
def bounds: Rectangle
def centre: Point
def radius: Double
}
There are two possible subclasses, one where the circle is defined in terms of a bounding box, and one where it's defined in terms of the centre and radius. Thanks to the UAP, details of the implementation can be completely abstracted away, and easily changed.
There's also a third possibility: lazy vals. These would be very useful to avoid recalculating the bounds of our circle again and again, but it's hard to imagine how lazy vals could be implemented without the uniform access principle.