I want to verify that i correctly understand the rational unified process.
My understanding is:
For the requirements specification activity, i have to design the use case diagram (a general one), the class diagram (classes, attributes, relations), and a general sequence diagram.
For the analysis activity, i have to design a detailed use case, the sequence diagram (using control, view and model classes), the analysis class diagram, the collaboration diagram
For the conception diagram, i have to design the class diagram and the deploiement diagram
is that correct please?
for my questions:
When can i use the activity and the state-transition diagrams?
Is it correct to first design a class diagram in the requirement acquisition phase?
In the implementation phase, which diagrams do i have to use? Or do you only have to generate code from some diagrams?
thank you a lot !!
Your assumptions are right.
ADs are used to illustrate scenarios from a use case. State transitions are usually created for classes. The can be used in code generation.
Not really. To sketch a class diagram of your solution you need a rough idea how that could look like. Just taking it from requirements works only for simple systems. You need to go through the use cases first to settle a usable construct.
To implement a system some class diagrams are essential. SDs help the coder to see how the classes collaborate. You can not generate code from that. Only code stubs from classes.
Related
The picture is taken from the book "UML # Classroom". The text says "the registration is via e-mail, that is, asynchronous".
In actuality, I believe, there would be no "Student" and "Professor" objects involved in the process. Rather an interface, a call to a mail server and in general, nothing that would tell the viewer of the diagram what is really going on.
That makes sense to me because it has an illustrative purpose. The methods of the classes in the sequence diagram would only resemble the methods in a class diagram at a low level.
If I am tasked with a high level view of class diagram and high level sequence diagrams of a particular interaction, if I am then asked why the classes of the class diagram don't have any of the methods of the sequence diagram, am I right to say that they simply don't have to?
Should I reach a compromise with the sequence diagram wherein I try to make the calls similar to what will be going on in the program?
The methods of the classes in the sequence diagram would only resemble the methods in a class diagram at a low level.
Not necessary, all depends on the goal of the sequence diagram, you can have classes at design level (may be allowing to generate code) but having them in a sequence diagram giving a semantic (high) level. You can also show these classes in class/package/... diagrams without low detail so not at design level.
The only rule is to have diagram saying something useful, and following UML specification of course. Do not forget UML is not a method but a language, it does not indicate how it must be used.
Remark you can put note in a diagram to help saying explicitly its level/goal in case you are afraid it is confusing because not 100% limited/dedicated to design even using classes part of the design.
if I am then asked why the classes of the class diagram don't have any of the methods of the sequence diagram, am I right to say that they simply don't have to?
yes, because the goal is not necessary to show a sequence of calls but for instance a higher level.
Should I reach a compromise with the sequence diagram wherein I try to make the calls similar to what will be going on in the program?
Of course you can do too.
Notice a sequence diagram (so in fact an interaction) has limited features, while for instance an activity allows to model a behavior in detail without the same limitations.
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'm stiil a newbie with Enterprise Architect. I was wondering is there a way to generate automatically a certain type of diagram from an already existing other type of diagram and if yes - between what types of diagrams it could be achieved.
For example, could a sequence diagram be generated out of a given class diagram? Or it isn't possible because the sequence diagrams are behavioral and the class diagrams are structural?
Thanks in advance!
To concrete Vladimir's answer: a diagram is not a model. If you want to transform anything you need to focus on packages (single elements would not make much sense anyway).
it is absolutely not possible transform or generate class diagram to (from) sequence because of different semantic of diagrams. It is not good idea to do any transformation between diagram definitions. If some tool allows it, it always directed to a meaningless or incomplete structures.
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.