I'm trying to read UML Class diagrams used to document design patterns. I understand aggregation and composition - and aggregation uses the open diamond and composition uses the filled diamond.
I've read somewhere that a dotted line implies instantiation - i.e. if one class instantiates another then you use a dotted line from the instantiator to the instantiated. First, wouldn't composition use this as well as I thought composition implied ownership?
Second, I've seen lines drawn between classes which are not aggregate or composition - i.e. there's no diamnad at all. Here's an example where they are documenting the observer pattern:
http://www.dofactory.com/Patterns/PatternObserver.aspx
they show a line from subject to observer without any diamond. What's all this about?
thanks
Ray
A UML association is used to convey a relationship between two or more classifiers (e.g. classes). Compositions and aggregations are specialized forms of association.
Associations are often used in class diagrams to indicate that instances of one class can have references to instances of another class. For example, in the diagram to which you link, the association between ConcreteObserver and ConcreteSubject implies that a ConcreteObserver instance can have a reference to a ConcreteSubject instance (note the directionality of the association).
Dotted line implies dependency. There are many different types of dependency, one of them being instantiation. As said before, associations are a way to describe relationship between a classs having a property of another class. When it comes to relationships between classes in classs diagram, it is good to start from most concrete and go to more general. So start with composition, aggregation, association and dependency.
Related
My component diagram is mostly components, ports, and interfaces. The interfaces have operations and attributes. They do not capture any class based OO at the moment. What's the right way of doing that?
My options as I see them is either:
Add the class constructors to the component interfaces, and let the type carry remaining details like class operations.
Duplicate class interfaces into the component interfaces, e.g. having the class object as first parameter.
From the two the former is least work obviously. But perhaps there is a better way I've overlooked.
Notation
The easiest way to do this is to capture the interfaces in a separate class diagram, with only «interface» classifiers. The advantage is that these classifiers give a (hopefully short) name to an interface, and describe the attributes and operations that are needed, with all required details, including constructors (keep in mind that in UML constructors should be preceded with «Create»)
You can then show for the components in your component diagram the interfaces provided (lollipop) and required (socket) just referring to the named interfaces, without cluttering the diagram with lots of redundant interface specifications.
Design
When you refer to duplicating class interfaces at the component level, I understand that you mean to add attributes (parts?) and operations to the component.
Of course, components implementing the same implicit interface could in principle be interchangeable. However, this approach does not allow to have a clear understanding of the dependencies, and in particular use dependencies, that are practical to decouple components. In other words, your components would be hard-wired.
Adding class constructors at the component level seems cleaner in this regard, since your class constructor would reuse classes that are defined somewhere else. But if you're going into that direction, you could go one step further and consider using a factory class:
The factory class constructs objects of a given class or a given interface
Your component would be initialized or configured with such factory provided from outside. The factories could be interchanged to construct different kind of objects that meet the requirements.
*. If you go that way, I come back to the notational topic: the lolipo/socket notation would then allow to highlight better the decoupling that this design would offer.
I didn't understand the options you describe. Maybe a diagram would help. Here is how I would do it:
The specification component has two ports and is indirectly instantiated. For the realization component I select two classes that are realizing the component. Class1 has an operation that uses the service defined by interface I1. Class2 implements the service promised by I2. Since port p2 has a multiplicity of 16, the part typed by Class2 also has at least this multiplicity. The constructors (with the «create» stereotype), don't have parameters, so that the component can be constructed without any additional logic.
If you need additional logic, you can use directly instantiated components. They have constructors that could call the parametrized constructors of realizing classes and also create the wiring.
So lets say I have a class CelebrityDog. CelebrityDog can either be a BigDog or a SmallDog depending on what the user wants.
It will inherit the properties of one of them, but not of both. How would I depict this in a UML diagram?
UML perspective
I am sorry to come with an unpleasant answer, but this is not possible in UML according to the UML 2.5 standard, section 9.2.4.1:
Generalizations define generalization/specialization relationships
between Classifiers. Each Generalization relates a specific Classifier
to a more general Classifier.
...
An instance of a Classifier is also an (indirect) instance of each of
its generalizations. Any Constraints applying to instances of the
generalizations also apply to instances of the Classifier.
In other words, an inheritance relation in UML is a relationship between a generalization and a specialization. A class can be the specialization of several more generalization class but always in the same time (i.e. multiple inheritance.
Design perspective
I'll add to the already unpleasant answer, that this is anyways a very bad desgin, that you will not be able to implement in most of the mainstream languages.
You can improve with a model that is closer to the reality of the relationsips:
CelebrityDog is a Dog (inheritance, this is always true)
Dog has a DogSize (association, i.e. composition when implementing) which can change over time
DogSize can be specialized into BigDogSize or SmallDogSize
Et voilà !
Dog is the top level class. It does not contain a size attribute.
CelebrityDog derives from Dog (as do normal, EverydayDogs).
BigDog and SmallDog derive from CelebrityDog. Perhaps change their class names to BigCelebrityDog and SmallCelebrityDog.
It is possible to use multiple inheritance to solve this, but that can be confusing.
I've read that UML assumes by default that :
a class can inherit several others
an object is an instance of only one class
an object of a given class cannot change to another class
This leads me to the question : as there are 3 hypothesis, there are 2^3 possible combinations. Could you give me languages which would be examples of each of them ?
I mean for me Java is "false-true-true" and C++ is "true-true-true". What about the 6 others ? Or did I misinterpret the assumptions ?
Let's look at the UML 2.5 standard of the OMG, to have a definitive answer:
1.Class inheritance
The UML 2.5 standard clearly defines that a class can have none or several superclasses and, that conversely, a class can be superclass of none or several classes (see section 11.4.2 and 11.8.3.6).
So UML definitively allows multiple inheritance (as in C++ or Python). But you may as well restrict yourself and use only single inheritance and several interface implementations, like in Java and C#. You'd use a realization relationship to show the "inheritance" from an abstract interface (the inheritance arrow is then dotted).
2. Objects and classes
9.8.1: InstanceSpecifications represent instances of Classifiers in a modeled
system. They are often used to model example configurations of
instances.
FYI: the terms used in the standard are a little more general, but an object is an instance, and a class a classifier. This definition is then further refined in the semantcs in chapter 9.8.3 :
The InstanceSpecification may represent: • Classification of the
instance by one or more Classifiers, any of which may be abstract.
So UML allows objects to be an instantiation of several classes. I don't know languages that allow this, but if you do don't hesitate to comment ;-).
3. Changing class of object
I must admit that I can't answer this answer 100%. I don't think so, because, becoming an instance of another class would mean to re-insantiate a class, so it's not corresponding anymore to the definition of an instantiation.
Furthermore (see 9.8.3):
An InstanceSpecification may represent an instance at a point in time
(a snapshot). Changes to the instance may be modeled using multiple
InstanceSpecification, one for each snapshot.
This is somewhat ambiguous: a given object in a given diagram can't change classes. However, you can represent several times the object in different diagrams (snapshot) to show a change.
Conclusions
So your assumption 1 is true, 2 is false, and 3 true or false depending if you're reasoning at diagram or model level.
I'm making a class diagram for a project.
How can I describe vectors, lists, files or unsigned types?
I would like to make a detailed diagram so I need to specify the types of the members and the input/output parameters of the methods.
Thank you all!
For more detailed description of the inner structure of the class you need a Composite Structure Diagram. There you can describe your methods as "ports". And your fields as attributes. You can show there really almost everything!
For detailed description of the specific instances of the class and their mutual behaviour you need an Object diagram.
At the links applied you can see a bit how to make them. But take it as a start only.
The class diagram is too common to describe the inner structure of the class. It is tooled for the description of the inter-classes relations. So, you can put your information into the model of the class, but some of it won't be seen on the diagram. But I would advise you to start from the class diagram and make it as detailed as it can show and only later go to more detailed diagrams. Maybe you won't need them after all.
Edit:
You can make a port on the border of your class, name it fileName and connect it to io interface you use. (Composite Structure Diagram only)
As for vector/list, it is easier, and could be done in a Class Diagram. If you want to show that some attribute is a vector or list, simply write: someAttr:List or put a List block on the diagram, draw association to it and name its end "someAttribute". You could do it with File, too, but there you should draw more, I think, to show the used io interface.
For showing attributes in class diagram also look here.
You should use an uml class diagramm. [Link][1]
In a class diagramm you can relate class members with types, functions with parameters and signatures.
[1] http://www.holub.com/goodies/uml/
(Somebody can format this? IMHO SO app can not handle links..)
Your question is not clear to me. There are two variants:
you need to define what type of collections (vector, list etc) in specific programming language should be used to implement multicity element ([N], [0..N] ordered or unordered, unique or nonuniqu)
It is not possible to explicitly define in UML. You can only declare, what type it is. For example in note or constraint
You need simply define types of collection
Use ordinary class or DataType element to define
Standard syntax for member (attribute, port etc.) is following: +name:Type[Multiplicity]{contraints}
The same syntax is used for parameters (all types) of operation (methods in programming language)
Does any programming language provide such a thing?
Where could this be used?
For example:
note that somethingStrange is not a class, its an instance (its underlined) and this is an object diagram
Spec (section 7.3.22) says:
An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and the classifier name or names.
The convention for showing multiple classifiers is to separate their names by commas.
So im stuck with "multiple classifiers".
Any language with extensional rather than intensional typing will allow such constructs.
For example, in RDF two sources could make claims about a web resource which are completely conflicting, or in a 'duck type' language an object could have all the characteristics of two otherwise unrelated types.
Extensional languages classify objects by their properties - if it has prongs it's a fork, if it's got a handle and a bowl it's a spoon, if it has both prongs and a bowl it is both a fork and a spoon.
The difference between such languages and class oriented intensional languages such as C++/Java/C# to which UML is more commonly applied, is that you don't need a spork class to define things which are both spoons and forks - whether things belong to a classifier is defined by whether they meet the requirements of the classifier.
That's multiple inheritance if you're referring to classes (except that you should use solid edges for generalization), nothing wrong with that ;)
Note that an interface is also a classifier, so also the text of your question needs a bit of refinement -- nothing wrong with generalizing more than one interface, after all.
It's is a Dependency.
Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the latter is a parameter variable or local variable of a method of the former. This is different from an association, where an attribute of the former is an instance of the latter.
In other words your somethingStance class will use both Cat and Panzer
The below it is just an example of how it might look like
Public class SomethingStrange{
public Cat CatDependency{get;set;}
public Panzer PanzerDependency{get;set;}
}
UML does allow an object to be instance of several different classes (even if they are unrelated) at the same time. The fact that this is not the normal convention and not supported by programming languages is a different issue. UML tries to be as broad as possible even if specific technologies only can implement a subset of it.