Whenever I extend two interfaces from the same interface, in the diagram, it creates separate arrows. I just want a single arrow with branching like this.
Is there any script in PlantUML to do this?
The set of tools - GraphViz - used by PlantUML is primarily for drawing graphs (i.e. nodes and edges); hence the individual realization relationships.
While showing realizations as such is useful at times for depicting interface hierarchies, diagrams can quickly become a "rat's nest" of relationships, potentially obscuring the bigger picture.
You might consider preferring the use of the short-hand "Lollipop" notation to indicate realizations of an interface. For example,
Layout can be a bit tricky at times if you want to show interface details in the same diagram. The script to produce the above is as follows:
#startuml
together {
interface Widget {
callFred()
callBarney()
}
class A
class B
class C
}
Widget ()- A
Widget ()- B
Widget ()- C
#enduml
If you just want two inheriting entities to share an arrow, you can connect the second to the line connecting the first entity to its generalization:
class Entity
class Generalization
class OtherEntity
Generalization <|-- Entity
(Entity, Generalization) -- OtherEntity
Unfortunately if you try this for more it generates more lines so doesn't work. Eg.
class Entity
class Generalization
class OtherEntity
Generalization <|-- Entity
(Entity, Generalization) -- OtherEntity
class AnotherEntity
(Entity, Generalization) -- AnotherEntity
gives this:
which isn't what we want.
Related
I am wondering why public biomedical ontologies are often organized in such a way that there are no class instances and only classes? I understand it in a way that all instances are classes, but I do not understand what is the advantage or purpose of such modelling? Those classes have also only annotation properties. For example NCIT ontology: https://bioportal.bioontology.org/ontologies/NCIT/?p=summary.
I would appreciate if someone could provide me with an explanation what is the purpose of such model and if there is an advantage to a model where classes have class instances. I am definitively not an expert in the field and I only was working on modelling 'standard' ontologies with classes and their instances.
TLDR
The reason for preferring classes over individuals (or instances) is that classes allow for sophisticated reasoning which is used to infer classification hierarchies.
The longer answer
The semantics of OWL allows you to make the following type of statements:
ClassExpression1 is a subclass of ClassExpression2
PropertyExpression1 is a subproperty of PropertyExpression2
Individual c1 is an instance of Class1
Individual x is related to individual y via property1
Of these 4 options, (1) by far allows for the most sophistication. Intuitively it comes down to how much each of these allow you to express and the reasoning capability to derive inferences from those statements. To get an intuitive feel of this, using the OWL Direct Semantics, we can see what
ClassExpression1 and ClassExpression2 can be substituted with:
There no way that this expressivity can be achieved using individuals.
Individuals vs Classes
In your question you say that all instances (individuals) are classes. This is not exactly true. Rather, classes consists of instances or instances belong to classes. From a mathematical perspective classes are sets and individuals are members of a set.
Annotations in biomedical ontologies
These ontologies have a substantial (80%-90%) amount of annotations. However, they do have lots of logical axioms. You can see it for example when you look at http://purl.obolibrary.org/obo/NCIT_C12392 on the righthandside, if you scroll down to the bottom, you will see the axioms listed:
I am working on a ClojureScript wrapper for qx.mobile and would like to programmatically build a cljs type hierarchy mirroring the qx class hierarchy.
Is there a way to get all the subclasses of a qooxdoo class?
How about a programmatic way to query the superclass of a class?
I am already putting qx.Class.getProperties to good use.
Thx, kt
The programmatic way of getting the superclass of a given class is documented at http://demo.qooxdoo.org/current/apiviewer/#qx.Class
<classname>.superclass
or getting the name of the superclass as a string
<classname>.superclass.classname
which means that e.g.
qx.ui.core.Widget.superclass.classname
will return the string "qx.ui.core.LayoutItem".
Regarding the programmatic way to retreive all subclasses of a class:
This is currently not possible without iterating the whole class hierarchy/tree and testing the objects against being subclasses of the given class.
We discussed at https://gitter.im/qooxdoo/qooxdoo that it maybe would be usefull to create an array for each class holding the subclasses. This could be added to the code of the private method __createClass in qx.Class.
We would like to encourage everyone who needs this (or other) functionalities to join us on https://github.com/qooxdoo/qooxdoo/ and help extending qooxdoo by creating a pull requests. Thank you.
After digging arround a bit in qx.Class we decided to implement a method qx.Class.getSubclasses which returns a hash object with all subclasses of a given class.
var subclasses = qx.Class.getSubclasses(qx.ui.core.Widget);
gets all subclasses of qx.ui.core.Widget.
Landed in qooxdoo master with commit https://github.com/qooxdoo/qooxdoo/pull/9037
I am working on a django project in which I create a set of three abstract models that I will use for a variety of apps later on. The problem I am running into is that I want to connect those models via ForeignKey but django tells me that it can't assign foreignkeys to an abstract model.
My current solution is to assign foreignkeys when I instanciate the class in my other apps. However, I am writing a Manager for the abstract classes (book and pages) right now and would need to access these foreignkeys. What I am basically trying to do is to get the number of words a book has in a stateless manner, hence without storing it in a field of the page or book.
The model looks similar to this:
class Book(models.Models):
name = models.CharField(...)
author = models.CharField(...)
...
class Meta:
abstract = True
class Page(models.Models):
book = models.ForeignKey(Book)
chapter = models.CharField(...)
...
class Meta:
abstract = True
class Word(models.Models):
page = models.ForeignKey(Page)
line = models.IntegerField(...)
...
class Meta:
abstract = True
Note that this model here is just to give an example of what I am trying to do, hence whether this model (Book-Page-Word) makes sense from an implementation standpoint is not needed.
Maybe what you need here is a GenericForeignKey, since you don't actually know what model your ForeignKeys will point to? That means that you'll loose some of the "type-safety" guarantees of a normal relation, but it will allow you to specify those relationships in a more general way. See https://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/#django.contrib.contenttypes.generic.GenericForeignKey
Django model inheritance is a cool thing, and nice as a shortcut for making your models DRYer, but doesn't always play nicely with the polymorphic ideas we generally have of classes.
How about this approach? I'm considering using it myself to delay the relationship definition until I inherit.
# This is a very very contrived (but simple) example.
def AbstractBook(AuthorModel):
class AbstractBookClass(Model):
name = CharField(max_length=10)
author = ForeignKey(AuthorModel)
class Meta:
abstract = True
return AbstractBookClass
class AbstractAuthor(Model):
name = CharField(max_length=10)
class Meta:
abstract = True
class BadAuthor(AbstractAuthor):
pass
class BadBook(AbstractBook(BadAuthor)):
pass
class GoodAuthor(AbstractAuthor):
pass
class GoodBook(AbstractBook(GoodAuthor)):
pass
Two things:
1) The way you constructed your schema, you will need a GenericForeignKey, as already mentioned. But you must take into account that Book through Page have a many-to-many relationship with Word, while a GenericForeignKey just realizes a one-to-many. Django has nothing out-of-the-box yet for the normalized schema. What you will have to do (if you care about normalization) is to implement the intermediate (with "through" for concrete Models) yourself.
2) If you care about language processing, using a relational database (with or without Django's ORM) is not a very efficient approach, considering the resulting database size and query time after a few dozen books. Add to that the extra columns you will need to look up for your joins because of the abstract Models, and it will soon become very impractical. I think that it would be more beneficial to look into other approaches, for example storing only the aggregates and/or denormalizing (even looking into non-relational storage systems in this case), based on your queries and views.
As the red block above (warning that this is a subjective question and may be closed) there may not be a stone etched law on this, but I don't see why that would warrant closing a question.
...Rant aside
I am planning on implementing Hibernate as my persistence framework, which may fix my problem upon implementation, but I have DB tables that translate into class and sub-class (many specifics and complications that exist in real life are omitted :) ):
//dbo.a with column Name
class a {
public String Name;
}
//dbo.b with column Name and a foreign key to dbo.a
class b extends a {
public String Name;
}
So, for the what should be done and why:
Shadowing:
I could leave these as is, which would require some reflection cleverness (per http://forums.sun.com/thread.jspa?threadID=5419973 ), when working with objects whose types are unknown at compile.
Compound Names:
I could name all of my fields preceded by its class's name i.e. a.aName and b.bName, which gets really ugly in real life: Door.DoorName and RotatingDoor.RotatingDoorName
Getters and Setters:
I didn't mention this one, since with JavaBeans these will be derived from the field names, and I believe Hibernate uses annotated POJOs.
To influence the results a little, shadowing seems to be the most robust, at least in my case where class a extends an abstract class with Name defined, then b shadows with its own Name when applicable. Using compound names would mean that if I wanted to add a NickName column to all my DB tables then I would have to add that field to each type (and then what's the point of inheritance?!)
In the end I decided to find out what people, hopefully who have experienced pros/cons of an implementation of one or more of these technique, have to say on the issue; or that convenient stone etched best practice will do :)
-Nomad311
you should only define your member in the base class if you need it in all subclasses. hibernate offers various types of mappings for class trees. take a look at Inheritance mapping in the manual to get a feeling of it.
you can define your mapping either via an xml file or via annotations.
I read this article today http://dotnetslackers.com/articles/silverlight/Silverlight-3-and-the-Data-Form-Control-part-I.aspx about the use of the MVVM pattern within a silverlight app where you have your domain entities and view spesific entities which basically is a subset of the real entity objects. Isn't this a clear violation of the DRY principle? and if so how can you deal with it in a nice way?
Personally, I don't like what Dino's doing there and I wouldn't approach the problem the same way. I usually think of a VM as a filtered, grouped and sorted collections of Model classes. A VM to me is a direct mapping to the View, so I might create a NewOrderViewModel class that has multiple CollectionViews used by the View (maybe one CV for Customers and another CV for Products, probably both filtered). Creating an entirely new VM class for every class in the Model does violate DRY in my opinion. I would rather use derivation or partial classes to augment the Model where necessary, adding in View specific (often calculated) properties. IMO .NET RIA Services is an excellent implementation of combining M and VM data with the added bonus that it's usable in on both the client and the server. Dino's a brilliant guy, but way to call him out on this one.
DRY is a principle, not a hard rule. You are a human and can differentiate.
E.g. If DRY really was a hard rule you would never assign the same value to two different variables. I guess in any non trivial program you would have more than one variable containing the value 0.
Generally speaking: DRY does usually not apply to data. Those view specific entities would probably only be data transfer objects without any noteworthy logic. Data may be duplicated for all kinds of reasons.
I think the answer really depends on what you feel should be in the ViewModel. For me the ViewModel represents the model of the screen currently being displayed.
So for something like a ViewCategoryViewModel, I don't have a duplication of the fields in Category. I expose a Category object as a property on the ViewModel (under say "SelectedCategory"), any other data the view needs to display and the Commands that screen can take.
There will always be some similarity between the domain model and the view model, but it all comes down to how you choose to create the ViewModel.
It's the same as with Data Transfer Objects (DTO).
The domain for those two object types is different, so it's not a violation of DRY.
Consider the following example:
class Customer
{
public int Age
}
And a corsponding view model:
class CustomerViewModel
{
public string Age;
// WPF validation code is going to be a bit more complicated:
public bool IsValid()
{
return string.IsNullOrEmpty(Age) == false;
}
}
Differnt domains - differnet property types - different objects.