开发者

which should be drawn first , class or sequence diagram?

开发者 https://www.devze.com 2023-02-03 23:41 出处:网络
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 aft

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 diagr开发者_如何学Cam, 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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号