I reversed some Java code to get a uml class diagram using Visual Paradigm. The diagram shows some associations with little black circles on one end, which I never saw before.
Image
It's definitely not a composition and not a containment! Can anybody explain to me, what kind of association this is?
Here's the related code:
public class DataAdapter extends RecyclerView.Adapter<DataAdapter.ViewHolder> {
public static final String TAG = DataAdapter.class.getSimpleName();
private static Context mContext;
private ArrayList<DataClass> mData;
private static OnItemClickListener<DataClass> mListener;
public static class ViewHolder extends RecyclerView.ViewHolder {}
public DataAdapter(Context context, ArrayList<DataClass> data) {}
public void setOnClickListener(OnItemClickListener listener) {}
#Override
public int getItemCount() {}
#Override
public ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {}
#Override
public void onBindViewHolder(ViewHolder holder, int position) {}
}
public interface OnItemClickListener<T> {
public void onItemClick(T item);
}
What you are seeing is the ownership indicator, commonly known as the dot
In this case it indicates that the property at right side of the association is owned by the class on the left side.
From the UML specs v2.5:
Ownership of Association ends by an associated Classifier may be
indicated graphically by a small filled circle, which for brevity we
will term a dot. The dot is to be drawn integral to the graphic path
of the line, at the point where it meets the Classifier, inserted
between the end of the line and the side of the node representing the
Classifier. The diameter of the dot shall not exceed half the height
of the aggregation diamond, and shall be larger than the width of the
line. This avoids visual confusion with the filled diamond notation
while ensuring that it can be distinguished from the line. The dot
shows that the model includes a Property of the type represented by
the Classifier touched by the dot. This Property is owned by the
Classifier at the other end. In such a case it is normal to suppress
the Property from the attributes compartment of the owning Classifier.
To adorn Geert's correct answer: In former UML versions navigability (an open arrow at either side) was (mis-) used for that purpose. So now that you see a dot it also means you can navigate towards it (because it renders an attribute of the class type it's touching). It is still possible to mix both notations. But it does not make much sense. Personally I'd use (if ever) navigational arrows only in a conceptual phase.
Related
To find elements that are intersecting a geometry I am using the example post by Jeremy in his blog http://thebuildingcoder.typepad.com/blog/2010/12/find-intersecting-elements.html. But the bounding box is always paralell to the axis X, Y and Z and this may cause a problem, like return elements that are not really clashing, because sometimes the bounding box it's not always coincident with the geometry because the family instance is rotated. Besides that, there is the problem that the bounding box will consider the geometry of the symbol and not the instance, and will consider the flipped geometry too, it means that the bounding box is bigger than I am looking for. Is there a way to get the real geometry that are in the currently view ? How can I solve this problem ?
There are many way to address this. Generally, when performing clash detection, you will always run a super fast pre-processing step first to determine candidate elements, and then narrow down the search step by step more precisely in following steps. In this case, you can consider the bounding box intersection the first step, and then perform post-processing afterwards to narrow down the result to your exact goal.
One important question is: does the bounding box really give you all the elements you need, plus more? Are you sure there are none missing?
Once that is settled, all you need to do is add post-processing steps applying the detailed considerations that you care about.
A simple one might be: are all the target element geometry vertices contained in the target volume?
A more complex one might involve retrieving the full solid of the target element and the target volume and performing a Boolean intersection between them to determine completely and exactly whether they intersect, are disjunct, or contained in each other.
Many others are conceivable.
I am using another strategy that is acess the geometry of the instance to verify if the face of the family instace are clashing with a closer conduit.
class FindIntersection
{
public Conduit ConduitRun { get; set; }
public FamilyInstance Jbox { get; set; }
public List<Conduit> GetListOfConduits = new List<Conduit>();
public FindIntersection(FamilyInstance jbox, UIDocument uiDoc)
{
XYZ jboxPoint = (jbox.Location as LocationPoint).Point;
FilteredElementCollector filteredCloserConduits = new FilteredElementCollector(uiDoc.Document);
List<Element> listOfCloserConduit = filteredCloserConduits.OfClass(typeof(Conduit)).ToList().Where(x =>
((x as Conduit).Location as LocationCurve).Curve.GetEndPoint(0).DistanceTo(jboxPoint) < 30 ||
((x as Conduit).Location as LocationCurve).Curve.GetEndPoint(1).DistanceTo(jboxPoint) < 30).ToList();
//getting the location of the box and all conduit around.
Options opt = new Options();
opt.View = uiDoc.ActiveView;
GeometryElement geoEle = jbox.get_Geometry(opt);
//getting the geometry of the element to acess the geometry of the instance.
foreach (GeometryObject geomObje1 in geoEle)
{
GeometryElement geoInstance = (geomObje1 as GeometryInstance).GetInstanceGeometry();
//the geometry of the family instance can be acess by this method that returns a GeometryElement type.
//so we must get the GeometryObject again to acess the Face of the family instance.
if (geoInstance != null)
{
foreach (GeometryObject geomObje2 in geoInstance)
{
Solid geoSolid = geomObje2 as Solid;
if (geoSolid != null)
{
foreach (Face face in geoSolid.Faces)
{
foreach (Element cond in listOfCloserConduit)
{
Conduit con = cond as Conduit;
Curve conCurve = (con.Location as LocationCurve).Curve;
SetComparisonResult set = face.Intersect(conCurve);
if (set.ToString() == "Overlap")
{
//getting the conduit the intersect the box.
GetListOfConduits.Add(con);
}
}
}
}
}
}
}
}
}
Can you please provide a complete minimal reproducible case so we can understand the exact context and analyse what can be done? Maybe you could include one axis-aligned junction box and one that is not, so we can see how ell versus how badly your existing algorithm performs. Thank you!
I summarised this discussion and the results to date in a blog post on filtering for intersecting elements and conduits intersecting a junction box.
Here are the signatures :
abstract sig Color{}
lone sig Red, Blue, Yellow, Green extends Color{}
abstract sig Vertex{
couleur: Color
}
abstract sig Digraph{
vertices: set Vertex,
edges: set(Vertex -> Vertex)
}
fact{
vertices.couleur != edges.couleur
}
I get an error saying that I can't use "!=" between 2 expressions that aren't the same arity. I get why, but I don't know how I can solve this.
What I want to do is, forbidding the two vertices color to be the same in an edge. Any ideas ?
The answer is very simple: the expression vertices.couleur != edges.couleur does not typecheck since vertices and edges, and thus also the operands of !=, are of different arity. (Essentially, you are trying to compare a set of Color to a set of (Color -> Vertex).)
As an example, if you take the image of the edges relation (by projecting it onto the universal set), you will not get the error:
fact {
vertices.couleur != edges.univ.couleur
}
(For more info about the basic operators in Alloy, it would be useful to check the tutorial and/or the Alloy book.)
Let's say that I want to calculate the distance between two geometries with JTS, but there is another one in the middle that I can't go across (as if it was a wall). It could look like this :
I wonder how I could calculate that.
In this case, these shapes geom1 and geom2 are 38.45 meters away, as I calculate it straight away. But if I don't want go across that line, I should surround it by the Northern sides, and distance would probably be more than 70 meters away.
We can think that we could have a line a polygon or whatever in the middle.
I wonder if there is any built in function in JTS, or some other thing I could you. I guess if there is anything out there, I should check for some other workaround, as trying to solve complex routing problems is beyond my knowledge.
This is the straight away piece of code using JTS for the distance, which would not still take into account the Geometry in the middle.
import org.apache.log4j.Logger;
import com.vividsolutions.jts.geom.Geometry;
import com.vividsolutions.jts.io.ParseException;
import com.vividsolutions.jts.io.WKTReader;
public class distanceTest {
private final static Logger logger = Logger.getLogger("distanceTest");
public static void main(String [] args) {
//Projection : EPSG:32631
// We build one of the geometries on one side
String sGeom1="POLYGON ((299621.3240601513 5721036.003245114, 299600.94820609683 5721085.042327096, 299587.7719688322 5721052.9152064435, 299621.3240601513 5721036.003245114))";
Geometry geom1=distanceTest.buildGeometry(sGeom1);
// We build the geometry on the other side
String sGeom2=
"POLYGON ((299668.20990794065 5721092.766132105, 299647.3623194871 5721073.557249224, 299682.8494029705 5721049.148841454, 299668.20990794065 5721092.766132105))";
Geometry geom2=distanceTest.buildGeometry(sGeom2);
// There is a geometry in the middle, as if it was a wall
String split=
"LINESTRING (299633.6804935104 5721103.780167559, 299668.99872434285 5720999.981241705, 299608.8457218057 5721096.601805294)";
Geometry splitGeom=distanceTest.buildGeometry(split);
// We calculate the distance not taking care of the wall in the middle
double distance = geom1.distance(geom2);
logger.error("Distance : " + distance);
}
public static Geometry buildGeometry(final String areaWKT) {
final WKTReader fromText = new WKTReader();
Geometry area;
try {
area = fromText.read(areaWKT);
}
catch (final ParseException e) {
area = null;
}
return area;
}
}
This works for SQL, I hope you have the same or similar methods at your disposal.
In theory, in this instance you could create a ConvexHull containing the two geometries AND your "unpassable" geometry.
Geometry convexHull = sGeom1.STUnion(sGeom2).STUnion(split).STConvexHull();
Next, extract the border of the ConvexHull to a linestring (use STGeometry(1) - I think).
Geometry convexHullBorder = convexHull.STGeometry(1);
EDIT: Actually, with Geometry you can use STExteriorRing().
Geometry convexHullBorder = convexHull.STExteriorRing();
Lastly, pick one of your geometries, and for each shared point with the border of the ConvexHull, walk the border from that point until you reach the first point that is shared with the other geometry, adding the distance between the current and previous point at each point reached. If the second point you hit belongs to the same geometry as you are walking from, exit the loop and move on to the next to reduce time. Repeat for the second geometry.
When you've done this for all possibilities, you can simply take the minimum value (there will be only two - Geom1 to Geom2 and Geom2 to Geom1) and there is your answer.
Of course, there are plenty of scenarios in which this is too simple, but if all scenarios simply have one "wall" in them, it will work.
Some ideas of where it will not work:
The "wall" is a polygon, fully enveloping both geometries - but then how would you ever get there anyway?
There are multiple "walls" which do not intersect each other (gaps between them) - this method will ignore those passes in between "walls". If however multiple "walls" intersect, creating essentially one larger "wall" the theory will still work.
Hope that makes sense?
EDIT: Actually, upon further reflection there are other scenarios where the ConvexHull approach will not work, for instance the shape of your polygon could cause the ConvexHull to not produce the shortest path between geometries and your "walls". This will not get you 100% accuracy.
I have the following class:
public class Vertex() {
private double xCoord;
private double yCoord;
private ArrayList<Vertex> neighborList();
}
And I want to support adding/removing vertices to the neighborList such that the points are listed in CCW order around this vertex (which point is first in the list doesn't matter). If points are collinear, nearer points to this should be first. I've tried several methods but so far have always been able to find a counter example that doesn't work for the given method.
Does anyone have a good idea of how to do this in a simple and efficient manner?
Express the point coordinates in the polar form
t = atan2(Y-Yo, X-Xo)
r = sqrt((X-Xo)^2 + (Y-Yo)^2)
and use lexicographical ordering on angle then radius.
i'm trying to come up with appropriate constant names for two right-angled triangles that can be rotated.
the image above shows the two different versions of a right-angled triangle. the right angle of the orange triangle is in the bottom-right while the right angle of the blue triangle is in the bottom-left.
from that, let's assume i will name each constant as:
public static const RIGHT_ANGLE_BOTTOM_RIGHT:String = "rightAngleBottomRight";
public static const RIGHT_ANGLE_BOTTOM_LEFT:String = "rightAngleBottomLeft";
besides those constant names being quite long and not very descriptive, these triangles can be rotated. therefore, if the orange triangle (RIGHT_ANGLE_BOTTOM_RIGHT) is rotated -90ยบ, its name is now misleading (and conflicting) since its right angle is now in the bottom left of the triangle shape.
so i'm searching for constant names for these rotatable, right-angled triangles which are clear and distinguishing (and ideally short). currently, my "best" is simply calling them type 1 and type 2. while those names are unmistakably distinguishing, it certainly isn't at all clear of their shape, especially since they can be rotated.
package
{
public final class TriangleStyle
{
public static const ISOSCELES:String = "isosceles";
public static const RIGHT_Type1:String = "right1";
public static const RIGHT_Type2:String = "right2";
}
}
any thoughts?
Perhaps HOA and HAO -- I'll leave the derivation to you -- and note that these names are invariant under rotation.