I am trying to understand new piece of project. I am drawing UML class diagrams, but there is something missing for me in these diagrams: the creation of objects. What a traditional UML diagram can depict is how these classes are related to each other and how instances of these classes are related to other objects of other classes, but that is in the moment when they are already created. Sometimes it is not that obvious who creates who, sometimes it is totally misleading. For example objects of class A may create object of class B, but that A object just returns this B object and gives it to somebody else and doesn't hold any reference to it. And sometimes it holds (a reference or pointer). Sometimes it matters for the reader. So in fact there are two types (pieces) of information: holding and creating. I came up with my own way of visualizing this, but maybe there is something standard here? What do you think? And I don't have UML Object diagram in mind, that is not something very helpful when reading C++ or Java code and trying to understand the relation of classes and objects. And not sequence diagram also, that's a different kind of beast.
If you want to stick to class diagrams, you can use the «create» usage dependency from UML Standard Profile (chapter 22 of UML 2.5 specs).
«Create» | Usage | A usage dependency denoting that the client classifier creates instances
of the supplier classifier.
So e.g. here A creates an instance of B, and C just has a reference to B.
A type of UML diagrams show only one particular view of your system by abstracting the other aspects of a system. For example, a class diagram shows only the static aspect of the system, but not the dynamic behavior such as:
At what time an object was created
The central ideas of modeling a system is trying to deal with (or focus on) an aspect at a time, and at the same time to eliminate the complexity by forget about the other aspects of a system.
In this case, "creating an object at a particular time by who (another object)" should be dealt with behavior view, thus, we can use a sequence diagram to modeling the dynamic behavior:
You can see the Dimension of a sequence diagram in the Figure:
Horzontally, Objects Lifecycle
Vertically, Time
You might then be interested, how I can relate these models together? Will there be any inconsistencies among them? Right! if you are puzzling about this, you are in the right track!
Look! models are inter-connected each other, take an example, you can create a use case, and a use case can be detailed with a number of scenarios, then.. each scenario can be modeled by a sequence diagram, and the sequence diagram giving you the hints of what objects (and what operations and attributes in it) you need to build your systems, right?
Related
I know that I can build a Class diagram from a database E-R Diagram (tables become classes, tables properties are the classes properties...)
But I'm looking for informations (or step by step like) to create a class diagram from a use case description (or even a sequence diagram).
(All I found now is that the sequence diagram objects becomes classes and the stimuli messages methodes)
Any idea ?
I used to TA in software engineering, and both create a class diagram from a textual definition as well as create a class diagram from a sequence diagram were regular exam questions.
Creating class diagrams from a specification should be covered in your lectures since its one of the most important things to learn. This site explains the workflow quite well in my opinion.
It is important to note, that in software engineering there never is just one solution. You can tackle problems in multiple ways each with their own benefits and problems. The most important step to learning is doing it yourself, just looking at solutions won't help you.
For creating class diagrams from a sequence diagram:
Objects are instance of classes, in most sequence diagrams there is only one instance of any given class. Therefore "objects become classes" is not technically correct but the right intention.
Messages represent method calls on the receiving object, ergo you need to add these methods to the class of the receiving object.
Any communicating classes need to be associated, else they could not call their methods.
We put focus on only modelling the information you can derive from the sequence diagram, e.g. in most cases you do not know multiplicities of associations.
I have a short question:
Should I name attributes of types like a List, Arrays, Vectors or Pointers to objects (not primitive type) in the UML diagram or the only association/aggregation/composition arrows are enough?
Example: which of these diagrams is correct?
or
In UML, your second diagram would be correct if you wrote the property names at the far ends of the associations. While UML properties are allowed to be unnamed, it is not a good practice. Use association ends to indicate why the relationship exists. Sometimes more than one association must exist between one pair of classes, but for different reasons. How would you tell them apart?
The first diagram shows two properties of each type. One is named and another (at the end of each association) is unnamed. That is incorrect.
This really depends on what you're trying to convey in this architectural drawing.
The purpose of the drawing is to help reason about the structure of the software. It should not be used to represent all of the details of implementation. If you put too much detail in it, it becomes cluttered, and it is hard to keep it consistent with the source code as changes occur.
The UML drawing should be more abstract than the implementation. It should hide details on purpose, so that it conveys the external view of classes, and not how they are implemented internally. You generally don't want users of classes to assume too much about their internal implementation, therefore you don't want to expose it too much.
Also, an architecture is typically represented by several drawings - not one. Try to have each drawing focus on one level of abstraction. If you have a few high level classes that represent the main logic of the application, and many low level classes, it makes sense to have a drawing of just the high level classes separately.
I have a simple flow which I would like to describe using UML in best way possible. I have no experience with UML and do not want to chose ridiculous diagram type.
DataA --> ProcessorA --> DataB --> ProcessorB ... --> DataN -->ProcessorN
In nutshell, Data is collection of data in some structure and Processor x transform input data into data to be used by Processor X + 1.
Where Data and Processor are actual classes and it would be nice to show how this works in code - for processing a certain data usually the new processor must be created with the data object, something like process() method invoked on it which returns data as input for next processor.
I tried to study dynamic UML diagrams but I am not sure which type is best to use for this.
Activity diagram is a perfect choice for data flow behaviors. You can use them to show everything you stated and lots more, especially if you complement acticity diagram with some other UML diagrams. In this case I would recommend class diagram, as these data structures are probably important and should also been specified.
Here is a simple example of your situation.
The following diagram is an activity diagram:
It is very intuitive and I guess you will be able to interpret it even without studying UML. Besides this simple sequence flow, you can also model paralel activities, choices (if-then for example), events, responsabiities, etc. You can even "open" the single activities and model then internally with another level of activities.
Those grey elements show the data that is flowing in and out of single actions/activities.
The best thing in UML is combining several diagrams to show different aspects of your problem. Here it is reasonable to somehow explain how the Data A, Data B and other data objects actually look like. In UML there is a diagram for this, a class diagram:
I showed just basic features here. Classes model complex data, are usually equipped with attributes and have realtionshipss of different kinds with other classes. Here you can see how the actial data look like (in contrast to activity, which shows what is done with the data)
Class diagram is one of the structural UML diagrams, while activity diagram is typical behavior diagram. They work best together.
I presume that the sequence diagram would be the best one for your case, because your lifeline would represent your object (or class) and the interaction message between your object would represent your method.
You would also have a chronology with this diagram. This diagram is focus on the interaction from your object.
You can see it : http://en.wikipedia.org/wiki/Sequence_diagram
I would like to know which diagram from those two should be created first when designing large IT system.
In every article I read about UML, the component diagram is mentioned as almost last.
I think that, when designing a larger system is better to divide it to smaller parts/modules on the component diagram and then for every component create a detailed class diagram. Is that correct?
How it look in practice from your experiences?
Do you know of any article/tutorial that shows from beginning to end, the design of system using UML?
There is no mandatory order for UML diagram design - in fact, you will often find yourself creating several simple diagrams of different types, and refining them later. The process is generally iterative but doesn't have a follow a particular order.
That being said, some UML diagrams provide a more abstract view than others, and it may sometimes make sense to start with the most abstract views and work your way down to the most specialised ones. Use case diagrams typically come early, while object diagrams or state diagrams often come later in the design process, once the original, abstract solution has been refined.
You will also want to take a look at consistency between your diagrams: indeed, with several views you will introduce redundant elements, and it is important to make sure that they do not contradict each other. For example, if you have a sequence diagram and a class diagram, any call message in the former should correspond to an operation in the latter. See Alexander Egyed et al's work for automated consistency management and correction in UML models.
I've had this discussion with my professor at college about UML diagrams .
He believes that sequence diagrams should be drawn before getting to class diagrams, but I think the opposite . I think after finishing the usecase diagram , the next diagram should be class diagram and after that we should get to sequence diagram.
Rational rose requires us to use the classes in sequence diagram, which are already in class diagram.
Can anyone help me with this?
I think you're both wrong. They should be drawn at the same time. As you're drawing your sequence diagram, you will undoubtedly come up with properties that you will need to keep track of the state, or that you hadn't thought of if you do the class diagram in a vacuum.
Of course, this is highly subjective and personal, but years of real-world experience (as opposed to academic theory) have taught me to work on both at the same time. MAYBE starting with the class diagram, but the class diagram invariably changes when you start going through process flows.
Well it depends a lot on how you plan to do things. I think it's a subjective matter. If you rather explain the actions performed for your usecases and after this has been done write the classes based on what you need to perform the sequences your professor is right.
But if you prefer to determine what the structure of your classes are and then adapt the action sequence to this then you would do the class diagram first and later the sequence.
In my experience I do them concurrently. I put the fundamental attributes to the class diagram but not the actions, and while I do the sequence diagram I add the methods and attributes that I need to the class diagram.
There is no one standard answer. There are several opinions, approaches and methods. In Unified Process I believe you first identify use case and then make realizations for them, e.g. sequence diagrams. As in use cases, there are actors and the systems and/or its parts interacting ina sequence. Actually this interactions should help you decompose your design and get to classes. Once you have classes on the analysis level, you can go further to design classess and design interactions. However these are quite a lot to draw in a diagram, most of the times code is the best documentation on this level, even generated diagrams are too large and more difficult to understand then code itself.
To prepare sequence diagram you need classes not the class diagram
You can prepare empty classes on the fly while in process of preparing sequence diagram....
Identification class objects in be part of preparing sequence or you can try to identify your objects before hand....
sequence is logical process while class diagram is end output
I don't think there is an order for creating diagrams since both are two different views of a system: class diagram structural (static) and sequence is behavioral (dynamic). I would start with sequence diagrams since you will discover more classes to create as you go through sequences. Do whatever makes sense for you at the time. If your doing more object oriented programming, I would consider doing classes before sequences.
Structural and behavioural models for all but the very simplest systems are naturally created simultaneously and iteratively, refining both over time.
You may have some method of "object discovery" such as CRC cards, which will yield a set of initial classes, with collaborations (the classes they interact with) and responsibilities, which informs both the methods they will need, and internal behaviour/state/activity.
You may then want to explore the use cases and scenarios using sequence or communication diagrams, this will expose the details of the required object communication and therefore inform the generation of public methods and relationships to refine the class diagram while at the same exploring the system behaviour which may yield further objects and classes to be created.
You may also want to explore the internal behaviour of classes, especially if they have stateful and/or active behaviour; activity ans state-machine diagrams are useful for this.
Either way I doubt that the use of Rational Rose is really the determinant of diagram creation order. Rational may require the classes on a sequence diagram to exist, but I imagine that they need not actually appear on a class diagram; they can probably equally be created on the sequence diagram and then later placed on a class diagram, or even created in the project explorer or whatever the equivalent is in that tool. Even if the only method of creating a class is to place it on a class diagram, that does not require you to refine and complete the class or its relationships before exploring interactions on a sequence diagram.
You need to buy some clothes, how you will proceed. You start choosing clothes first or you will decide first where to go? At the same time, will you go to shoe store if you want to buy shirt.
So both are iterative, but definitely first step is sequence on very high (component) level then drill down to class level sequence
You should first decide your application flow,means you should first draw a sequence diagram. It will show the flow of your application after this you should go for class diagram.