I have a class A and it has data members of class B and class C which are composition relationships. As I am going to draw a composition relationship line from B to A and C to A, does this mean I cannot also include the data members within the class A "box" because the relationship is inferred from the composition relationship lines?
I ask because the data member variable names seem a good way to help understand the context and this cannot be represented if you omit the data members from the class A "box"??
I am not sure if there is a cast-iron rule in UML or whether I am free to choose. This is not for auto-generation of code- just human reading.
At least, in UML you can show a name of each property like a figure below.
According to UML specification, both representations of data members, visually depicted association/composition between two classes or in-class data member display) are equivalent. Here is an example (a little bit modified your case, to make it clearer):
Note that association end also show the scope and collection type (besides the name of course). col_B is defined ase private {ordered} collection (like array).
So, getting back to the formal side of UML spec... a, x, aa, col_b and m_c are all co called A's structural features (or properties). They can all be visually depicted using relationsips between the classes or inside the class itself. You can even show "int" data type as a class and link it using a composition!
Which way you will use is up to you, kind of matter of personal taste.
I always apply a simple rule - basic data types (int, boolean, date, string, etc) and their arrays are showed in the class itself, while the class and enumeration based properties are depicted by a relationship (example on the top).
As simple data types are clear and well known and does not have their own properties, I find it clear enough to show them in-class (diagram is simpler and smaller).
The complex data types (classes and enumerations) however typically have their own properties (data members, associations), even inheritances, and I want to make the class structure stand out on my diagarm.
You can use your own logic though.
In a class diagram you cannot model the same composition both showing the association and the attribute, because in the UML semantic that would mean your class has two composition :-)
If in your diagram you already have classes B and C, I suggest you opt for the association ("relationship lines") solution.
To better understand the context, you can put the roles on the association: this is equivalent to the name of your attributes.
Related
It is my understanding that a data structure is essentially a blueprint which contains all the information necessary to create a final product according to its specification, and a data type is a physical implementation or realization of that design (quite similar to the difference between a genotype and phenotype, from biology).
When it comes to object-oriented oriented programming, would it be accurate to say that an abstract class or interface is a data structure, because it contains a set of values and declared behaviors, and that a class which implements that abstract class or interface is a data type, because it is a concrete manifestation of those behaviors?
If this is the case, then what about the distinction between an abstract data type (ADT) and a data type? Are they truly distinct, or is ADT just colloquially shortened to 'data type'?
I ask this because it has seemed to me that these terms are often used interchangeably in conversation, and it made me wonder if my understanding was incorrect.
I am fairly new to answering on stackoverflow and to this sort of data structure vs data types discussion, but hopefully this helps. These links have done a lot for me in addition to what I've been taught:
Is there a difference between 'data structure' and 'data type'?
Explain the difference between a data *structure* and a data *type*
http://cs.lmu.edu/~ray/notes/dtds/
First of all, I'm going to define my usage of the word "implementation" since it seems I might be using it slightly differently than you are. I define implementation like the implementation files in C++. Such implementation contains the source code for how some interface works. For example the implementation of a singly linked list is a bunch of nodes that each contain data with a starting node that points to the next node until the last node points to some sort of null. In that sense, I can't quite say that a data type is a physical implementation of a data structure. A simplified version is that a data structure is actually the physical implementation of one or more data types. For example, a stack is a data type while a LinkedStack is a data structure that implements a stack. Although a data type can represent all possible instances of a data structure as described by the links above, not all data types have to. For example, an int is a data type, but it's not exactly the best idea to say it is a data structure.
To summarize each, please let me go in the order of data types, abstract data types, and then data structures.
Data types or types for short classify data by its values and operations. For example, if the data is 42, is 42 an int or a string? If it's an int, what int is it (what's its value)? Is it positive or negative? What kinds of operations does it have? Can I divide with it? In that sense, data types depend purely on their external behavior.
Now some data types might not specify any sort of implementation and those data types are called abstract data types. Basically, a data type is an abstract data type if the user can't access nor care about access to how the values and operations are implemented. For example, ints are abstract data types since a programmer doesn't need to know and might not care to know how ints work or how ints are added. Yet, said programmer can still work with ints, adding away to his/her content. User made data types that don't reveal its implementation would also be abstract data types. Because of this, many data types are abstract data types. In addition, abstract data types can model similar data types and data structures and be implemented by specific data types and data structures as the links above describe.
Finally data structures are ways to efficiently store data, and they are all about the implementations. For example, a singly linked list and a doubly linked list are different data structures because they have different implementations. Single linked lists only go forward whereas double linked lists can go forward and backward. I described the implementation for singly linked lists above while in short a doubly linked list's implementation is the same as a singly linked list's implementation but each node would also have a pointer to each previous node to allow the doubly linked list to go backward. The gist of data structures is that the implementation (how data is organized/stored) of a data structure is how it is distinguished.
If you want an example of the efficiency doubly linked lists have over singly linked lists, these links are nice:
When is doubly linked list more efficient than singly linked list?
https://social.msdn.microsoft.com/Forums/vstudio/en-US/270bebdb-9032-4fc1-97c6-bc017d7e0a45/when-to-use-single-linked-list-and-when-to-use-double-linked-list?forum=csharpgeneral
Otherwise, hope I was of some use and good luck.
Abstract Data Type
Defines contractual agreement for behavior and state management
Abstract Data Types exists only conceptually. They have no concrete existence in the context of a language. This is why Wikipedia refers to it specifically as a mathematical model.
Data Structure
Class level implementation of the contract defined by an abstract data type.
Data Structures exists in the form of the code that comprises your class definition.
Data Type
Concrete instance of a class
Data Types exists in the form of objects created from classes you defined.
Examples
A Priority Queue is an abstract data type which can be implemented with a Binary Heap data structure.
A List is an abstract data type that can be implemented with an array or linked list data struture
TLDR
Abstract Data Type > Data Structure > Data Type
A method of interpreting a bit pattern is called a data type. There are several data types such as binary integers, binary coded decimal, non-negative integers, real numbers and character strings. E.g.: a bit string 00100110 can be interpreted as the number '38' (binary coded decimal).
If we do some specific operation with data structure, then data structure with these specific operation are called Abstract Data Type. It is a tool for specifying logical properties and operation of data types.
Data Structure is the implementation of the abstract operations.
-source: books, google search....
As I know about,for example,in Python,int float boolare data types,they are built-in classes,str list tuple dict set frozensetare data structures,they are also built-in classes,and we can write linked list linked stack linked queue linked deque positional list array stack array queue linked tree linked binary tree binary search tree AVL tree red black tree splay tree hash table priority queueand etc,we can call these data structure,or ADT,in my opinion,data structure/ADT is to organize data,data type is to classify data into int/float/bool/etc
Python built-in list is implemented with dynamic array,Python built-intupleis implemented with static array,Python built-in`dict/set/frozrnset are implemented with hash table
Subsetted Properties are widely used in UML specification diagrams.
What are the semantics (meaning) of a Subsetted Property?
How does one use a UML Subsetted Property?
A real-world example would be great
Edit:
the following screenshot from UML specification 2.5(Beta)
Could you please let me know what subset means in this diagram?
Short answer
As there are two constraints that might produce problems and they are somewhat related (and they've led me to this question ;-) ) let me describe both of them, i.e. subsets and redefines
To sum up - redefines changes (provides more precise) logic of model for the same relationship but in specialized class while subsets shows relationship between different relationships of the same classes (they might be inherited but don't have to) and shows that objects that are in one relationship create a subset of objects that are in other relationship.
More elaborate answer
redefines
redefines changes in some way a logic of the relationship for a specialization of a class linked to a relationship. E.g. while animal can have any number of limbs (octopus 8 and centipede - who knows...), humans have always 4. So we have a relationship from Human to Limb with target name limb but a changed multiplicity (to 4).
Fig. 1 - Normal Limb - redefines
There might also be a further changes, like we might define a new class JointLimb which specialize Limb. As humans have only JointLimb our relationship will not only change the multiplicity but also allow only a specialized class on both ends of the relationship.
Fig. 2 - Joint Limb - redefines
subsets
On the other hand subsets shows that the objects that are in a one relationship (with subsets constraint) are all at the same time also in some other relationship (the one pointed in subsets constraint) i.e. set of objects in a relationship one is a subset of objects in a relationship two. In our case we will have new classes Hand and Leg specializing class Limb (or JointLimb in the latter example). As each Hand (Leg respectively) is a Limb (JointLimb) the relationship from Human to Hand (Leg) will have multiplicity 2, target name hand (leg) and will be constrained with subsets limb.
Fig. 3 - Normal limb - subsets
Fig. 4 - JointLimb - subsets
While in the previous example we were having a subsetting somewhat related to the inheritance it doesn't necessarily have to be the case. Let's consider class Car and class Wheel. A Car is equipped with Wheels (which is a relationship equippedWheel), some of them (e.g. 4 for passenger car) are mountedWheel while some (1 for passenger car) are spareWheel. Both mountedWheel and spareWheel subset equippedWheel.
Fig. 5 - Car - subsets
I'm sorry, I can't place pictures yet nor put more than 2 links so you have to follow this link to see the examples.
Hope that helps.
According to UML 2.4.1 specification, Subsetted Property references the properties of which this property is constrained to be a subset.
What do you mean by a real-world example ? UML specification is one of them I guess...
But you might find this kind of properties in all applicatioh where an Object is associatded to another and this association is redefined in the context of two of theirs subtypes.
For example, an Animal class can be associated to a Limb class. We can also define two classes Human and Leg extending respectively Animal and Limb. Finally we can associate Human and Leg which will be a redefinition of the preexisting association.
Hoping it helps,
BR
As I read that
aggreagation kind is a property of the association's member ends
And also
aggregation, association and composition are features of the
properties, which take part in the association as associatio ends, and
is called AggregationKind.
Could you Please clarify the two sentences through a UML simple example?
It is obvious that both the sentences have basically the same meaning.Generally,in many-to-many associations the association has itself two or more Properties as MemberEnds. We can describe these properties separately using a type called aggregationkind. This property in fact has an attribute aggregation of type AggregationKind.
AggregationKind is an enumeration type that specifies the literals for defining the kind of aggregation of a property or you can simply say AggregationKind defines the type of aggregation with the help of following basic literals:
none Indicates that the property has no aggregation.
shared Indicates that the property has a shared aggregation.
composite Indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts).
It’s this AggregationKind that specifies the difference between a regular Association, an Aggregation and a Composition.We can understand this with help of following diagram:
NOTE: the diagram is taken from here
Some of the useful links regarding this topic:
http://www.uml-diagrams.org/association.html
2.http://www.cs.sjsu.edu/~pearce/modules/lectures/uml/class/Aggregation.htm
My model looks like this:
InsurancePolicy
VehicleInsurancePolicy
AbcInsurancePolicy
DefInsurancePolicy
HomeInsurancePolicy
GhiInsurancePolicy
PqrInsurancePolicy
SomeOtherInsurancePolicy
... etc
where InsurancePolicy is an abstract class which is the base class for all concrete implementations of insurance policies. AbcInsurancePolicy , DefInsurancePolicy , etc are implementations which correspond to a certain insurance products. Sometimes I define other abstract classes for subgroups of policies with a subset of common fields (like VehicleInsurancePolicy).
I mapped this classes using a "Table per subclass, using a discriminator" strategy. The InsurancePolicy table contains about 60 fields, and each joined table adds from 10 to 30 fields. I used this strategy because:
I have a lot of subclasses with a lot of fields. A table-per-class-hierarchy strategy would end having a single table with a lot of null columns.
I want to be able to extend the application by adding other subclasses without changing the schema of InsurancePolicy table.
The InsurancePolicy is used often as a many-to-one relationship in other entities like Payment, Document etc.
NHibernate generates a lot of left-outer-joins when querying for InsurancePolicy because it doesn't know the type. This is very inefficient as I have a lot of tables to join. The problem becomes even worse when lazy-loading many-to-one properties containing an InsurancePolicy because it is used quite a lot in my model. The concrete implementations are used rarely, only in edit/details scenarios where it is specified the actual type and only the needed tables are joined.
Then I used a combination of discrimator + join. Thus the InsurancePolicy table contains the information about the type. Unfortunately a "join" mapping doesn't support lazy-loading. I tried setting fetch="select", however these generates N+1 selects when querying for multiple insurance policies.
// select from 1 table, "join" class must be lazy-loaded on access
Session.Get<InsurancePolicy>(5)
// select includes a join, since we explicitly specified a concrete type
Session.Get<SomeConcreteInsurancePolicy>(5)
So my questions are:
Is there a way to extend NHibernate to make it work like above?
Is there another way of mapping these large / complex class hierarchies?
Based on this:
The concrete implementations are used rarely, only in edit/details scenarios
I recommend that you break up InsurancePolicy in two:
InsurancePolicy, containing only the properties from the current base class
PolicyDetails, an abstract base class for the hierarchy.
There's a one-to-one relationship between those two classes.
The beauty of this is that you don't have to change anything else (except a minor change in the policy edit views, to point them to the new relationship)
I've been trying to encode a relational algebra in Scala (which to my knowlege has one of the most advanced type systems) and just don't seem to find a way to get where I want.
As I'm not that experienced with the academic field of programming language design I don't really know what feature to look for.
So what language features would be needed, and what language has those features, to implement a statically verified relational algebra?
Some of the requirements:
A Tuple is a function mapping names from a statically defined set of valid names for the tuple in question to values of the type specified by the name. Lets call this name-type set the domain.
A Relation is a Set of Tuples with the same domain such that the range of any tuple is uniqe in the Set
So far the model can eaisly be modeled in Scala simply by
trait Tuple
trait Relation[T<Tuple] extends Set[T]
The vals, vars and defs in Tuple is the name-type set defined above. But there should'n be two defs in Tuple with the same name. Also vars and impure defs should probably be restricted too.
Now for the tricky part:
A join of two relations is a relation where the domain of the tuples is the union of the domains from the operands tuples. Such that only tuples having the same ranges for the intersection of their domains is kept.
def join(r1:Relation[T1],r2:Relation[T2]):Relation[T1 with T2]
should do the trick.
A projection of a Relation is a Relation where the domain of the tuples is a subset of the operands tuples domain.
def project[T2](r:Relation[T],?1):Relation[T2>:T]
This is where I'm not sure if it's even possible to find a sollution. What do you think? What language features are needed to define project?
Implied above offcourse is that the API has to be usable. Layers and layers of boilerplate is not acceptable.
What your asking for is to be able to structurally define a type as the difference of two other types (the original relation and the projection definition). I honestly can't think of any language which would allow you to do that. Types can be structurally cumulative (A with B) since A with B is a structural sub-type of both A and B. However, if you think about it, a type operation A less B would actually be a supertype of A, rather than a sub-type. You're asking for an arbitrary, contravariant typing relation on naturally covariant types. It hasn't even been proven that sort of thing is sound with nominal existential types, much less structural declaration-point types.
I've worked on this sort of modeling before, and the route I took was to constraint projections to one of three domains: P == T, P == {F} where F in T, P == {$_1} where $_1 anonymous. The first is where the projection is equivalent to the input type, meaning it is a no-op (SELECT *). The second is saying that the projection is a single field contained within the input type. The third is the tricky one. It is saying that you are allowing the declaration of some anonymous type $_1 which has no static relationship to the input type. Presumably it will consist of fields which delegate to the input type, but we can't enforce that. This is roughly the strategy that LINQ takes.
Sorry I couldn't be more helpful. I wish it were possible to do what you're asking, it would open up a lot of very neat possibilities.
I think I have settled on just using the normal facilities for mapping collection for the project part. The client just specify a function [T<:Tuple](t:T) => P
With some java trickery to get to the class of P I should be able to use reflection to implement the query logic.
For the join I'll probably use DynamicProxy to implement the mapping function.
As a bonus I might be able to get the API to be usable with Scalas special for-syntax.