I am making a structural diagram in UML using classes and objects and wondered if I was doing it correctly.
Would the following (on the right) be the correct way to represent an object diagram of the left-hand side class diagram?
No. You are using a Generalization which is not the case. Either leave that out or use a stereotyped dependency <<instanceOf>>. Note that this is no standard as per UML specs. But those specs leave you the freedom to express is this way.
The class from which the object is instantiated is already shown in the name objectName::className.
From Annex A p. 683 of the UML 2.5 specs, which describes the organization of diagram types:
NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.
Related
I was searching around for a simple example depiction on how it would look if class Professor and Class Student would both implement and interface from Class Person in a communication diagram or System sequence diagram.
I think its depicted as this a class diagram:
But i am curious if it can be depicted in a communication diagram or System sequence diagram ?
You can show anything in any diagram type. Citing p. 683 of UML 2.5:
NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.
I think, that's more than clear.
up until now, I always ignored the UML Metamodel, but now that I've taken a closer look at it, I have a question which isn't answered by the standard books which I have at hand.
The Metamodel describes elements and their associations per diagram. So, it defines for instance what kind of relationship an actor can have with a use case in a use case diagram.
But does it also describe the relationships / associations between diagrams? Or maybe better expressed between elements of different diagrams?
Example:
In a class diagram, I define how I structure my code. This is defined by the metamodel
In a deployment diagram, I specify how I deploy artifacts to execution nodes. Also defined by the metamodel
But does the metamodel also define relationships with which I can specify how I derive the artifact (which I deploy, maybe a .jar file) from my code?
Diagrams are only a view onto the model. So you can show any arbitrary part of your model. Preferably you create a number of different structural diagrams to explain your model structure. Those are later augmented with behavioral diagrams which show how certain elements collaborate.
tl;dr UML is not about diagramming.
Yes, metamodel explains how various elements of a model can be connected. Diagrams itself represent poets puff the model and it is also described in a metamodel. While it's not always clearly shown how to actually represent that, for example each behavioral model represent behavior of something. What can have this type of behaviour is part of metamodel.
Let's look at specific example.
Consider State Machine. Metamodel defines which elements can have State Machines (e.g. A class). So if you have a certain class you can draw a diagram of State Machine owned by this class. How to show that this SM is owned by that class is a different story but that is also possible with UML.
Then on a state machine you can have activities which according to metamodel have to be owned by the same class etc.
One remark - it's spread over the whole specification. But look at definitions of elements like classifier, behaviour, state machine etc. That's where your answer is.
Can someone give me an example of when is better to use State Diagram and when Class Diagram. Tnx in advance!
For what type of software system would you use state machine diagrams to model functional requirements?
For what type of software system is data modeling via UML class diagrams suitable?
A class diagram shows classes in their relation and their properties and methods.
A state diagram visualizes a class's states and how they can change over time.
In both cases you are talking about diagrams which are only a window into the model. The class relations define how the single classes relate to each other. A state machine can be defined for each class to show its states. In embedded systems you use state machines almost all the time but there are also state machines for business applications (you can do this if that).
This question reveals a very common misunderstanding. There are only thirteen types of diagram in UML. They're not used to describe different types of system, but to describe different aspects of the system you are documenting. Which you pick in any given situation is more a question of style, what you want to emphasize.
It is better to use state diagrams if you want to focus on how the system can go into different states in response to various events. Activity diagrams are better if you want to focus on activities being carried out in some order, sequence diagrams are better if you want to show messages being sent between entities.
The above are all types of diagram which show behaviour. Class diagrams are a different type of beast altogether, and show how structures of things fit together (as do package diagrams and component diagrams).
It might be worth pointing out that while UML does not include a "requirement" element type, the related modelling language SysML does. If you want to express a number of functional requirements on the form "the system shall" in a model, SysML is a better fit.
A state diagram shows the behavior of the class. A class model shows the relationship between two or more classes. It includes its properties/attributes...
A state is an allowable sequence of changes of objects of a class model.
Is an activity diagram is considered algorithmic?
Strange question indeed. Taking a look at dictionary definitions:
Algorithmic: of or relating to or having the characteristics of an algorithm
Algorithm(1): a precise rule (or set of rules) specifying how to solve some problem
Algorithm(2): an effective method for solving a problem expressed as a finite sequence of steps.
So: can Activity Diagrams be used to describe "a method for solving problems expressed as a finite sequence of steps"? Yes - that's their purpose. They support all the usual control structures required to describe algorithms: sequence (A followed by B), alternation (either A or B), iteration. They also provide explicit support for parallel activity.
Areas where they may be considered weak:
The execution semantics are not precisely and unambiguously defined. Whilst the UML spec does provide some semantics, it leaves some points open.
There's no pre-defined set of primitive types defined for Activity Diagrams. Thus, the lowest level primitive activities (adding integers, concatenating strings, etc.) aren't pre-defined. In that sense Activity Diagrams on their own aren't computationally complete.
However: those are nitpicking theoretics. In practice, Activity Diagrams are a popular means to represent algorithms: from the design of software procedures to specifying business processes.
Of course, it all comes down to your definition of algorithmic. If you go with the general definitions above then ADs are algorithmic. If you go with something more specific they might not be.
hth.
OMG Meta-Models (i.e. UML, SysML, etc.), starting from the Meta-Meta-Modeling language by means of which they are described (MOF), consists of two different classes of models respectively aimed at definining:
The static structure of a system, or architecture (i.e. Class Diagram, Component Diagram, Block Diagram, etc.);
The dynamic of the system, or behaviours (i.e. sequence diagram, activity diagrams, state machine diagrams, object interaction diagrams, etc.)
Activity diagrams belong to the second class so they are aimed at describing behaviours.
an algorithmic is only of type of behaviour that can be described by means of an activity diagram
Activity diagrams complemented with the new UML executable standards can be used to represent any algorithm. Activity diagrams alone can be used to represent the overall control flow but not really the details of data management
Im a bit uncertain about the relation between the Unified Modeling Language (UML) and the different modelling perspectives (conceptual, specification and impelementation) endorsed by (R)UP among other OOA/D methodologies.
From what I understand the same type of diagram using the same notation can have different meaning depending on the perspective* being used. For instance the class diagram can represent an abstraction of real world systems / phenomena in the conceptual perspective and when perspective is later changed to specification/implementation the class diagram is used to abstract constructs of a computer program.
Questions:
1) It is my understanding that certain rules exist for a UML class diagram in general. For instance that a class can extend another class but that it can't extend an association. Where are the entities of the class diagram and the rules about how they can relate defined? Does it all take place at the M2 layer in the UML metamodeling architecture
(see wikipedias illustratio of metamodel architecture)?
2) A related question. The way I see it, the general rules for a specific diagram span the modelling perspectives (again, it is absurd for a class to extend an association), but the different modelling perspectives will superimpose certain meaning to a particular type of diagram. For instance an association in the class diagram of the domain model (conceptual perspective) will inherently be bidirectional whereas it can be either bi- or unidirectional in the class diagram of the design model (specification / implementation perspective).
In the scenario just described the rule superimposed limits the properties of an association. Is it a correct assumption that rules superimposed by perspectives will always be a subset/limitation of the rules defined by the uml metamodel and never a superset?
Are these rules/limitations defined by the perspectives formalized (in a way similar to the metamodel) or are they mere conventions described in the OOA/D litterature?
* Perspectives are explained in paragraph 10.8: http://books.google.co.uk/books?id=r8i-4En_aa4C&printsec=frontcover&hl=da&source=gbs_v2_summary_r&cad=0
1) Your first question is quite clear. The rules that you are looking for are called a "metamodel". And yes, they are documented as what the OMG (the creators of UML, basically) call "MOF" or "meta-object facility". It is an OMG standard.
2) Your second question is a bit more confusing. I'll try to answer here. Diagrams are just views on an underlying model. The model is overarching and all-encompassing, if you wish. But diagrams are not. The perspectives that you mention are related to diagrams. But the model that underlies is multi-perspective, in the sense that all the elements form a connected mesh, without isolated "islands". Does this make sense? :-)