This question is about Ontologies , I am implementing an ontology about potential physical attacks on wireless sensors as devices.
I created class Modification_Attack meaning attacks which modify in the sensor itself. I created Programming_Modification as an instance of this class, is this logical, is it better a sub-class or neither an instance nor a sub-class?
What is the main difference between instances and sub-classes?
This question isn't really unique to OWL ontologies; it comes up in object-oriented programming, and in set theory in mathematics. A class is a collection of its members. E.g.,
Person ≡ { person1, person2, … }
Suppose you have another class:
TallPerson ≡ { person63, person102, … }
A class A is a subclass of the class B if every element of A is also an element of B:
(A ⊆ B) ≡ (x ∈ A → x ∈ B)
So, for instance, if every member of TallPerson is also a member of Person, then TallPerson is a subclass of Person.
I created class Modification_Attack meaning attacks which modify in
the sensor itself.I created Programming_Modification as an instance of
this class , is this logical , is it better a sub-class or neither an
instance nor a sub-class?
This is a choice that you need to make. It really depends on the context and how you intend to use the ontology. If you're observing attacks in the wild and trying to categorize them, you probably want a subclass, but you'll want to have instances of Programming_Modification. That is, you'll want something like:
Programming_Modification ≡ { attack24, attack89, … }
But if you've got some other kind of use case, where you you want to talk about Programming_Modification as a single entity, then it might make more sense for it to be an individual.
I have been thinking through the same issue. And I think the same thing can be both an instance and a subclass depending on whether you plan to use it conceptually or not, which can be simplified to whether you would describe it using the or a.
For example, I am working on a materials ontology, where the main class is Material. A particular type of material is Steel. If I say the steel then steel an instance of Material. If I say a steel then Steel is a subclass of Material. Further, steel is an instance of Steel. And it would be more appropriate to also give it some kind of meaningful identifier like steel-1.
It all seems to come down whether you are using a term as a conceptual class or as a name for some instance of that class. In your case, I think it would probably be more appropriate to say Programming_Modification is a subclass as you could probably have many of such modifications which you would refer to as the first Programming_Modification or the second Programming_Modification . Would love to see what you came up with though if you have a solution.
Related
I am reading Autosar document and in one of the document (Autosar_TemplateModelingGuideline.pdf), it says that:
Composite aggregation, forming a whole-part relationship
Regular association, expressing a reference from the associating to
the associated model element
My question is: what is the difference between these two in practice? How do I have to interpret them in a class diagram, e.g. the Com Module in Autosar.:
The AUTOSAR COM module’s Configuration Overview
Consider Specified class ComGwSignalRef surrounded with a red rectangle. This class has a composition relation with ComGwSignalRef class and two regular association with ComGroupSignal and ComSignal.
How would you interpret this as a developer and how do you implement in C?
if regular association is a reference to an object that has independent life from ComGwSignalRef why designer do not use instanceRef here?
if it is not a reference, why did the designer not use composition?
PS. There is a concept in Autosar "InstanceRef" which is used for reference for independent object with independent lifecycle.
Maybe you should also consider the following:
The Com Configuration is an instance of the EcuC configuration meta-model as defined in the AUTOSAR_TPS_EcuConfiguration.
The ComGwSignalRef is of type EcucChoiceContainerDef, and as such, the two destination associations of ComSignal and ComGroupSignal have a meaning. Only one of these "choices" can be selected in the final configuration as a reference. In AUTOSAR metamodel, that is the definition of how EcucChoiceContainerDef works, in UML you might need here an additional constraint element to define the XOR relation of two associations.
An object can only be composed as part of one object.
A <>- C -<>B
In the diagram above C is composed in A and B. This would lead to the following instances:
a: A <>- c: C -<> b:B
Now the specific instance c is now part of both a and b.
What happen would with c if b goes out of scope? By the semantics it should be destroyed and not be destroyed (a still exists).
Or more pointed:
Take Alice,Bob, and Collar Bone as examples. Alice’s collar bone cannot be part of Bob.
UML is a modeling language and has not the same expressiveness as, say a C compiler. This is by design to simplify things.
Remember: All models are wrong, but some are useful. — George E. P. Box
I tried to use the same object property between multiple classes, but I got a warning that the same object property has been set multiple times as follows, can you please let me know what is wrong with that and how to solve it? Does this restrict reasoning later on (i.e. confuse the reasoner since the same object property is set multiple times)?
Thanks
Contrary to the comments it actually is very problematic to use the same object property between multiple classes.
What you don't see in your visualization is that in RDF/OWL, the starting point of your relation arrows is modelled as rdfs:domain and the target point of the arrows is modelled as rdfs:range.
The semantic of an OWL class is that it is a set of individuals and rdfs:domain and rdfs:range specify the domain, respectively range of a relation. That is, they specify the sets of allowed values in subject, respectively object position of a triple with that relation in the predicate position.
If you express your example in RDF Turtle it would look like this:
:hasPart rdfs:domain :ClassA, :ClassB;
rdfs:range :ClassB, :ClassC, :ClassD.
This causes multiple problems:
Intersection
The semantic of multiple domains, respectively ranges, is the intersection of those classes, not the union!
Even if we disregard the relation between :ClassB and :ClassD, this means :hasPart is only allowed by individuals that are instances of class C and class D at the same time!
For example, lets say class A is "car", class B is "tire" and class C is "motor". Now you want to say that a car can have tires and motors but what you actually specify is that a car can only have things that are a motor and a tire at the same time!
Unwanted but allowed usage
If you fix the first problem but specifying the union instead of the intersection, it will be very messy in serialized RDF because you need a large amount of triples to represent OWL restrictions such as unions. But even if you do that, you could now connect an instance of class A with an instance of class D, which is not allowed in the image.
Solution
The solution is simple, just separate those relations, for example into :hasB, :hasC and :hasD, although in a real scenario you can probably find a more suitable naming scheme, where the "has" prefix is often not used. For example, in DBpedia, the property for the country of a city is expressed using dbo:country, not dbo:hasCountry.
I was explaining to a friend a few days ago the concept or inheritance and containers.
He has very little programming knowledge so it was really just a friendly chat.
During the conversation he came to me with a question that i just couldn't answer.
"Why cant you just have an array of the top level class, and add anything to it"
I know this is a bad idea having being told so before by someone far smarter but for the life of me i couldn't remember why.
I mean we do it all the time with inheritance.
Say we have class animal which is parent of cat and dog. If we need a container of both of these we make the array of type animal.
So lets say we didn't have that inheritance link, couldn't we just use the base object class and have everything in the one container.
No specific programming language.
Syntactically, there is no problem with this. By declaring an array of a specific type, you are giving implicit information about the contents of that array. You could well declare a contain of Object instances, but it means you lose all the type information of the original class at compile-time.
It also means that each time you get an object out of the array at runtime, the only field instances and methods you know exist are the fields/methods of Object (which arguably is a compile time problem). To use any of the fields and methods of more specific subclasses of the object, you'd have to cast.
Alternatively, to find out the specific class at runtime you'd have to use features like reflection which are overkill for the majority of cases.
When you take elements out of the container you want to have some guarantees as to what can be done with them. If all elements of the container are returned as instances of Animal (remember here that instances of Dog are also instances of Animal) then you know that they can do all the things that Animals can do (which is more things than what all Objects can do).
Maybe, we do it in programming for the same reason as in Biology? Reptiles and Whales are animals, but they are quite different.
It depends on the situation, but without context, it's definitely okay in most (if not all) object-oriented languages to have an array of a base type (that is, as long as they follow all the substitution principles) containing various instances of different derived types.
Object arrays exist in certain cases in most languages. The problem is that whenever you want to use them, you need to remember what type they were, and stay casting them or whatever.
It also makes the code very horrible to follow and even more horrible to extend, not to mention error prone.
Plant myplant = new Plant();
listOfAnimals.Add(myplant);
would work if the list is object, but you'd get a compile time error if it was Animal.
I have problem with concept and implementation of encapsulation.
Can someone explain it to me?
Encapsulation is a moderately easy concept once you realise it (probably) comes from the same base word as capsule.
It's simply a containment of information.
Encapsulation means that a class publishes only what is needed for others to use it, and no more. This is called information hiding and it means classes can totally change their internals without having an effect on any of their users.
In other words, a dictionary class can begin life as a simple array and progress to a binary tree of words then even maybe to some database access functions, all without changing the interface to it.
In an object oriented world, objects hold both their data and the methods used to manipulate data and that is the pinnacle of encapsulation. One way this is done is to make sure each object knows which functions to call to manipulate its data, and ensure the correct ones are called.
As an example, here's a class for maintaining integer lists in my mythical, but strangely Python-like and therefore hopefully easy to understand, language:
class intlist:
private int val[10] # Slots for storing numbers.
private bool used[10] # Whether slot is used or not.
public constructor:
# Mark all slots unused.
for i in 0..9:
used[i] = false
public function add(int v) throws out-of-memory:
# Check each slot.
for i in 0..9:
# If unused, store value, mark used, return.
if not used[i]:
used[i] = true
val[i] = v
return
# No free slots, so throw exception.
throw out-of-memory
public function del(int v) throws bad-value:
# Check each slot.
for i in 0..9:
# If slot used and contains value.
if used[i] and val[i] == v:
# Mark unused and return.
used[i] = false
return
# Value not found in any used slot, throw exception.
throw bad-value
public function has(int v):
# Check each slot.
for i in 0..9:
# If slot used and contains value.
if used[i] and val[i] == v:
return true
# Value not found in any used slot.
return false
Now the only information published here are the constructor and three functions for adding, deleting, and checking for values (including what exceptions can be thrown).
Callers need know nothing about the internal data structures being used (val and used), or the properties of the functions beyond their "signatures" (the content of the "function" lines).
Because everything else is encapsulated, it can changed it at will without breaking the code that uses it.
I could, for example, do any of the following:
make the arrays longer;
store the data sorted, or in a binary tree instead of an array to make it faster.
change the used array into a count array (initialised to zero) so that many occurrences of a single number use just the one slot, increasing the quantity of numbers that can be stored where there are duplicates.
store the numbers in a database, located on a ZX-80 retro-computer located in outback Australia, and powered by methane produced from kangaroo droppings (though you may notice a latency change).
Basically, as long as the published API doesn't change, we am free to do whatever we want. In fact, we can also add things to the API without breaking other code, I just can't delete or change anything that users already rely on.
You should note that encapsulation isn't something new with object orientation. It's been around for ages, even in C by ensuring that information is hidden within a module (usually a source file or group thereof with private headers).
In fact, the stdio.h FILE* stuff is a good example of this. You don't care what's actually behind the pointer since all the functions which use it know how to do their stuff.
link text
I always explain it to people is think of yourself as an object. Other people can see your height, they can see if your smiling, but your inner thoughts, maybe the reason while your smiling, only you know.
Encapsulation is more than just defining accessor and mutator methods for a class. It is broader concept of object-oriented programming that consists in minimizing the interdependence between classes and it is typically implemented through information hiding.
The beauty of encapsulation is the power of changing things without affecting its users.
In a object-oriented programming language like Java, you achieve encapsulation by hiding details using the accessibility modifiers (public, protected, private, plus no modifier which implies package private). With these levels of accessibility you control the level of encapsulation, the less restrictive the level, the more expensive change is when it happens and the more coupled the class is with other dependent classes (i.e. user classes, subclasses).
Therefore, the goal is not to hide the data itself, but the implementation details on how this data is manipulated.
The idea is to provide a public interface through which you gain access to this data. You can later change the internal representation of the data without compromising the public interface of the class. On the contrary, by exposing the data itself, you compromise encapsulation, and therefore, the capacity of changing the way you manipulate the data without affecting its users. You create a dependency with the data itself, and not with the public interface of the class. You would be creating a perfect cocktail for trouble when "change" finally finds you.
There are several reasons why you might want to encapsulate access to your fields. Joshua Bloch in his book Effective Java, in Item 14: Minimize the accessibility of classes and members, mentions several compelling reasons, which I quote here:
You can limit the values that can be stored in a field (i.e. gender must be F or M).
You can take actions when the field is modified (trigger event, validate, etc).
You can provide thread safety by synchronizing the method.
You can switch to a new data representation (i.e. calculated fields, different data type)
However, encapsulation is more than hiding fields. In Java you can hide entire classes, by this, hiding the implementation details of an entire API. Think, for example, in the method Arrays.asList(). It returns a List implementation, but you do no care which implementation, as long as it satisfies the List interface, right?. The implementation can be changed in the future without affecting the users of the method.
The Beauty of Encapsulation
Now, in my opinion, to really understand encapsulation, one must first understand abstraction.
Think, for example, in the level of abstraction in the concept of a car. A car is complex in its internal implementation. They have several subsystem, like a transmission system, a break system, a fuel system, etc.
However, we have simplified its abstraction, and we interact with all cars in the world through the public interface of their abstraction. We know that all cars have a steering wheel through which we control direction, they have a pedal that when you press it you accelerate the car and control speed, and another one that when you press it you make it stop, and you have a gear stick that let you control if you go forward or backwards. These features constitute the public interface of the car abstraction. In the morning you can drive a sedan and then get out of it and drive an SUV in the afternoon as if it was the same thing.
However, few of us know the details of how all these features are implemented under the hood. Think of the time when cars did not have a hydraulics directional system. One day, the car manufactures invented it, and they decide it to put it in cars from there on. Still, this did not change the way in which users where interacting with them. At most, users experienced an improvement in the use of the directional system. A change like this was possible because the internal implementation of a car is encapsulated. Changes can be safely done without affecting its public interface.
Now, think that car manufactures decided to put the fuel cap below the car, and not in one of its sides. You go and buy one of these new cars, and when you run out of gas you go to the gas station, and you do not find the fuel cap. Suddenly you realize is below the car, but you cannot reach it with the gas pump hose. Now, we have broken the public interface contract, and therefore, the entire world breaks, it falls apart because things are not working the way it was expected. A change like this would cost millions. We would need to change all gas pumps in the world. When we break encapsulation we have to pay a price.
So, as you can see, the goal of encapsulation is to minimize interdependence and facilitate change. You maximize encapsulation by minimizing the exposure of implementation details. The state of a class should only be accessed through its public interface.
I really recommend you to read a paper by Alan Snyder called Encapsulation and Inheritance in Object-Oriented programming Languages. This link points to the original paper on ACM, but I am pretty sure you will be able to find a PDF copy through Google.
Encapsulation - wrapping of data in single unit. also we can say hiding the information of essential details.
example
You have a mobile phone.... there it some interface which helps u to interact with cell phone and u can uses the services of mobile phone. But the actually working in cell phone is hide. u don't know how it works internally.
hide/bind something : eg: a capsule (which we consume when v r ill)hide/bind some powder form in itself,, means that capsule encapsulate the powder contained it.
Binding of data and behavior i.e functionality of an object in a secured and controlled manner.
or the best example of encapsulation is a CLASS because a class hides class variables/functions from outside d class..
Encapsulation:
Wrapping up data member and method together into a single unit (i.e. Class) is called Encapsulation.
Eg: we can consider a capsule. Encapsulation means hiding the internal details of an object, i.e. how an object does something. Here capsule is a single Unit contain many things. But we cant see what is there in side capsule.
This is the technique used to protect information about an object from other objects. Like variable we can set as private and property as Public. When we access the property then we validate and set it.
We can go through some other examples. Our Laptop. We can use Laptop but what operations are happening inside that we are not knowing. But we can use that. Same like mobile, TV etc.
We can conclude that a group of related properties, methods, and other members are treated as a single unit or object.An encapsulated object is often called an abstract data type.
There are several other ways that an encapsulation can be used, as an example we can take the usage of an interface. The interface can be used to hide the information of an implemented class.
//Declare as Private
private string _LegName;
// Property Set as public
public string LegName
{
get
{
return _LegName;
}
set
{
_LegName=value;
}
public class LegMain
{
public static int Main(string[] args)
{
Leg L= new Leg();
d.LegName="Right Leg";
Console.WriteLine("The Legis :{0}",d.LegName);return 0;
}
}
Note: Encapsulation provides a way to protect data from accidental corruption.
Thank you
Encapsulation means hiding the data. In other words a class only exposes those properties or information which is authorized to be seen. Consider the below exapmle where a certain property called ConfidentialMessage is accesible only to the Admin role. This property is made private and is returned through another method which checks the role of an user and return the message only for admin.
public class Message
{
public Message()
{
ConfidentialMessage = "I am Nemo";
}
private string ConfidentialMessage { get; set; }
public string GetMessage(string name)
{
string message = string.Empty;
if (name == "Admin")
{
message = this.ConfidentialMessage;
}
return message;
}
}
Putting definition of encapsulate
enclose in a capsule, from en- "make, put in" + capsule + -ate .
now capsule meaning is box, case
In real life example if you put things on desk open then it is accessible to anyone but if you put in case then it is accessible with the key of case to open.
Same way in class if you create a variable then it accessible whenever you create object of that class.But if you create function to access the variable then you have created case and function is key to access the variable.
So in programming language we are creating wrapper of the data by using getter and setter and making it private variable.
Encapsulation is a capsule, consider it to be a class enclosing or hiding fields, properties and functions.
Please check below url encapsulation is simplified with simple programming example.
http://itsforlavanya.blogspot.com/2020/08/encapsulation.html?m=1
The problem domain features a large population of named snarks. Some of the snarks are boojums.
There are at least two ways to model this:
// as a property:
class Snark {
string name;
bool is_boojum;
};
// as a list:
class Snark {
typedef long Id;
Id id;
string name;
};
tree<Snark::Id> boojums;
It seems intuitive that if we determined that snarks come in male and female, we would add a "sex" property to the snark class definition; and if we determined that all but five snarks were vanquished subjects, we would make a list of royals.
Are there principles one can apply, or is it a matter of architectural preference?
What problem are you trying to solve?
If the purpose of recording the royalty of the snarks is to display a crown on their heads in the GUI, then it makes sense for it to merely be an attribute. (Alternatively, there could be a RoyalSnark subclass, with an overridden Render method.)
If the purpose is to quickly find all the royal snarks, then a list is more appropriate - otherwise you would need to look at every snark and check its attribute.
I believe that the information entropy associated with the classification can be a guide to which method to use. Low-entropy classifications (i.e. most of the objects have the same value) suggest a list implementation tracking the exceptional cases, while high-entropy classifications (you cannot make any very good predictions about which classification an object will have) suggest a property implementation.
As a derived class:
class Snark
{
virtual void Approach(Creature& approacher) {};
};
class Boojum : public Snark
{
virtual void Approach(Creature& approacher)
{
approacher.softlySuddenlyVanishAway();
}
};
That natural way to do it seems to be a property in all cases.
You might use a list for performance, or to optimise space. Both reasons strike me as potential cases of premature optimisation, breaking encapsulation, and/or storing redundant data with the consequent risk of lack of integrity (because I should still be able to query the object itself to find out if it is royal - I shouldn't have to know that this property is handled in a special way for reasons of performance). You could I suppose hide the list implementation behind a getter, to make it behave as a property.
Also, if these objects were stored in a DB, the performance issue pretty much goes away as the DB layer can create the list at runtime using a query anyway.
If you're asking about database modeling, then it's most straightforward to treat is_boojum as an attribute column in the table Snarks. If you need to search for all boojums, the query is simple:
SELECT * FROM Snarks WHERE is_boojum = 1
This gives logically correct answers, and it's easy to model. It might not be so speedy, because indexing a column with low selectivity (many rows with identical values) isn't very efficient, and might not benefit from the index at all.
But your question was about modeling, not optimization.
Hmmm. My first thought is that, indeed, Boojum is a subtype of Snark. but the specification seems to argue against it, for "the snark was a boojum, you see." Well, that means the snark is_a Boojum, and that would make the inheritance graph cyclic. Can't have that.
On the other hand, I do'nt think there's any indication that a Snark can become a Boojum; either it's a Boojum or it's not.
I think probably you want a Boojum mixin --
abstract class Snark { /*...*/ };
class PlainSnark extends Snark {/*...*/};
class RoyalSnark extends Snark implements Boojum {/*...*/};